我們前面提到了Fast Forward這種合并模式戈咳，這種很方便网沾，Git默認也會優(yōu)先使用這種模式癞蚕，但同時會帶了一個問題，一旦合并且刪除分支后辉哥，分支的信息將不再存在桦山。
我們可以強制禁止Fast Forward模式，禁止之后Git就會在merge時產(chǎn)生一個新的commit記錄醋旦，這樣帶來的好處顯然易見恒水，那就是可以從歷史commit記錄中查看到分支信息；
現(xiàn)在來學習如何以--no-ff普通模式來git merge：
//現(xiàn)在在master分支上的文件內(nèi)容
$ cat README.text
無關風月oo
//創(chuàng)建新的dev分支
$ git checkout -b dev
Switched to a new branch 'dev'
//修改README.text 文件內(nèi)容
$ vi README.text
此恨無關風與月oo
//提交一個新的commit
$ git add README.text
$ git commit -m 'dev modify'
[dev 61d1a87] dev modify
1 file changed, 1 insertion(+), 1 deletion(-)
//切回master并使用普通模式合并
$ git merge --no-ff -m 'noff mergemerge with no-ff' dev
Merge made by the 'recursive' strategy.
README.text | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
因為本次合并需要創(chuàng)建一個新的commit饲齐，所以加上-m參數(shù)钉凌，把commit描述寫上。
然后我們使用git log查看分支歷史：
$ git log --graph --pretty=oneline --abbrev-commit
* 4102d9e (HEAD -> master) noff mergemerge with no-ff
|\
| * 61d1a87 (dev) dev modify
|/
* 3833f92 init master
分支策略
在實際開發(fā)中捂人，我們應該按照幾個基本原則進行分支管理：
首先御雕，master分支應該是非常穩(wěn)定的矢沿，也就是僅用來發(fā)布新版本，平時不能在上面干活饮笛；
那在哪干活呢咨察？干活都在dev分支上论熙，也就是說福青，dev分支是不穩(wěn)定的，到某個時候脓诡，比如1.0版本發(fā)布時无午，再把dev分支合并到master上，在master分支發(fā)布1.0版本祝谚；
你和你的小伙伴們每個人都在dev分支上干活宪迟，每個人都有自己的分支，時不時地往dev分支上合并就可以了交惯。
所以次泽，團隊合作的分支看起來就像這樣：
image.png
