什么时候使用Git rebase而不是Git merge？

何时建议使用Git rebase vs.Git merge

成功重设基础后是否仍需要合并？

Short Version

• Merge接受一个分支中的所有更改，并在一次提交中将它们合并到另一个分支中
• Rebase说我希望分支点移动到一个新的起点

那你什么时候用哪一种呢

合并

• 假设您创建了一个分支以开发单个功能。当您想要将这些更改带回主控时，您可能需要合并（您不关心维护所有的临时提交）

重基

• 第二种情况是，如果您开始进行一些开发，然后另一个开发人员进行了不相关的更改。您可能希望从存储库中提取当前版本的更改，然后重新设置其基础

补充上述内容

• 在合并之前，重基通常是一个好主意，因为这样做的目的是在分支

  Y

  中集成要合并的分支

  B

  的工作
  但是，在合并之前，您需要解决分支中的任何冲突（即：“重新设置基础”，如“从分支的最近点开始在分支中回放我的工作”

  B

  ）。
  如果操作正确，从分支到分支的后续合并

  B

  可以快速推进

• 合并直接影响目标分支

  B

  ，这意味着合并最好是微不足道的，否则分支

  B

  可能需要很长时间才能恢复到稳定状态（解决所有冲突的时间）

---

重新设定基准后的合并点是什么

在我描述的案例中，我将

B

重新设置到我的分支上，只是为了有机会从

B

的较新点重放我的工作，但同时留在我的分支中。
在这种情况下，仍然需要合并才能将我的“重放”工作带到

B

另一种情况（例如）是通过重新基准将您的工作直接带到

B

（这会保留您所有的好提交，甚至让您有机会通过交互式重新基准对其重新排序）。
在这种情况下（当您在B分支中时重设基础），您是对的：不需要进一步合并：

当我们没有合并或重定基址时，默认情况下的Git树

我们通过重定基址获得：

第二个场景是关于：如何将新功能恢复到master中

通过描述第一个重基场景，我的观点是提醒大家，重基也可以作为实现这一点的初步步骤（即“将新功能恢复到主功能中”）。
您可以使用rebase在新功能分支中首先“引入”主功能：rebase将重播来自

主功能的新功能提交，但仍在新功能分支中，有效地将分支起点从旧主功能提交移动到
主功能提交

这允许您解决分支中的任何冲突（这意味着，如果冲突解决阶段花费的时间太长，则允许master继续并行发展）。

然后，您可以切换到主功能并合并
新功能
（或者如果您想保留在
新功能
分支中完成的提交，可以将
新功能
重新设置到
主功能
）

因此：


“rebase vs.merge”可以被视为导入工作的两种方式，例如，
master
但“重新基础然后合并”可以是一个有效的工作流，它可以首先单独解决冲突，然后恢复您的工作
这很简单。有了rebase，你可以说使用另一个分支作为你工作的新基础

例如，如果您有一个分支
主分支
，则创建一个分支来实现一个新功能，并说您将其命名为
酷功能
，当然主分支是新功能的基础

现在，您需要添加在
master
分支中实现的新功能。您可以切换到
master
并合并
cool功能
分支：

$ git checkout master
$ git merge cool-feature

但这样会添加一个新的虚拟提交。如果您想避免意大利面历史，可以重新设置基址：

$ git checkout cool-feature
$ git rebase master

然后将其合并到
master
：

$ git checkout master
$ git merge cool-feature

A <- B <- C
^         ^
 \         \
  D <- E <- F

A <- B <- C <- D' <- E'

这一次，由于主题分支具有相同的master提交和具有新功能的提交，因此合并将是一个快速的过程。
TLDR:这取决于最重要的内容—整洁的历史记录或开发顺序的真实表示。

如果整洁的历史记录是最重要的，那么您将首先重新设置基础，然后合并更改，这样就可以清楚地知道新代码是什么。如果您已经推动了分支，除非您能够处理后果，否则不要重新设置基础。

如果序列的真实表示是最重要的，则可以合并而不重定基址

合并意味着：创建一个新的提交，将我的更改合并到目标中。注意：此新提交将有两个父级-提交字符串中的最新提交和正在合并的另一个分支的最新提交

Rebase的意思是：使用我当前的提交集作为提示，创建一个全新的提交系列。换句话说，计算如果我从我要进行Rebase的那一点开始进行更改，我的更改会是什么样子。因此，在Rebase之后，您可能需要重新测试您的更改，并且在Rebase期间，您可能会有一些错误不公平

既然如此，为什么要重新设置基础？只是为了保持开发历史的清晰。假设您正在处理功能X，完成后，您将更改合并到中。目标现在将有一个提交
A <- B <- C <- D' <- E'

git fetch
git checkout origin/my_feature
git merge origin/master
git commit
git push origin HEAD:refs/for/my_feature

git fetch
git checkout origin/master
git merge --squash origin/my_feature
git commit
git push origin HEAD:refs/for/master

git fetch
git fetch <gerrit link>
git checkout FETCH_HEAD
git rebase origin/master
git push origin HEAD:refs/for/master

    B -- C
   /      \
  A--------D