Git pull使用rebase导致冲突过多。我该如何修复我们的工作流程？

Question

我们有一个基础系统，为每个客户进行了定制。基础系统存放在自己的代码库中，每个客户都有自己的代码库（最初是从基础系统克隆而来）。

目标是能够向基础系统添加错误修复/功能，并按需传播到客户端。

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

- 为基础系统的修复/功能创建提交/主题分支：（在基础系统上，主分支）`git commit -m "修复管理员拼写错误"` - 将这些更改合并到客户端：（在客户端上，主分支）`git merge base/master`。显然，这包括解决基础系统和客户端自定义之间的任何冲突。 - 推送合并后的更改到客户端的代码库：（在客户端上，主分支）`git push origin master` - 我们的惯例是使用 rebase 拉取（以保持历史记录可读性）。因此，接下来不同的开发人员在客户端项目上工作时会（在客户端上，主分支）`git pull --rebase origin master`

正是在这个点上，我们遇到了拉取/变基的重大问题。开发人员在从基础系统合并到客户端之后执行的拉取/变基过程中会出现冲突。而且不仅仅是一些冲突，而是很多（对于重放的许多提交？），而且通常是特定开发人员从未接触过的代码。我认为这是不合理和不可持续的。

那么，这里最好的解决方案是什么？

我的唯一想法是停止在拉取时使用变基，并处理混乱且难以阅读的日志，但我不想这样做。这些客户项目可以持续数年，我希望将来仍然能够理解基础系统合并的某些内容。

- Ben Crouse

---

你推送到 origin/master，然后立即从那里拉取？这样做不是什么都不会发生吗？ - svick

@svick - 在这个例子中，一个开发人员推送合并，另一个开发人员进行拉取。 - Ben Crouse

Answer 1

让我来解释一下你的仓库问题：

1. 主项目叫做“base”，是单独的。 2. 每个客户端项目都是从“base”克隆的，只拉取更新。 3. 开发人员从公共“client_foo”仓库工作，然后进行“推送/拉取”。

由于有一个开发人员正在将“client_foo”分支重新定位到来自“base”仓库的新提交并将其推回“client_foo”，这将导致所有其他使用“client_foo”的开发人员在尝试进行下一次拉取时出现故障。因此，您不能这样做，并期望git自动处理它。

如果每个客户端仓库只有一个开发人员，那么也许可以这样做。但我觉得这不是情况。

选项：

1. 继续按原来的方法进行操作，但当开发人员将重新基于“base”仓库的新提交的“client_foo”分支推回公共“client_foo”仓库时，其他人必须对“origin/master”执行“reset --hard”。如果他们在一个私有主题分支中保留了所有未push的更改，则还必须将这些更改“rebase”回新的“client_foo/master”上。 2. 让开发人员将更改从“base”合并到“client_foo”上。这将在“client_foo”上产生一个合并提交，你之前说你想避免这个，但它将给你最准确的历史记录。当你的开发人员进行“pull --rebase”时，你不再需要像现在一样获得冗长的冲突列表。 3. 让开发人员从“base”中“cherrypick”更改到“client_foo”上。这会使你的历史记录保持线性，但git将不再跟踪“cherrypick”的提交来自于“base”。你必须想出另一种方法来跟踪它。

我建议选择第2个选项，因为这才是git应该运行的方式。但其他人可能会想到更好的非显而易见的解决方案。

- cmcginty