我们有一个为每个客户定制的基础系统。基础存在于自己的存储库中，每个客户端都存在于自己的存储库中（最初是从基础克隆的）。
目标是能够根据需要向基础添加错误修复/功能，可以将其传播给客户端。
到目前为止，工作流程如下：
- 为基本修复/功能制作提交/主题分支：（基于基础，主）
git commit -m "Fix admin typo" - 将这些更改合并到客户端： (on client, master)
git merge base/master。显然，这包括修复基础和客户端自定义之间的任何冲突。 - 将合并推送到客户端的原点：（在客户端，主控）
git push origin master - 我们的约定是使用 rebase 进行拉取（以保持历史可读性）。因此，在客户端项目上工作的不同开发人员将（在客户端，主控）
git pull --rebase origin master
正是在这一点上，我们遇到了 pull/rebase 的重大问题。在从基础合并到客户端后，开发人员会在 pull/rebase 中遇到冲突。而且它不仅仅是一些冲突，还有很多（对于许多被重放的提交？），并且通常是特定开发人员甚至从未接触过的代码。我认为这是不合理和不可持续的。
这里最好的解决方案是什么？
我唯一的想法是在拉取和处理草率和难以阅读的日志时停止使用 rebase，但我宁愿不必这样做。这些客户项目可以持续多年，我希望将来能够从基础系统合并中获得一些意义。