Git pull with rebase 导致过度冲突。我怎样才能修复我们的工作流程？

Question

我们有一个为每个客户定制的基础系统。 base 位于其自己的存储库中，每个客户端位于其自己的存储库中(最初是从 base 克隆的)。

目标是能够向基础添加错误修复/功能，可以按需传播给客户。

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

• 为基础修复/功能创建提交/主题分支:(在基础上，master)git commit -m "Fix admin typo"
• 将这些更改 merge 到客户端:(在客户端，master 上)git merge base/master。显然，这包括解决基础和客户定制之间的任何冲突。
• 将 merge 推送到客户端的来源:(在客户端，master 上)git push origin master
• 我们的惯例是使用 rebase 进行 pull (以保持历史可读)。因此，在客户端项目上工作的不同开发人员将(在客户端，master 上)git pull --rebase origin master

正是在这一点上，我们遇到了 pull/rebase 的重大问题。在从 base merge 到 client 之后，开发人员在 pull/rebase 中遇到冲突。而且它不仅仅是一些冲突，它有很多(对于许多正在重放的提交？)，并且通常是特定开发人员从未接触过的代码。我认为这是不合理和不可持续的。

最好的解决方案是什么？

我唯一的想法是在 pull 和处理草率且难以阅读的日志时停止使用 rebase ，但我宁愿不必这样做。这些客户项目可以持续多年，我希望将来仍然能够从基础系统 merge 中获得一些意义。

Answer 1

让我在你的 repo 协议(protocol)中直接说明这一点:

1. 主项目是独立的，叫做base
2. 每个客户端项目都是从base克隆的，只 pull 更新
3. 开发人员从公共(public) client_foo 存储库工作，并向/从该存储库push/pull

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

如果每个客户端存储库只有一个开发人员，那么这可能会奏效。我假设情况并非如此。

选项:

1. 继续做您正在做的事情，但是当开发人员将重新设置基础的 client_foo 分支(带有新的 base 提交)推送回公共(public) client_foo repo ，其他所有人都必须在 origin/master 上执行 reset --hard。如果他们将所有未推送的更改保存在私有(private)主题分支中，那么他们必须将这些更改rebase 回到新的 client_foo/master。

2. 让您的开发merge 从base 更改为client_foo。这将为您提供 client_foo 上的 merge 提交，您说您正试图避免，但它会给您最准确的历史记录。当您的开发人员执行“pull --rebase”时，您应该不会再得到现在的一长串冲突。

3. 让您的开发人员cherrypick 将更改从base 转移到client_foo。这使您的历史保持线性，但 git 将不再跟踪 cherrypick 的提交来自 base。你必须想出另一种方法来跟踪它。

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