Git rebase冲突优化

Question

假设我从

F1

创建了一个分支

main

。这个

F1

分支有 20 个提交。我现在想将此分支重新定位到

main

以获取来自

main

的更改

git checkout F1
git rebase -i main

但是，我知道

F1

上的几乎所有提交都修改了在

main

上也被修改过的文件。因此，在几乎所有 20 个提交中，我都必须解决冲突。

修复提交 1/20 中的冲突似乎是浪费时间，只是为了让它在 2/20 和 3/20 等中也发生冲突。

我是否应该从第一次提交 (1/20) 重新调整

F1

的基数，并将所有 20 次提交压缩为 1 次？然后重新设置

main

？

即类似：

git checkout F1
git rebase -i HEAD~19 (add -squash to the last 19 commits)
git push -f

然后

git checkout F1
git rebase -i main

Answer 1

我们对这个问题有一些很好的评论，我将在此处将其归功于并总结为一个汇总答案。

我是否应该...将所有 20 个提交压缩为 1 个...然后将 rebase 到 main 上？

正如评论中提到的NoDataFound：

我想说这取决于这些提交在历史中的重要性！

如果你愿意压扁...

正如Axnyff提到的：

我通常先进行挤压，然后再进行变基，但如果您有有意义的提交，则不应该这样做。

如果您计划最终将 20 个提交压缩为更少的“好”提交，那么是的，绝对要先进行压缩，然后再进行变基。如果你可能不打算压扁它们，但即使这样做也不会太困扰你，那么，你最好先压扁它们。请注意，如果您使用 Pull Request 工具来跟踪 PR 中分支的历史记录，请考虑在变基之前创建 PR，然后在变基之后强制推送您的分支，以便仍然可以在 PR 中找到 20 次提交。公关的历史。这是在 PR 工具中保留历史记录的一种方法，即使您在存储库本身中没有历史记录。有时，当我怀疑将来的某一天我可能希望看到各个提交的更详细粒度时，我有时会这样做，也许是为了确定为什么进行某些更改背后的原因，而在更大的压缩提交中可能更难确定。即使存储库中没有单独的提交，也可以轻松返回并查看 PR 以查看原始提交列表，您可以调查甚至再次在本地签出。

如果你不想挤压...

如果您的提交足够重要，需要保留，即使线性历史记录很好，但有时拥有线性历史记录的好处会被实现它的痛苦所抵消。这可能是您决定接受合并提交的情况之一。正如 Tim Biegeleisen 指出的那样：

事实上，解决这个问题的简单方法是使用 git merge。合并会一次性产生一个包含所有冲突的事件。

这是迄今为止最简单的解决方案，即使在严格的变基工作流程中，引入

main

偶尔进行合并提交也许不会引起太多焦虑。

如果您不想压缩并且无法进行合并提交...

如果您想保留完整的历史记录并且不想进行合并提交，那么您将不得不处理冲突。有一些选项可能有助于提高该过程的效率。来自LeGEC的评论：

git rerere

可以帮助：

git config --global rerere.enabled true

。请参阅

git help rerere

和 git 书籍 以获取更详细的解释

另一种选择是尝试使用

-X

选项来解决冲突。这将尝试通过支持“我们的”或“他们的”来解决冲突。 注意： 变基时，“我们的”和“他们的”的含义与合并时相比会翻转。如果您将

main

合并到

F1

中，那么您将签出

F1

，并且正如预期的那样，“我们的”是

F1

，“他们的”是

main

。但是，当将

F1

onto

main

变基时，则在变基期间

main

是“我们的”，而

F1

是“他们的”。例如，如果您希望通过将更改保留在

main

上来解决

F1

上 20 次提交中的所有冲突，您可以使用：

git rebase main F1 -Xours

请注意，在变基时，您还会看到术语“传入”和“当前”，它们类似于“他们的”和“我们的”。更多信息请参见此处。