通常在分支合并的过程中要做到两点：
- 产生有效的合并结果
- 提交日志记录具备可读性
如果仅仅保证合并结果的正确性，却忽略日志记录的可读性，将产生不受约束的合并日志，导致代码仓库不可维护，影响项目后期开发。这里我们围绕日志记录的可读性（第二点），来探讨合并分支的各种方法，并归纳出不同场景下的最佳实践。
场景一：功能分支开发完毕，并入主分支
$ git checkout master
Switched to branch 'master'
$ git merge feature
Fast-forward
最简单的场景，合并分支的默认实践
场景二：功能分支开发中途获取主分支更新，在开发完毕后并入主分支
通过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
- 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
通过rebase 获取主分支更新(最佳实践)
- default fast-forward
$ git rebase --onto master
$ git checkout master
Switched to branch 'master'
$ git merge feature
Fast-forward
- non fast-forward
$ git rebase --onto master
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff feature
Non fast-forward
通过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
- 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
多级分支进行合并，--no-ff保留分支信息，应为最佳实践
场景四：如何保留脏代码
我们要时刻保证日志记录的可读性，关于脏代码的存储和应用，也需要进行规范。
1、git提供了stash命令，为每个repository提供了一个存储栈，用来临时存储未完成的修改，并且可以pop于任意一条分支上。因为这是一个栈的存储结构，所以我们只能依序存，依序取，如若需要将脏代码永久留下并在必要时加以应用，我们可以采取后一种方案。
$ git stash
$ git stash pop
2、鉴于stash的局限性，我们可以再建立一条标记分支用来保存脏代码，利用from即可将其再次运用于任意一条新分支上
$ git rebase --onto 'base' from 'start'