分支管理策略

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

如果要強制禁用 Fast forward 模式，Git 就會在 merge 時生成一個新的 commit，這樣，從分支歷史上就可以看出分支信息。

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

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

$ git checkout -b dev
Switched to a new branch 'dev'

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

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

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

$ git checkout master
Switched to branch 'master'

準備合并 dev 分支，請注意--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(+)

因為本次合并要創(chuàng)建一個新的 commit，所以加上-m參數(shù)，把 commit 描述寫進去。

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

$ git log --graph --pretty=oneline --abbrev-commit
*   7825a50 merge with no-ff
|\
| * 6224937 add merge
|/
*   59bc1cb conflict fixed
...

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

http://wiki.jikexueyuan.com/project/git-tutorial/images/branch8.png" alt="" />

http://wiki.jikexueyuan.com/project/git-tutorial/images/merge-with-no-ff.gif" alt="" />

分支策略

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

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

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

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

所以，團隊合作的分支看起來就像這樣：

http://wiki.jikexueyuan.com/project/git-tutorial/images/branch9.png" alt="" />

小結(jié)

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

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