通常在分支合并的过程中要做到两点:
- 产生有效的合并结果
- 提交日志记录具备可读性
如果仅仅保证合并结果的正确性,却忽略日志记录的可读性,将产生不受约束的合并日志,导致代码仓库不可维护,影响项目后期开发。这里我们围绕日志记录的可读性(第二点),来探讨合并分支的各种方法,并归纳出不同场景下的最佳实践。
场景一:功能分支开发完毕,并入主分支
$ git checkout master
Switched to branch 'master'
$ git merge feature
Fast-forward
![](https://i-blog.csdnimg.cn/blog_migrate/16a650474cd9869a89c96149e018424b.png)
最简单的场景,合并分支的默认实践
场景二:功能分支开发中途获取主分支更新,在开发完毕后并入主分支
通过merge 获取主分支更新
这里有一个fast-forward的设置,默认进行快速合并,对分支进行共线性整合。当然我们也可以选择非快进模式,参数--no-ff
用来保留分支信息。
- default fast-forward
$ git checkout feature
Switched to branch 'feature'
$ git merge master
Fast-forward
$ git checkout master
Switched to branch 'master'
$ git merge feature
Fast-forward
![](https://i-blog.csdnimg.cn/blog_migrate/1ec845c017beea1835793fefab23f10e.png)
- non fast-forward
$ git checkout feature
Switched to branch 'feature'
$ git merge --no-ff master
Non fast-forward
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff feature
Non fast-forward
![](https://i-blog.csdnimg.cn/blog_migrate/a1382a5b0a54453d88995e60e833e4b6.png)
通过rebase 获取主分支更新(最佳实践)
- default fast-forward
$ git rebase --onto master
$ git checkout master
Switched to branch 'master'
$ git merge feature
Fast-forward
![](https://i-blog.csdnimg.cn/blog_migrate/3b0e9380ee3a9634a9d023d75628cee9.png)
- non fast-forward
$ git rebase --onto master
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff feature
Non fast-forward
![](https://i-blog.csdnimg.cn/blog_migrate/ca273f57d3d1531c6e6f303e84871417.png)
通过rebase
重新整理功能分支,--no-ff
保留分支信息,应为最佳实践
场景三:功能分支开发完毕,并入生产分支,在开发完毕后并入主分支
- default fast-forward
$ git checkout -b dev
Switched to a new branch 'dev'
$ git merge feature
Fast-forward
$ git checkout master
Switched to branch 'master'
$ git merge dev
Fast-forward
![](https://i-blog.csdnimg.cn/blog_migrate/8241c687f65a429d237c4827fc33b200.png)
- non fast-forward
$ git checkout -b dev
Switched to a new branch 'dev'
$ git merge --no-ff feature
Non fast-forward
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff dev
Non fast-forward
![](https://i-blog.csdnimg.cn/blog_migrate/b368c0385b73a00fdd8335bc1669720d.png)
多级分支进行合并,--no-ff
保留分支信息,应为最佳实践
场景四:如何保留脏代码
我们要时刻保证日志记录的可读性,关于脏代码的存储和应用,也需要进行规范。
1、git提供了stash
命令,为每个repository提供了一个存储栈,用来临时存储未完成的修改,并且可以pop
于任意一条分支上。因为这是一个栈的存储结构,所以我们只能依序存,依序取,如若需要将脏代码永久留下并在必要时加以应用,我们可以采取后一种方案。
$ git stash
$ git stash pop
2、鉴于stash
的局限性,我们可以再建立一条标记分支用来保存脏代码,利用from
即可将其再次运用于任意一条新分支上
$ git rebase --onto 'base' from 'start'