源码管理十三：分支管理策略

在实际开发中，我们应该遵循的几个分支管理策略：

第一，master分支必须是非常稳定的，也就是仅用来发布新版本，平时不在上面干活；

第二，干活都在dev分支上；也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

开发人员每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。到发布版本的时候，再往master分支上合并即可。

所以，团队合作的分支看起来就像这样：

在合并分支的时候，之前的提交方式：Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

下面我们实战一下--no-ff方式的git merge：

第一，先切换到分支dev上：

zhanggeng:git_learning (master)$git checkout -b devSwitched to a new branch 'dev'

第二，修改文件后，再提交：

zhanggeng:git_learning (dev *)$git add hello.txtzhanggeng:git_learning (dev +)$git commit -m "add merge"[dev 4fe60aa] add merge 1 file changed, 1 insertion(+)

第三，切换回master分支：

zhanggeng:git_learning (dev)$git checkout masterSwitched to branch 'master'Your branch is ahead of 'origin/master' by 4 commits.  (use "git push" to publish your local commits)

第四，以禁用“Fast forward”的形式进行合并：

zhanggeng:git_learning (master)$git merge --no-ff -m "merge with no-ff" devMerge made by the 'recursive' strategy. hello.txt | 1 + 1 file changed, 1 insertion(+)

第五，查看提交log:

zhanggeng:git_learning (master)$git log --graph --pretty=oneline --abbrev-commit*   a58efef merge with no-ff|\  | * 4fe60aa add merge|/  *   22d8df7 modify confilicg|\  | * 84331a1 AND simple* | a916a38 & simple|/  * 5d0d2b1 commit hello.txt* 010cb0f add modify* ca48fd5 delete text.txt* 6607fa5 add text.txt* 839cd4d delect test.txt* 6df06ba add test.txt* 5a31231 delete test.txt* fe439a5 add test.txt* 6850d61 six commit: add yes* d77a1bb five commit: modify by vim* 421f961 second : why so* c520dac first commit : for cat txt* ab88d5c thrid commit : do what* 4811639 second commit : think:

总之，

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。