小結(jié)
- Git分支十分強(qiáng)大，在團(tuán)隊(duì)開發(fā)中應(yīng)該充分應(yīng)用。
2.合并分支時(shí)狠轻，加上--no-ff參數(shù)就可以用普通模式合并，合并后的歷史有分支彬犯，能看出來曾經(jīng)做過合并向楼，而fast forward合并就看不出來曾經(jīng)做過合并查吊。
正文
通常，合并分支時(shí)湖蜕，如果可能逻卖，Git會(huì)用Fast forward模式，但這種模式下昭抒，刪除分支后评也，會(huì)丟掉分支信息。
如果要強(qiáng)制禁用Fast forward模式灭返，Git就會(huì)在merge時(shí)生成一個(gè)新的commit盗迟，這樣，從分支歷史上就可以看出分支信息熙含。
首先罚缕，仍然創(chuàng)建并切換dev分支：
修改readme.txt文件，并提交一個(gè)新的commit：
然后切換回master：
上述三步
合并dev分支怎静，請(qǐng)注意--no-ff參數(shù)邮弹，表示禁用Fast forward。因?yàn)楸敬魏喜⒁獎(jiǎng)?chuàng)建一個(gè)新的commit蚓聘，所以加上-m參數(shù)腌乡，把commit描述寫進(jìn)去
禁用Fast forward
合并后，我們用
git log看看分支歷史：
image.png
可以看到夜牡，不使用
Fast forward模式导饲，merge后就像這樣：
git-no-ff-mode
分支策略
在實(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-br-policy
