使用git rebase，我是否应该假装在解决冲突时未发生某些事情？

Question

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

是这样的想法吗：一旦我完成了改组和解决冲突的过程，我的历史就好像没有一路改变主意一样？

例如，假设我有一个提交A和一个提交B。提交A进行了一些重要的更改，但还引入了一个功能，后来我在提交B中将其删除。重新定级时，我遇到了与提交A中引入的功能冲突的情况。

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

Answer 1

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

如果存在冲突，请不要更改提交A，因为这表示提交B之前的代码更改。相反，请更改提交B（历史记录的后面的编辑内容），以消除冲突并修复所有错误。

通常，您可以根据需要使用merge或rebase。 如果您是git项目中的唯一人员，那没关系。 较大的群体可能会有偏好。 有人喜欢重新设定基准，因此似乎一切都是线性的。 其他人则更喜欢合并，因为它与实际发生的事情相匹配。

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

Answer 2

我认为这无关紧要。 对提交进行重新设置基准时，通常是因为您已完成一些功能或达到某种里程碑，并且想要“重写”历史记录。 从本质上讲，您更想对所做的工作进行高层次的概述，而不是进行详细介绍。

如果要突出显示特定的代码更改作为重新设置的一部分，则将它们放入提交消息中。

Answer 3

“如果是这样，我是否会错过有关代码演变的重要背景信息”

是的，但这就是重新设置基准的重点。 重新建立基础将历史记录重写为您希望的样子：-)

您在上面没有提到提交的位置，在同一分支上使用交互式rebase进行了重新设置，还是在单独的分支中。

我假设使用单独的分支，进行重新基准的目的是要对一个分支上的提交进行重新排序，以将其追加到另一分支的末尾，如果现在发生冲突，则需要修改提交，就像在另一个提交之后被编码，如果那意味着一个函数看不到日光，那就照做吧。

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