使用git rebase，我应该假装在解决冲突时某些事情没有发生吗？

Question

我是git的新手，我对使用git rebase的“正确”方式感到有些困惑。

这个想法是，一旦我完成了rebase和冲突解决过程，我的历史看起来好像我没有改变我的想法吗？

例如，假设我提交了A并提交了B.提交A进行了一些重要的更改，但也引入了一个函数，我稍后在提交B中删除。当重新定位时，我遇到了提交中引入的函数的冲突甲

这里有什么“正确”的回应方式？我应该编辑提交A以避免完全引入该功能然后完全跳过提交B吗？如果是这样，我不会错过关于代码演变的重要背景吗？

Answer 1

我假设您将提交B重新提交到提交A。

如果存在冲突，请不要更改提交A，因为它代表提交B之前的代码更改。而是更改提交B（历史记录中稍后的编辑）以消除冲突并修复任何错误。

通常，您可以根据需要使用合并或rebase。如果你是你的git项目中唯一的人，那没关系。较大的群体可能有偏好。有些人喜欢rebase也许所以看起来一切都是线性的。其他人更喜欢合并，因为它与真正发生的事情相匹配。

较大的项目也可能希望将分支压缩到单个提交（使用交互式rebase），然后再将其合并回主分支（可能是为了简化历史记录）。

Answer 2

在我看来，这应该不重要。当你重新提交提交时，通常是因为你已经完成了一些功能或达到某种里程碑并且想要“重写”历史。从本质上讲，您对所做的事情的高级概述更感兴趣，而不是详细介绍。

如果要将特定代码更改作为rebase的一部分进行突出显示，请将它们放在提交消息中。

Answer 3

“如果是这样，请不要错过关于代码演变的重要背景”

嗯，是的，但这是一个重点。 rebase将历史重写为您希望的历史： - ）

您没有在上面提到您的提交，在同一分支上使用交互式rebase或在单独的分支中进行重新分配。

我将假设单独的分支，做一个rebase的重点是你正在重新排序一个分支上的提交被附加到另一个分支的末尾，如果现在发生冲突，那么你需要修改提交为如果它在另一个提交之后被编码，如果这意味着一个函数看不到白天的光，那么就这样吧。

如果提交的时间顺序对于上下文很重要，请改为合并。