Open JTangming opened 5 years ago
团队中不少开发同事基本使用的是 --no-ff 的方式合并，但是这样会有很多无用的 commit log 信息，且 git log graph 不够线性。下面参考别人的动图，总结一下git的四种 merge 方式。
git 中的分支其实就是一类文件记录了分支所指向的 commit id，以下都用 master 和 test 分支举例。
如果待合并的分支在当前分支的下游，也就是说没有分叉时，快速合并是不错的选择。这种方法相当于直接把 master 分支 HEAD 指针移动到了 test 分支最近的一次提交，如下图：
快速合并给人的感觉是不知道主干分支 master 代码合并自哪里，其实可以强制指定为非快速合并，只需加上 --no-ff 参数，如：git merge –no-ff test。这种合并方法会在 master 分支上新建一个提交节点，从而完成合并，如下图：
总结一下以上两种合并方式，快速 merge 和 --no-ff 两种方式都有风险存在，即如果 test 分支删除可能会丢提交的代码。
squash 会在当前分支新建一个提交节点，但不会保留对合入分支的引用。如下图：
rebase 与 merge 不同，它会将合入分支上超前的节点在待合入分支上重新提交一遍，且保留了原本的 commit log 信息，如下图，B1、B2 会变为 B1’、 B2’，看起来会变成线性历史。
cherry-pick 给你想要的自由度，即把想要的某一 commit 提交节点合并到你想要的分支。
团队中不少开发同事基本使用的是 --no-ff 的方式合并，但是这样会有很多无用的 commit log 信息，且 git log graph 不够线性。下面参考别人的动图，总结一下git的四种 merge 方式。
git 中的分支其实就是一类文件记录了分支所指向的 commit id，以下都用 master 和 test 分支举例。
fast-forward
如果待合并的分支在当前分支的下游，也就是说没有分叉时，快速合并是不错的选择。这种方法相当于直接把 master 分支 HEAD 指针移动到了 test 分支最近的一次提交，如下图：
--no-ff
快速合并给人的感觉是不知道主干分支 master 代码合并自哪里，其实可以强制指定为非快速合并，只需加上 --no-ff 参数，如：git merge –no-ff test。这种合并方法会在 master 分支上新建一个提交节点，从而完成合并，如下图：
总结一下以上两种合并方式，快速 merge 和 --no-ff 两种方式都有风险存在，即如果 test 分支删除可能会丢提交的代码。
squash
squash 会在当前分支新建一个提交节点，但不会保留对合入分支的引用。如下图：
rebase
rebase 与 merge 不同，它会将合入分支上超前的节点在待合入分支上重新提交一遍，且保留了原本的 commit log 信息，如下图，B1、B2 会变为 B1’、 B2’，看起来会变成线性历史。
cherry-pick
cherry-pick 给你想要的自由度，即把想要的某一 commit 提交节点合并到你想要的分支。
通过比较，我们最终选择了 rebase 的 merge 方式，确保了提交 log 的线性和清晰度。