Git pull with rebase导致过度冲突.如何修复我们的工作流程？

Question

我们有一个为每个客户定制的基础系统.基础存在于自己的存储库中,每个客户端都位于自己的存储库中(最初从基础克隆).

目标是能够向基础添加错误修复/功能,可以根据需要传播到客户端.

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

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

正是在这一点上,我们通过拉/ rebase达到了重大问题.开发人员在从基础到客户端的合并之后完成了pull/rebase中的冲突.它不仅仅是一些冲突,还有很多(许多提交被重播？),而且通常是特定开发人员从未触及过的代码.我认为这是不合理的,也是不可持续的.

什么是最好的解决方案？

我唯一的想法是在拉动和处理草率和难以阅读的日志时停止使用rebase,但我宁愿不必这样做.这些客户端项目可以存在多年,我希望将来能够从基础系统合并中找到一些意义.

Answer 1

让我直接了解您的存储库：

工作流程失败，因为一名开发人员正在将分支重新client_foo定位到存储库中的新提交base并推回到client_foo. client_foo当其他开发人员尝试进行下一次拉动时，这最终会破坏他们使用的所有功能。所以你不能这样做，并期望 git 自动处理它。

如果每个客户端存储库只有一名开发人员，那么也许这会起作用。我认为情况并非如此。

选项：

继续做你正在做的事情，但是当开发人员将重新调整的client_foo分支（带有新的base提交）推回公共client_foo存储库时，其他人都必须执行reset --hardon origin/master。如果他们将所有未推送的更改保留在私有主题分支中，那么他们必须将rebase这些更改返回到新的client_foo/master.
让您的开发人员merge从更改base为client_foo. 这将为您提供您所说的试图避免的合并提交client_foo，但它将为您提供最准确的历史记录。当你的开发人员执行“pull --rebase”时，你不应该再得到现在的一长串冲突。
让您的开发人员从到进行cherrypick更改。这使您的历史记录保持线性，但 git 将不再跟踪'd 提交来自. 您必须想出另一种方法来跟踪它。baseclient_foocherrypickbase

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