代码合并到底用Git Rebase 还是 Git Merge

在使用 Git 进行版本控制时，理解何时使用 git merge 和 git rebase 对于高效和有序的代码管理至关重要。虽然两者都是用于合并代码的强大工具，但它们在不同情境下的适用性和影响各不相同。本文旨在深入探讨这两种命令，并指导何时以及如何正确使用它们。

Git Merge

概述

git merge 是一种非破坏性操作，用于将两个分支的更改合并到一起。它通过创建一个新的“合并提交”（G'），将两个分支的历史联系起来。

优点

• 保留历史完整性：合并操作保持了两个分支的原始历史不变。
• 简单直观：对于 Git 新手来说， merge 更易于理解和操作。

使用场景

git merge 特别适用于团队协作环境，其中保留完整的历史记录和明确的合并点是有价值的。

Git Rebase

概述

git rebase 重新定位分支上的更改，将它们放在另一分支的最新更改之上。这通常涉及重写提交历史，使其看起来更加线性。

优点

• 清晰的线性历史： rebase 为项目提供了一个干净、直线的历史。
• 避免冗余合并提交：有助于减少不必要的合并提交。

使用场景

rebase 是理想的选择，当你想要整理个人分支上的提交，或者在团队中共享更改之前更新你的特性分支。

Git 变基的黄金规则

"永远不要在公共分支上使用 git rebase"。这是因为变基会改变历史，可能导致团队成员间的历史不一致，从而引起混乱。

选择 Git Merge 还是 Git Rebase？

在决定使用 git merge 还是 git rebase 时，重要的是要考虑你的工作环境和团队的工作流程：

大家在工作中团队开发的时候对于拉取分支和合并代码时就会涉及到两种选择，git rebase与git merge：

​

rebase：变基，会有一个干净的分支，但是对于记录来源不够清晰

merge：合并，git分支看起来比较混乱，但是清楚各个记录的来源与时间节点

拉公共分支使用最新代码：merge；

有些公司会要求使用rebase，也就是git pull -r或git pull --rebase。这样的好处很明显，提交记录会比较简洁。但有个缺点就是rebase以后我就不知道我的当前分支最早是从哪个分支拉出来的了，因为基底变了嘛，所以看个人需求了。总体来说，即使是单机也不建议使用。

git fetch

git merge --ff-only

往公共分支上合代码merge；如果使用rebase，那么其他开发人员想看主分支的历史，就不是原来的历史了，历史已经被你篡改了。举个例子解释下，比如张三和李四从共同的节点拉出来开发，张三先开发完提交了两次然后merge上去了，李四后来开发完如果rebase上去（注意，李四需要切换到自己本地的主分支，假设先pull了张三的最新改动下来，然后执行<git rebase 李四的开发分支>，然后再git push到远端），则李四的新提交变成了张三的新提交的新基底，本来李四的提交是最新的，结果最新的提交显示反而是张三的，就乱套了，以后有问题就不好追溯了。

​

正因如此，大部分公司其实会禁用rebase，不管是拉代码还是push代码统一都使用merge，虽然会多出无意义的一条提交记录“Merge … to …”，但至少能清楚地知道主线上谁合了的代码以及他们合代码的时间先后顺序

​

详细解读：

1 git rebase

1.1 过程详解

首先我们通过简单的提交节点图解感受一下rebase在干什么

构造两个分支master和feature，其中feature是在提交点B处从master上拉出的分支

master上有一个新提交M，feature上有两个新提交C和D

此时我们切换到feature分支上，执行rebase命令，相当于是想要把master分支合并到feature分支（这一步的场景就可以类比为我们在自己的分支feature上开发了一段时间了，准备从主干master上拉一下最新改动。模拟了git pull --rebase的情形）

​

将master上的分支合并到feature

这两条命令等价于git rebase master feature

git checkout feature

git rebase master

​

下图为变基后的提交节点图，解释一下其工作原理：