通常，合并分支時(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 checkout -b devSwitchedto a new branch'dev'
修改readme.txt文件，并提交一個(gè)新的commit：
$ git add readme.txt $ gitcommit-m"add merge"[dev6224937]addmerge1file changed,1insertion(+)
現(xiàn)在斥扛，我們切換回master：
$git checkout masterSwitchedto branch'master'
準(zhǔn)備合并dev分支入问，請注意--no-ff參數(shù)，表示禁用Fast forward：
$git merge --no-ff -m"merge with no-ff"devMergemade by the'recursive'strategy. readme.txt |1+1file changed,1insertion(+)
因?yàn)楸敬魏喜⒁獎(jiǎng)?chuàng)建一個(gè)新的commit稀颁，所以加上-m參數(shù)芬失，把commit描述寫進(jìn)去。
合并后匾灶，我們用git log看看分支歷史：
$ git log --graph --pretty=oneline --abbrev-commit*7825a50 mergewithno-ff|\| *6224937add merge|/*59bc1cb 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ì)合作的分支看起來就像這樣：
Git分支十分強(qiáng)大朽们，在團(tuán)隊(duì)開發(fā)中應(yīng)該充分應(yīng)用。
合并分支時(shí)诉位，加上--no-ff參數(shù)就可以用普通模式合并骑脱，合并后的歷史有分支，能看出來曾經(jīng)做過合并苍糠，而fast forward合并就看不出來曾經(jīng)做過合并叁丧。
