Git分支管理策略

通常，合并分支時(shí)，如果可能，Git會(huì)用Fast forward模式，但這種模式下，刪除分支后，會(huì)丟掉分支信息。

如果要強(qiáng)制禁用Fast forward模式，Git就會(huì)在merge時(shí)生成一個(gè)新的commit，這樣，從分支歷史上就可以看出分支信息。

下面我們實(shí)戰(zhàn)一下--no-ff方式的git merge：

首先，仍然創(chuàng)建并切換dev分支：

$ git switch -c dev
Switched to a new branch 'dev'

修改readme.txt文件，并提交一個(gè)新的commit：

$ git add readme.txt 
$ git commit -m "add merge"
[dev f52c633] add merge
 1 file changed, 1 insertion(+)

現(xiàn)在，我們切換回master：

$ git switch master
Switched to branch 'master'

準(zhǔn)備合并dev分支，請(qǐng)注意--no-ff參數(shù)，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

因?yàn)楸敬魏喜⒁獎(jiǎng)?chuàng)建一個(gè)新的commit，所以加上-m參數(shù)，把commit描述寫進(jìn)去。

合并后，我們用git log看看分支歷史：

$ git log --graph --pretty=oneline --abbrev-commit
*   e1e9c68 (HEAD -> master) merge with no-ff
|\  
| * f52c633 (dev) add merge
|/  
*   cf810e4 conflict fixed
...

可以看到，不使用Fast forward模式，merge后就像這樣：

分支策略

在實(shí)際開發(fā)中，我們應(yīng)該按照幾個(gè)基本原則進(jìn)行分支管理：

首先，master分支應(yīng)該是非常穩(wěn)定的，也就是僅用來發(fā)布新版本，平時(shí)不能在上面干活;

那在哪干活呢?干活都在dev分支上，也就是說，dev分支是不穩(wěn)定的，到某個(gè)時(shí)候，比如1.0版本發(fā)布時(shí)，再把dev分支合并到master上，在master分支發(fā)布1.0版本;

你和你的小伙伴們每個(gè)人都在dev分支上干活，每個(gè)人都有自己的分支，時(shí)不時(shí)地往dev分支上合并就可以了。

所以，團(tuán)隊(duì)合作的分支看起來就像這樣：

小結(jié)

Git分支十分強(qiáng)大，在團(tuán)隊(duì)開發(fā)中應(yīng)該充分應(yīng)用。

合并分支時(shí)，加上--no-ff參數(shù)就可以用普通模式合并，合并后的歷史有分支，能看出來曾經(jīng)做過合并，而fast forward合并就看不出來曾經(jīng)做過合并。