[廖雪峰] Git 分支管理(3)：分支管理策略

通常，合并分支时，如果可能，Git 会用 Fast forward 模式，但这种模式下，删除分支后，会丢掉分支信息。

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

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

首先，仍然创建并切换 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(+)

现在，我们切换回 master：

$ git checkout master

Switched to branch 'master'

准备合并 dev 分支，请注意 --no-ff 参数，表示禁用 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(+)

因为本次合并要创建一个新的 commit，所以加上 -m 参数，把 commit 描述写进去。

合并后，我们用 git log 看看分支历史：

$ git log --graph --pretty=oneline --abbrev-commit

*   7825a50 merge with no-ff

|\

| * 6224937 add merge

|/

*   59bc1cb conflict fixed

...

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

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在 dev 分支上，也就是说，dev 分支是不稳定的，到某个时候，比如 1.0 版本发布时，再把 dev 分支合并到 master 上，在 master 分支发布 1.0 版本；
你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。

说白了就是 master 是正式版，dev 是测试版。测试版在测试后确认无误才能和正式版合并，如果一开始就在正式版上开发或者修改，那如果改的过程刚好有人要使用正式版，那么就没办法保证正式版的安全稳定了。

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

小结

Git 分支十分强大，在团队开发中应该充分应用。

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

【网友留言】

留言1：实际开发流程是不是这样子的呢？

leader 在远程仓库创建 2 个分支：master 和 dev
张三和李四克隆远程仓库到本地
张三和李四都切换到 dev 分支
张三创建分支 z3，李四创建分支 l4
张三合并 z3 到 dev，李四合并 l4 到 dev
张三和李四 push dev 到远程库（此处会冲突吗）
leader 把远程库里的 dev 合并到远程库的 master

答1：[廖雪峰] 合并也是在本地合并，把本地的 dev 合并到本地的 master，再把本地的 master 推到远程 master。

答2：Z3 --> dev 时先 pull origin dev

有冲突时，在自己本地更改。

Z3 提交到 --> dev

dev 下 merge z3

如果这时候

l4 --> dev

但是他并没有先 pull，他提交上去的就会出现冲突

如果这个时候他也在 dev 下 merge 就会出现冲突。

这时候就需要在 dev 下解决冲突。

如果有冲突的情况下提交 master 请求时就会告诉你，解决完冲突才可以提交。

留言2：远程的 master 和 push 上去的 master 进行冲突解决？

z3 master-->    |

l4 master-->     | ----> 远程 master

w5 master-->   |

各自解决各自的冲突，各个 master 之间的冲突 push 上去谁解决呢？

答1：[勤奋的光光2012] 根据我的理解，假设提交的先后顺序为 Z3 L4 W5， Z3 push 上去有冲突就 Z3 解决， l4 再拿到的就是 Z3 push 后的版本了，所以有冲突是 l4 解决，依次类推。

延伸阅读：

[廖雪峰] 分支管理 - 多人协作

摘自：

http://www.liaoxuefeng.com/wiki/0013739516305929606