我们有一个基础系统,为每个客户进行了定制。基础系统存放在自己的代码库中,每个客户都有自己的代码库(最初是从基础系统克隆而来)。
目标是能够向基础系统添加错误修复/功能,并按需传播到客户端。
到目前为止,工作流程如下:
- 为基础系统的修复/功能创建提交/主题分支:(在基础系统上,主分支)`git commit -m "修复管理员拼写错误"` - 将这些更改合并到客户端:(在客户端上,主分支)`git merge base/master`。显然,这包括解决基础系统和客户端自定义之间的任何冲突。 - 推送合并后的更改到客户端的代码库:(在客户端上,主分支)`git push origin master` - 我们的惯例是使用 rebase 拉取(以保持历史记录可读性)。因此,接下来不同的开发人员在客户端项目上工作时会(在客户端上,主分支)`git pull --rebase origin master`
正是在这个点上,我们遇到了拉取/变基的重大问题。开发人员在从基础系统合并到客户端之后执行的拉取/变基过程中会出现冲突。而且不仅仅是一些冲突,而是很多(对于重放的许多提交?),而且通常是特定开发人员从未接触过的代码。我认为这是不合理和不可持续的。
那么,这里最好的解决方案是什么?
我的唯一想法是停止在拉取时使用变基,并处理混乱且难以阅读的日志,但我不想这样做。这些客户项目可以持续数年,我希望将来仍然能够理解基础系统合并的某些内容。
目标是能够向基础系统添加错误修复/功能,并按需传播到客户端。
到目前为止,工作流程如下:
- 为基础系统的修复/功能创建提交/主题分支:(在基础系统上,主分支)`git commit -m "修复管理员拼写错误"` - 将这些更改合并到客户端:(在客户端上,主分支)`git merge base/master`。显然,这包括解决基础系统和客户端自定义之间的任何冲突。 - 推送合并后的更改到客户端的代码库:(在客户端上,主分支)`git push origin master` - 我们的惯例是使用 rebase 拉取(以保持历史记录可读性)。因此,接下来不同的开发人员在客户端项目上工作时会(在客户端上,主分支)`git pull --rebase origin master`
正是在这个点上,我们遇到了拉取/变基的重大问题。开发人员在从基础系统合并到客户端之后执行的拉取/变基过程中会出现冲突。而且不仅仅是一些冲突,而是很多(对于重放的许多提交?),而且通常是特定开发人员从未接触过的代码。我认为这是不合理和不可持续的。
那么,这里最好的解决方案是什么?
我的唯一想法是停止在拉取时使用变基,并处理混乱且难以阅读的日志,但我不想这样做。这些客户项目可以持续数年,我希望将来仍然能够理解基础系统合并的某些内容。
origin/master
,然后立即从那里拉取?这样做不是什么都不会发生吗? - svick