git - 使用 Git，是否可以为多个开发人员之间的单个 merge 拆分 merge 冲突解决方案？

Question

一些背景:

目前使用 CVS 并希望迁移到 Git。我们每个月左右都会为复杂的自定义内部平台进行计划发布。

在当前的开发工作流程中，我们有多个分支，一个用于我们计划的每个版本，例如:

• 第 7000 版，可能会在 5 月发布
• 7100 版，可能会在 8 月发布
• 7200 版，可能会在 9 月发布

(我们可以同时处理六个计划中的版本)。

我们还为目前没有发布日期的大型项目命名了项目分支。当日期已知时，它们最终会 merge 到选定的计划发布分支中。

每个版本都非常大(许多功能)，因为发布需要中断，我们不能太频繁，我们实际上可以每个月左右获得发布停机一次的批准。

随之而来的是 merge 冲突。我们有一份 CVS 报告，其中提供了要完成的手动 merge 列表，我们将工作分配给了几个开发人员。有什么方法可以用 Git 做同样的事情 - 在多个开发人员之间拆分 merge 工作以从一个分支 merge 到另一个分支(导致许多冲突)？

编辑:

这就是我最终所做的(请注意，我们使用 Atlassian Stash/BitBucket Server 进行 pull 请求/代码审查):

• merge 守护进程:从目标分支创建一个新的“手动 merge ”分支
• merge 守护进程:开始 merge 以获取冲突列表
• merge 守护进程:通知管理人员并等待冲突解决
• 经理:解决开发人员之间的冲突
• 开发人员:每个开发人员创建并从 merge 分支中 check out “功能”分支，然后开始将源标记 merge 到他们的功能分支 - 他们在他们的环境中遇到冲突。他们只解决他们负责的文件的冲突，然后进行软重置以中止 merge ，并只提交他们解决的文件。然后他们将他们的功能分支(经过审核) merge 到“手动 merge ”分支。
• merge 守护程序:开发人员解决冲突后，从“手动 merge ”分支检查修改后的文件(仅更改的文件)。此时应该解决所有手动冲突。 promise 并 push 。

Answer 1

假设您的每个开发人员都有自己的存储库克隆，则无法在所有这些克隆的同一分支中拆分单个 merge 和冲突解决工作。当开发人员在她的分支上执行 git merge 并遇到冲突时， merge 将保持“进行中”(因此，无法进行进一步的提交)，直到解决该分支中的所有冲突并且 merge 通过 merge 提交完成。

也就是说，您仍然可以指派每个开发人员在他自己的克隆存储库中的不同分支上解决冲突；只是不是单个分支上的多个开发人员。

如果你真的必须坚持现有的分支设置，并且你可以干净地划分冲突解决工作而无需团队成员踩到每个脚趾，你可以尝试在共享机器上拥有一个公共(public)存储库，每个人都可以访问(例如，通过 ssh)。只需执行 git merge，输出中确定的冲突就是您的报告:-)

通常，通过经常 merge 它们来避免让分支彼此偏离太远。进行 merge 盛宴，尤其是在临近发布日期时，可能会非常紧张且容易出错。

关于您对由于严格的 SLA 限制发布周期的评论的旁注，您是否考虑过可能有助于减少停机时间和降低风险的不同发布技术，例如蓝/绿部署或集群策略(适合您的产品)？