Git - Git教程 1.4：分支管理策略

前言

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

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

--no-ff 方式的 git merge

1 - 创建并切换 dev 分支

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

2 - 修改 FILE_T.txt 文件内容，添加内容随意，并提交一个新的 commit

$ git add FILE_T.txt
$ git commit -m "add merge"
[dev b1ab620] add merge
 1 file changed, 2 insertions(+), 1 deletion(-)

3 - 切回 master 

$ git checkout master
Switched to branch 'master'

4 - 准备合并 dev 分支。--no-ff 参数表示禁用 Fast forward

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 FILE_T.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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

5 - 合并完成，现在使用 git log 看看分支历史 

$ git log --graph --pretty=oneline --abbrev-commit
*   1455dae (HEAD -> master) merge with no-ff
|\  
| * 331b25c (dev) add merge
|/  
*   4776222 conflict fixed
|\  
| * 0285122 simple
* | 3d9d333 & simple
|/  
* adf1cd6 new branch
* e5012ec start branch

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

分支策略

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

① master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活

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

③ 你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了，所以团队合作的分支看起来就像这样

注：Git 分支十分强大，在团队开发中应该充分应用。合并分支时加上 --no-ff 参数就可以用普通模式合并，这样合并后的历史有分支，能看出来曾经做过合并；而 fast forward 合并就看不出来曾经做过合并