git

1.Git的一个版本（仓库快照）构成
假如我的仓库有两个文件，README.md、LICENSE
将会有三种对象产生：
* blob类型对象
blob类型：二进制的大型数据文件，可以用于存储文件的，如代码文件，图片等。
这里就是用来存储README.md、LICENSE这两个文件，因此产生了两个blob类型对象，每个这样的对象都会产生一个索引，可以理解成数据库的唯一索引。
索引举例：217c4abd5721876b8abe8cb3ff317903fd24d0

注意：这些索引在Git体系叫做指纹字串，官方称通过对文件内容和目录的结构计算出的SHA-1哈希值，具体如何得出，我无研究。

* tree对象
该对象包含blob类型对象索引的一个列表，和索引对应blob数据类型对象所存储的文件的文件名。

* commit对象
该对象包含tree对象索引，和提交的相关信息，如提交描述（如 $ git commit -m “Initial commit” 里面所指的”Initial commit”），作者，提交者。在第二次提交的时候，会产生新的commit对象，该对象新增一个属性parent用于指向较早前的一个commit对象，实际上保存的也是一个指纹字串。

2.什么是分支
 可以理解成你的工作区，你在工作区所做的一切修改都没有被提交的，也就是顶多就是出于暂存的状态，还没有形成版本信息的。而这个工作区（分支）都会指向一个commit对象的。

3.HEAD指针
Git保存着一个HEAD指针，指向本地当前（你正在工作的分支）分支的一个指针。

注意：官方在这里提出一句话--（译注：将HEAD想象为当前分支的别名）。
为什么只是想象呢？HEAD指针和当前分支有什么不同的地方？
答：当前分支是一个工作区，它是一个实体，而HEAD仅仅是指向这个实体的地址，严格来讲，HEAD是指针，当前分支是工作区，两者没半毛钱关系。只是可以通过HEAD来间接操作当前分支，后面提到的分支指针之所以能在创建之时指向当前分支，靠的就是HEAD指针。

4.分支
特性：指向最后一个commit对象。
* 创建分支：
$ git branch testing

注意：
* 这个不会自动将当前工作区自动切换到新创建的分支testing，要到切换
到testing分支：（下次再从Git Bash进入该本地仓库的路径，会选用testing分支）
$ git checkout testing

* Git默认分支的名字为master

5.合并分支的做法
我举个例子，流程如下：
1.首先我要在G:\test_github中新建一个git仓库，放一个文件“新建文本文档.txt”文本文件进去，该文件的内容为
“
文本文件
”。并完成一次commit动作（生成一份版本）。

2.然后新建一个testing分支，并转换为当前的工作区，对
  文本文件内容修改为：
“
文本文件

修改了东西
”，最后完成一次commit动作。

3.然后切换回master分支上，再对文本文件再修改一次，
文本内容修改为
“
文本文件

made other change
”，最后完成一次commit动作。

4.在master分支上进行与testing分支进行合并。

接下来我们来执行以下命令
流程一：
cd g:test_github
git init
git add .
git commit -m 'Initial commit'

流程二：
git branch testing
git checkout branch
(修改”新建文本文档.txt“的内容为
“
文本文件

修改了东西
”)
git add .
git commit -a -m 'made a change'

流程三:
git checkout master
(修改”新建文本文档.txt“的内容为
“
文本文件

made other change
”)
git add .
git commit -a -m 'made other change'

流程四：
git merge testing

合并操作执行后，系统返回的信息如下：
Auto-merging 新建文本文档.txt
CONFLICT(content):Merge conflict in 新建文本文档.txt
Automatic merge failed; fix conflicts and then commit the result.
(意思，就是git不能帮你自动合并新建文本文档.txt文档了，原因是在合并时发生了冲突。)

我们来分析一下为何会发生冲突：
在流程二，我们的修改为
“
文本文件

修改了东西
”)，在流程三时，我们的修改为
“
文本文件

made other change
”)，我们在master工作区和testing工作区都对“新建文本文档.txt”的第三行进行了修改。所以git帮我们合并不了了。在这种情况下，我们的文本内容变为：
”
文本文件

<<<<<<< HEAD
made other change
=======
修改了东西
>>>>>>> testing
“

注意，在这种冲突发生之后，我们在解决冲突之前不能进行任何操作，否则提示错误：error: you need to resolve your current index first

下一步，我们进行修正：
将文本修改为：
“
文本文件

made other change
修改了东西
”，在这里我们做了人工的内容合并工作，保留了两个版本的信息。然后通过暂存该文件：
git add .
查看冲突的解决情况：
git status
系统显示：
# All conflicts fixed but you are still merging.
#  (use "git commit" to concle merge)
#
# Changes to be committed:
#
#         modified:   txt.txt
#
从信息我们知道冲突解决了，但还处于合并状态。解决就是commit多一次。
git commit -a -m "commit merge changes"

这样我们就完成了合并了。

6.怎样的文件才能让git自动合并成功了
从第5点看出，我们之前没有成功使用过git的自动合并功能，在什么情况下才不会出现合并冲突呢？
在这之前我们冲突的情况为
“
文本文件

made other change
”
“
文本文件

修改东西
”，我们有理由怀疑是否不同版本的相同文件中发生不同的地方都出现在第三行导致的呢？于是我改一下
master工作区的文本文件：
“
文本文件

made other change
”
testing工作区的文本文件：
“
文本文件
修改东西
”
结果还是有冲突的，
”
文本文件
<<<<<<< HEAD

made other change
=======
修改东西
>>>>>>> testing
“，
后来我发现无论如何都是会有冲突的，除非我master上没有任何变化，也即master和testing工作区上的文本内容完全一致！，那么合并还有什么意义呢，都一样了，这里回到实际，我们在新的工作区，除了修改原有的文件，好大可能还在添加新的文件吧，这样，我们commit了新文件上去testing工作区，在master工作区就可以将新的文件拉下来了，对于我们有所修改的文件，统统都要我们人工合并的，所以到此，你应该明白到自动合并，git能帮我们做的是将新工作区的新建文件帮我们拉到我们的主分支上的！

7.合并完，还有一个操作
  当我们都合并完之后，旧的分支就没什么用了，此时应该删除。
 
  git branch -d testing
  系统显示：
  Deleted branch testing(was 2b4b78c)

总结：（这部分是个人的思考，并不是官方给出）
     1. 分支的用法场景一，当你在项目开始的时候，我们一般不太专注用户体验的，更多关注功能能否达标，因此初期我们会出一个以功能为主要考察的版本（master工作区），到了优化阶段，那你可能会在此基础上改的，而git会提倡你先建一个分支来开始你的优化工作（新分支工作区），当所有优化工作完成之后，将新分支合并到master分支（主分支上），这样做你在做优化的过程中，你可以大胆修改变动文件，即使改到乱了，也能返回到master分支拿回原始的代码的。
     2. 分支的用法场景二，当你的项目架构师将程序搭载好框架之后，接下来就是分工，可能不同人去做其中一个部分的，现在应该每个人都新建一个分支，完成之后，由架构师将代码合并工作，出现需要人工合并的时候找到相关部分的同事就ok了，或者他们之间相互协调就好。到最后合并成功之后，再逐一删除那些新建的分支。
    3. 新建分支的原则，在git中不会耗费多少性能损耗的，每新建一个分支，只是网.git中的index文件添加40字符长度 SHA-1 字串，如0000 0000 0000 0000 0000 0eb5 712a 4c2e，删除一个分支就是删除这个字符串，基本上都是几毫秒的事，所以git提倡多建分支，但是总有一些原则，就是当项目已经进展到一个阶段性或者说一个里程碑的时候，就应该新建一个分支出来，然后再在其上做后续开发了。

本文来源 我爱IT技术网 http://www.52ij.com/jishu/4255.html 转载请保留链接。