1

我是 git 新手,我对使用 git rebase 的“正确”方式有点困惑。

我的想法是,一旦我完成了 rebase 和冲突解决过程,我的历史看起来就好像我在此过程中没有改变主意?

例如,假设我有提交 A 和提交 B。提交 A 进行了一些重要的更改,但还引入了一个我稍后在提交 B 中删除的函数。在变基时,我遇到了与提交 A 中引入的函数的冲突。

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

4

3 回答 3

1

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

如果存在冲突,请不要更改提交 A,因为这表示提交 B 之前的代码更改。而是更改提交 B(历史中稍后的编辑)以消除冲突并修复任何错误。

通常,您可以根据需要使用合并或变基。如果你是 git 项目中唯一的人,那没关系。较大的群体可能有偏好。有些人可能喜欢变基,所以看起来一切都是线性的。其他人更喜欢合并,因为它更符合实际发生的情况。

较大的项目也可能希望在将分支合并回主分支之前将其压缩到单个提交中(使用交互式变基)(也许是为了简化历史)。

于 2012-08-19T00:50:48.913 回答
0

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

如果您想突出显示特定代码更改作为变基的一部分,请将它们放在提交消息中。

于 2012-08-19T01:04:33.527 回答
0

“如果是这样,我不要错过有关代码演变的重要背景”

好吧,是的,但这就是变基的重点。变基将历史改写为您希望的样子:-)

你没有在上面提到你的提交在哪里,在同一个分支上通过交互式变基或在单独的分支中变基。

我将假设单独的分支,进行变基的目的是您正在重新排序一个分支上的提交以附加到另一个分支的末尾,如果现在发生冲突,那么您需要修改提交,就好像它有在另一个提交之后被编码,如果这意味着一个函数没有看到光明,那就这样吧。

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

于 2012-08-19T01:09:53.300 回答