1.1 什么是分支

公司正常流程其实有好几套服务器的，各司其职，有的直接服务用户，有的是测试专用，有的是开发专用，程序员总不能在服务客户的服务器上随心地commit吧。

在版本控制过程中，同时推进多个任务，为每个任务，我们就可以创建每个任务的单独分支。使用分支意味着程序员可以把自己的工作从开发主线上分离开来，开发自己分支的时候，不会影响主线分支的运行。对于初学者而言，分支可以简单理解为副本，一个分支就是一个单独的副本。(分支底层其实也是指针的引用）

1.2 分支的好处

master分支1.0版凑合着用，后来我想给它加个blue背景，就分出feature-blue分支，让master继续为用户提供服务，程序员在后方给feature-blue分支加入blue背景。然后合并到master分支，成为1.1版，结果发现bug，赶忙分出hot-fix分支抢修，经测试后合并到master，成为1.2版。后来又想加入游戏功能，单开一个feature-game分支，经多轮测试后无误，合并入master，觉得改动较大，遂曰2.0版。

可见分支好在:同时并行推进多个功能开发，提高开发效率。各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。

1.3 分支的操作

v是view。对于还没有过commit的分支，切换到其他分支上git branch -d 分支名即可删除。对于有了commit的分支，切换到其他分支上git branch -D 分支名即可强制删除。

圈出来的代表当前所处分支。 在hot-fix做作的任何代码修改、git add、git commit都不会改动到master分支。

如果我在hot-fix上新增了一行字符串hot-fixed modified，随后git add、git commit(这两步必须有，不然对于分支来说，代码是没有改动的)，然后回master执行分支合并：

你会发现master的Hello.txt也被更新了（此次合并，两分支原先一样，然后只有hot-fix有修改，所以此次合并没有冲突可言）。合并规则是，站在master分支执行git merge hot-fix能将hot-fix并入master。

1.4 分支合并详讲

在分支改好代码后尽量add commit下

正常合并

对于master，当前工作区的文件和最新的commit时的一模一样（不一样还有其他问题，不知道怎么回事）。然后git status显示working tree很干净，然后创建hot-fix分支，此时发现在两个分支cat txt内容都是1 2 。然后在fix分支修改txt为1 2 3，并git add、git commit，cat txt发现1 2 3，git status显示很干净，切回master，cat txt还是1 2 ，git status显示很干净。最后git merge hot-fix，发现master的txt变成1 2 3 过程如下

(master)$git status : working tree clean
(master)$cat Hello.txt : 1 2
(master)$git branch hot-fix
(master)$git checkout hot-fix
(hot-fix)$cat Hello.txt : 1 2
(hot-fix)$vim Hello.txt后cat : 1 2 3
(hot-fix)$git add Hello.txt
(hot-fix)$git commit Hello.txt
(hot-fix)$git status : working tree clean
(hot-fix)$git checkout master
(master)$cat Hello.txt ： 1 2
(master)$git status ： working tree clean
(master)$git merge hot-fix 
(master)$cat Hello.txt ： 1 2 3
(master)$git branch -v ：   hot-fix 2b8da1b 333  &  * master  2b8da1b 333
(master)$git status ： working tree clean

这个合并很平静，因为fix基于master有了修改，所以没冲突。

冲突合并

冲突产生的原因:合并分支时，两个分支在同一个文件的同一个位置有两套完全不同的修改。Git无法替我们决定使用哪一个。必须人为决定新代码内容。

前提：此时master是working tree clean，我删了hot-fix然后重新创建了hot-fix以确保分支内容一样，txt都是1 2 3。开始实验：

(master)$ vim Hello.txt
(master)$cat txt : 1 2 3 4
随后(master)$add, commit, git status : working tree clean
(master)$ git checkout hot-fix
(hot-fix)$ cat Hello.txt : 1 2 3
(hot-fix)$vim txt,cat txt : 1 2 3 5
(hot-fix)$add, commit, git status : working tree clean
(hot-fix)$ git checkout master
(master)$ cat Hello.txt : 1 2 3 4
(master)$git status : working tree clean

彩色的后缀新增|MERGING，表示还处在合并中，可以用git status确认，此时vim txt发现git版本我们标记了两个分支在哪几行分别做了不一样的改动：

附一个老师的示例:

<<<< HEAD到=====之间是当前分支的改动内容，=====到>>>> hot-fix之间是hot-fix的改动。
我们要怎么样才能继续合并呢？：vim txt，手动修改txt的内容，就基于上图的内容修改，
你可修改为1 2 3 4或者1 2 3 5或者1 2 3 4 1 2 3 5或者1 string added randomly或者其他任何，记得最后把<<<< HEAD和=====和>>>> hot-fix删了。:wq保存。（说白了就是必须人为决定新代码内容，随你怎么决定）
此时你还处在(master|MERGING)状态，可以用git status确认，只有git add Hello.txt，紧接着git commit -m "message" 才能完成合并。注意：处于(master|MERGING)状态下commit不要跟文件名，毕竟Git知道它的任务（不然一直挂着master|MERGING吃白饭的？。）。
merging中非要带文件名commit的报错信息：
(master|MERGING)
$ git commit -m "8" Hello.txt ： fatal: cannot do a partial commit during a merge.
​
此时(master)$ cat Hello.txt ：1 2 3 4"\n"1 2 3 5
合并成功！
此时 (master)$ git checkout hot-fix
(hot-fix)$ cat Hello.txt ： 1 2 3 5
hot-fix不受影响。

1.5 对于分支的理解

毕竟git是C编写的，说白了主要有图中红蓝两种指针和蓝色长方形代表的多个分支和黄框代表的某个分支的多个历史版本。红指针代表HEAD指向哪个分支变量，蓝指针对于$master就是$master变量指向哪个master分支上的哪个版本；蓝指针对于$hot-fix就是$hot-fix变量指向哪个hot-fix分支上的哪个版本；最终由HEAD->某分支->该分支上某版本决定程序员当前处在哪个分支的哪个版本上。 只是两个低级的C语言指针的运用罢了。

1.6 猜测

问题描述：第一次测试发现，创建一个分支，一开始（记为t0时）master和hot-fix的Hello.txt内容一样，然后在fix里改，结果两分支的TXT都改了。第二次测试发现创建一个分支，一开始master和hot-fix的Hello.txt内容一样，然后在fix里改，然后git add、git commit，结果fix分支的txt改了，master的反而回退到master最新的commit时的内容了（也就是说t0时master工作区的内容不等于master本地库最新版本的内容，即没有add commit，第二次测试的结果是master的工作区变成等于master本地库最新版本的内容了）。

猜测：刚开始复制出hot-fix分支时，OS为了节省空间，采用引用赋值，所以两分支的工作区是同一块地，所以改动任一处的txt，在另一分支cat txt，会发现内容变化了。直到hot-fix git add又git commit，才改为普通赋值，上文所谈及的那块地被分配给了hot-fix，那么master没地了呀，就另辟一空间，结果没现成的数据，只好取master的当前版本的内容。