Git - 合并 vs 变基

Question

我看过 《何时使用 git rebase 而不是 git merge？。

但是在这种情况下，我想确定应该选择哪种解决方案：

我想要在master上实现新功能，因此我将其分支到一个新的功能分支。
我在 Feature 上进行了 10 次提交，而其他人则在主线上进行了其他提交。

我的问题是，如果我想将我的分支与主分支分开以进行测试，但我需要将其与新的主分支提交集成测试。 那么，我应该将 Master 合并到 Feature（而不是将 Feature 合并到 Master，这会在我的测试之前将修改应用于 master），还是执行 rebase？

- user2316341

---

这是一个有争议的问题。我会进行一次变基操作。 - 1615903

你查看的链接中排名第一的答案明确建议在你的使用情况下进行变基。 - mah

请在之后使用更加描述性的标题，以更清晰地解释您试图解决的问题。 - user456814

Answer 1

为什么不创建一个新的分支来测试合并后的版本呢？例如：

git checkout -b test-merged-feature master
git merge my-feature
[... do your testing ..]

这里并没有特别的理由需要进行rebase，但如果你还没有推送你的分支，那么也没关系。这些问题部分涉及到您希望您的历史记录是什么样子的 - 有些人不喜欢看到很多合并，有些人则更喜欢以此作为追踪哪些提交对特定功能做出了贡献的一种方式。

- Mark Longair

---

我想在这种情况下，拥有一个“dev”分支来测试功能，然后将其放到主分支进行生产，这将是一个好的实践吧？因此，合并与变基的问题只是关于您希望如何记录提交历史的问题？ - user2316341

我同意这个选项（在新分支中合并），所以+1。但是我仍然在下面的答案中提倡变基。 - VonC

如果你需要集成（合并）多个特性分支以查看它们是否能够协同工作，那么“dev”分支是有意义的。但是，如果你一次只有一个特性分支...这会增加复杂性，而收益很小。 - VonC

Answer 2

除非您已经推送了您的分支（并且您知道其他人已经克隆了您的存储库），否则我仍然建议进行变基，就像我在自己的回答中提到的一样：“git rebase vs git merge”。

测试或不测试，我通常在每次更新本地repo（git fetch）时进行变基，以确保最终合并（Feature与master）将是一个快进的合并。

因此，这不仅仅关乎您的历史记录如何展现，而主要关乎确保您正在开发的内容不是基于旧版的master，并且随时间保持针对master最新的演进。

- VonC

---

那么你的意思是说，我大多数时候都应该进行变基操作，但如果我已经推送了我的分支，就不需要进行变基操作。为什么会这样？已经推送分支有什么问题吗？ - user2316341

@user2316341，rebase 会重写 SHA1 的历史记录。在这种情况下，您需要使用 git push --force 命令来替换已经推送的历史记录，以便使用 rebase 生成的新历史记录。如果没有人使用您的分支，那么这并不是一个大问题，而且相比于在中间分支上人为地添加合并操作，rebase 是最简单和最安全的解决方案。 - VonC

@user2316341 可以参考 https://dev59.com/tWox5IYBdhLWcg3w1Xs3#8940299 来解决这个问题。 - VonC

Answer 3

在我所了解的工作流中，有一个主干(trunk)，一个或多个集成分支(integration branches)和功能分支(feature branches)。

我一直在向“衍生”(derivative)分支进行变基(rebase)（所谓的“衍生”分支指的是远离主干(trunk)的方向），并向集成分支进行合并(merge)。

我喜欢总是在与我将要集成的分支具有相同历史记录的分支上工作。我喜欢合并后能够快速前进(fast-forward)，这样我就知道我刚刚合并的内容与我在分支上测试过的内容完全相同。

- Chuck L

Answer 4

当两个开发人员提交到同一个repo时（这将导致冲突），您可以通过创建合并提交来合并这两个提交，或者可以将其中一个提交（您自己的）变基于另一个提交之上。与生成合并提交相比，重新基础始终更好。

- Mahmoud Zalt