Git详细教程（十三）分支管理-管理策略 Git详细教程（十三）分支管理

我们前面提到了Fast Forward这种合并模式，这种很方便，Git默认也会优先使用这种模式，但同时会带了一个问题，一旦合并且删除分支后，分支的信息将不再存在。
我们可以强制禁止Fast Forward模式，禁止之后Git就会在merge时产生一个新的commit记录，这样带来的好处显然易见，那就是可以从历史commit记录中查看到分支信息；
现在来学习如何以--no-ff普通模式来git merge：

//现在在master分支上的文件内容 $ cat README.text 无关风月oo //创建新的dev分支 $ git checkout -b dev Switched to a new branch 'dev' //修改README.text 文件内容 $ 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(-)

因为本次合并需要创建一个新的commit，所以加上-m参数，把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

分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
【Git详细教程（十三）分支管理-管理策略】首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：