本文已参与「新人创作礼」活动，一起开启掘金创作之路。
Git 分支合并策略
git merge 命令在合并分支时，支持使用如下三个参数：
git merge --ff，-ff 是默认的参数，即git merge == git merge --ff.git merge --no-ffgit merge --squash
三种合并方式的区别，使用 master 和 dev 分支来演示：
在 dev 分支上开发新功能，开发完毕，总共进行了 三次提交，记作 commitA，commitB，commitC。假设 master 分支上有一次提交，记作 commit0，现在需要把 dev 分支的代码合并到 master 分支上。
使用--ff 参数，dev 合并到 master 时，会把 提交信息也合并进来，也就是说：此时 master 分支上会有 4个提交，dev 分支上的提交信息也一同带入了 master。
默认的这种提交方式存在的问题：cA，cB，cC其实是从 dev 分支合并过来的，但是单看 master 分支，并没有任何信息可以表明它们是合并过来的，更像是直接在 master 上面开发的。
单看图谱，感受不到 master 和 dev 有过合并。
还有一个问题是提交顺序混乱。当有多个 dev 分支同时向 master 分支合并代码时，比如 dev1 是 5月份开发完毕的，但是迟迟没有上线，dev2 是 6 月份开发的，立刻就上线了。然后上线 dev1，在 dev1 合并到 master 时，你会发现，因为 dev1 是先开发的，所以它上面的提交信息排在了 dev2 的提交信息前面，这样存在的问题是，一个是提交信息混乱，再一个，想进行代码回滚都不知道如何下手了，因为 dev1 的提交全部掺杂在了 master 中，早已分不清了。
使用 --no-ff 参数，dev 合并到 master 时，会把提交信息也合并进来，同时会生成一个分支合并的提交信息（ git bash 中进入 MERGE_MSG 输入面板 ），也就是说：此时 master 分支上会有5 个提交，dev 分支上的提交信息也一同带入了 master。
单看图谱，也能知道 dev 合并到了 master 中。不过看图谱，会误以为 master 只有两次提交，但是 git log 查看是 5 次提交。
使用--squash参数合并，它把分支上的多次 commit 历史压缩为一次，在合并时，不会主动提交，还需要手动在 master 分支进行一次 commit，产生一个提交记录。此时 master 上只有2 个提交。
将 dev 的提交打包为一个，然后提交到 master。
图谱如下：
使用这种方式，无论是版本修改历史，还是进行版本的回退，都非常方便。
