代码之家 › 专栏 › 技术社区 › Ben Crouse

git pull with rebase导致过度冲突。如何修复我们的工作流程?

rebase repository workflow merge git

Ben Crouse · 技术社区 · 14 年前

我们有一个为每个客户定制的基本系统。基本存储在自己的存储库中,每个客户机都在自己的存储库中(最初是从基本存储库克隆的)。

其目标是能够将错误修复/特性添加到基础中,可以根据需要传播到客户机。

到目前为止,工作流程如下:

为基本修复程序/功能创建提交/主题分支:(在基本版、主版上) git commit -m "Fix admin typo"
将这些更改合并到客户端中:(在客户端、主服务器上) git merge base/master . 显然,这包括修复基础和客户机定制之间的任何冲突。
将合并推送到客户机的源站:(在客户机上,master上) git push origin master
我们的惯例是使用REBASE(保持历史可读性)。因此,在客户机项目上工作的另一个开发人员将(在客户机上,master上) git pull --rebase origin master

正是在这一点上,我们达到了拉/再平衡的重大问题。开发人员在从基础合并到客户机后完成的pull/rebase中会遇到冲突。不仅仅是一些冲突,还有很多(对于许多正在重播的提交?)通常是特定开发人员从未接触过的代码。我认为这是不合理和不可持续的。

这里最好的解决方案是什么?

我唯一的想法是在拉和处理草率和难以阅读的日志时停止使用REBASE,但我不想这样做。这些客户项目可以持续数年,我希望将来仍然能够从基础系统合并中获得一些意义。

1 回复 | 直到 14 年前

cmcginty 14 年前

让我把这件事告诉你:

工作流失败,因为一个开发人员正在重新平衡 客户\foo 从分支到新的提交 基础 回购和回推 客户\foo . 这将最终打破所有其他开发者使用 客户\foo 当他们试图做下一次牵引时。所以你不能这样做,希望Git自动处理它。

如果每个客户机的repo只有一个dev,那么这可能会奏效。我想情况并非如此。

选项:

继续做你所做的,但当开发人员推动重新平衡 客户\foo 分支(与新的 基础 承诺)回到公众面前 客户\foo 回购,其他人都要做 reset --hard 在 origin/master . 如果他们在一个私人主题分支中保留所有未经处理的更改,那么他们必须 rebase 那些回到新的 client_foo/master .
有你的开发人员 merge 更改自 基础 到 客户\foo . 这将为您提供一个合并提交 客户\foo 你说你试图避免,但它会给你最准确的历史。当你的开发人员进行“拉-再平衡”时,你不应该再得到你现在所拥有的冲突的长列表。
有你的开发人员 cherrypick 变化来自 基础 到上面 客户\foo . 这会使你的历史保持线性,但Git将不再跟踪 樱桃采摘 D承诺来自 基础 . 你必须想出另一种方法来追踪它。

我会说坚持2,因为这是Git应该工作的方式。然而,其他人可能会想到一个更好的非显而易见的解决方案。