分支管理
一.概念
在版本回退⾥，你已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分⽀。截⽌到⽬前，只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即master分⽀。
每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀。可能到目前为止还很模糊，接下来结合例子一起看。
二.分支管理基本操作
1. 查看分支
git branch
目前为止我们只创建了master分支（这是默认创建的），那么前面的*代表什么呢？之前我们的HEAD指针一直指向master，所以当我们进行add操作时是一直向master分支里添加。而HEAD可以指向其它分支，被指向的分支就是当前正在工作的分支。 *出现在master前面就代表master正在工作。
2.创建分支
git branch+name
接下来看看.git下的变化。
看到heads下面多出了一个dev，接下来查看它们的内容。
我们知道master里是最新提交的commit ID，但dev里存的内容竟然与master一样。这是因为我们是基于当前最新提交而建立的分支。
3.切换工作分支
git checkout +分支名，加上-b选项表示如果没有就创建一个。
4.进行测试
对ReadMe文件进行修改，并提交。
接下来切回master分支，再看看ReadMe内容。
可以看到我们新加的内容没有了。
5.合并分支
用master分支和并dev分支，注意必须切回mater分支。
仔细观察，可以发现这里打印出了Fast-forward（快速合并），为什么说快速呢？因为它是直接让master指向dev的本次提交，所以快。从这里你可以发现，在本次直接更改master指针没有问题，因为dev并没有对master内容进行修改，只是增加了一行，所以dev相当于向下兼容。如果dev里的数据是aaa，master里的数据是bbb，那么合并时应当保留谁，去除谁呢？
6.分支冲突
进行实验。在dev1分支上让ReadMe增加一行bbb，在master分支上增加一行aaa。
此时状态master和dev1都进行了提交：
再次进入ReadMe查看。
<<<<<到=====之间的代码都是当前分支的代码， ======到>>>>>之间的代码都是dev1分支的代码。这些都是冲突代码，git没办法解决，需要自己手动删除或保留代码。例如想保留bbb代码，那么只需要删除其它代码即可。
此时还需要再次提交。
此时状态master和dev1进行了合并：
这里再介绍一个命令，可以将上面的图打印出来，git log --graph --abbrev-commit。
7.分支删除
注意要删除某一分支，只能在其它分支上操作，例如我们要删除dev分支，就要在master或者除dev之外的其它分支上执行git branch -d dev。
三.分支管理策略
1.noff模式
通常合并分⽀时，如果可能，Git会采⽤ Fast forward 模式。在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是merge进来的还是正常提交的。但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交。那么这就不是 Fast forward 模式了(一般称为noff模式)，这样的好处是，从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀，但依旧能看到master其实是由其他分⽀合并得到。
Git⽀持我们强制禁⽤ Fast forward 模式，那么就会在merge时⽣成⼀个新的 commit ，这样，从分⽀历史上就可以看出分⽀信息。命令：git merge --no-ff 分支名。
fast模式
当我们使用fast forward模式，不会有分支信息。
master分支里的ReadMe
dev2里的ReadMe
将两者直接合并
没有分支信息
noff模式
master分支里的ReadMe
dev3分支里的ReadMe
使用noff合并(ps:由于写到这时xshell崩了，所以换了一个)
2.分支策略
在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：
⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活；
那在哪⼲活呢？⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布时，再把dev分⽀合并到master上，在master分⽀发布1.0版本；你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就可以了。
通过这样的模式就能够实现多人协同开发了。