在将 MR 与 squash 合并之前忽略 master 上的 rebase 会导致任何问题吗？

Question

我们倾向于在每个 MR 合并后对每个分支进行 rebase。导致了很多不必要的管道等等。但我们将每个 MR 压缩为一次提交。

那么考虑到合并请求中没有冲突，在合并之前省略rebase到master会导致任何问题吗？

Answer 1

您可以可能跳过预合并变基。

我可以想到在完成 MR（或 PR）之前将源分支重新定位到目标分支的 3 个原因：

1. 存在冲突，您必须以某种方式更新分支。 （不适用于您的情况。）
2. 如果您使用

   merge --no-ff

   完成 PR，那么生成的历史记录会更干净，从而产生漂亮的小合并气泡。 （既然你挤压，这也不适用于你的情况。）
3. 您希望在合并到目标之前测试最新和最好的代码。尽管在没有合并冲突的情况下潜入错误的情况通常很少见，但它仍然是可能的，特别是当多个人正在处理代码的相同部分时。如果您有良好的单元测试覆盖率，那么在完成 MR 之前，也许可以快速轻松地根据最新代码重新运行它们，以防万一。

显然 #1 和 #2 不适用于您的情况，但如果我处于您的位置，并且我有良好的测试覆盖率，那么 #3 可能是我盲目重新设定并重新运行测试的充分理由万一。如果我没有良好的覆盖范围并且没有简单的方法来重新测试所有内容，我可能会快速浏览一下，看看我是否认为需要它，如果没有，我会跳过它。

旁注：

1. 既然你正在压缩，对于#1和#3，你可以通过合并而不是变基来完成同样的事情。选择对您来说更容易的一个。例如，如果您正在解决冲突并且有很多提交，那么与在变基期间解决每个提交的冲突的最坏情况相比，合并通常比变基更快，因为它一劳永逸。
2. “但是我们将每个 MR 压缩为一次提交。”这里请注意一点。将 feature 分支压缩到目标分支中是完全可以的，但请确保不要将 shared 分支压缩到彼此中。这只会给每个人带来混乱。如果您曾经创建 MR 将一个共享分支合并到另一个共享分支，则仅在此处使用常规合并。
3. 虽然压缩对于较小的更改可能很方便，并且对于那些进行了许多 WIP 提交但没有修复它们的人来说，恕我直言，当开发人员不遗余力地进行多次良好的、有意义的提交时，那么我更愿意拥有所有这些提交到永久历史记录中，因为这是开发人员想要的。