分支管理
一.概念
在版本回退⾥,你已经知道,每次提交,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分⽀上合并就可以了。
通过这样的模式就能够实现多人协同开发了。