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

Question

一些背景知识：

目前正在CVS上并希望转向Git。我们每个月左右为复杂的自定义内部平台做计划发布。

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

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

（我们可以同时处理六个计划发布的版本）。

我们还指定了项目分支机构，用于目前尚未发布日期的大型项目。当日期已知时，它们最终会合并到选定的计划发布分支中。

每个版本都非常大（许多功能），因为版本需要中断，我们不能经常使用它们，我们确实可以每个月左右批准一次发布停机时间。

随之而来的是合并冲突。我们有一个CVS报告，提供了要完成的手动合并列表，我们在几个开发人员之间分配了工作。用Git做同样的事情 - 在多个开发人员之间将合并工作从一个分支拆分到另一个分支（导致很多冲突）？

编辑：

这就是我最终做的事情（注意我们使用Atlassian Stash / BitBucket Server进行拉取请求/代码审查）：

• 合并守护程序：创建一个新的＆＃34;手动合并＆＃34;来自目标分支的分支
• 合并守护程序：开始合并以获取冲突列表
• 合并守护程序：通知管理员并等待解决冲突
• 经理：划分开发者之间的冲突
• 开发人员：每个开发人员创建并检出＆＃34;功能＆＃34;从合并分支分支，然后开始将源标记合并到其功能分支 - 它们在其环境中获得冲突。它们仅针对它们负责的文件解决冲突，然后执行软重置以中止合并，并仅提交它们解析的文件。然后他们将他们的功能分支（与评论）合并到＆＃34;手动合并＆＃34;分支。
• 合并守护程序：一旦开发人员解决了冲突，请查看＆＃34;手动合并＆＃34;分支（仅更改的文件）。此时应解决所有手动冲突。提交并推送。

Answer 1

假设您的开发人员各自拥有自己的存储库克隆，则无法在所有这些克隆的同一分支中拆分单个合并和冲突解决方案。当开发人员在其分支上执行git merge并遇到冲突时，合并仍然在进行中＆＃34;正在进行中＆＃34; （因此，不能进行进一步的提交），直到该分支中的所有冲突都得到解决并且合并通过合并提交完成。

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

如果您真的必须坚持使用现有的分支设置，并且您可以干净地对冲突解决方案进行分区，而无需团队成员踩到每个脚趾，您可以尝试在共享计算机上拥有一个公共存储库，每个人都可以访问（比如，通过ssh）。只需执行git merge，输出中确定的冲突就是您的报告： - ）

一般情况下，通过经常合并，避免让分支彼此偏离太远。合并节目，特别是在发布日期附近，可能会非常紧张和容易出错。

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

Answer 2

这是一种方法：

1. 开始合并
2. 使用git diff --name-only --diff-filter=U打印合并冲突列表
3. 在开始合并之前使用git reset --hard HEAD重置为

但是，最好不要让这些事情积累起来，而不是进行大规模的冲突解决，这可能会引入更多的错误。

您可以通过从7100而不是7000开始master分支来实现此目的，并定期将7000重新绑定或合并到7100。

您也可以通过将每个功能保留在不同的分支（feature-a，feature-b等）上来实现此目的，并在您接近某个版本时将它们合并为一个确切地知道它会在里面。

Answer 3

也许Gerrit，松散地说＆＃34; Git服务器＆＃34;，可以帮助你：它有更改的概念。每个更改都由用户（通常是开发人员）拥有。开发人员可能会将某个功能推送到将来的发布分支，但它不会直接应用于分支（例如，通过推送到魔术分支 refs/for/release-7100）。

只要有人（例如发布经理）决定真正接管此功能，就可以提交。如果发布分支在此期间分歧很大，开发人员将收到通知并需要解决冲突。推送已解决的冲突后，最终可以再次提交更改。

我自己没有试过这个工作流程，但我想这可行。无论如何，我认为值得一试......; - ）

Answer 4

哦，天哪，我们的团队最近经历了这个，并且最初对此限制感到沮丧。从分支“源”合并到“目的地”，我们的（诚然是hackey）解决方案是：

1. 对于每个团队成员，我们将“目的地”的副本克隆到我们的个人计算机上作为“destinationMerging”。
2. 然后我们每个人都在destinationMerging目录中做了'git merge source'
3. 这产生了一个冲突文件列表。我们建立了一个我们所有人都可以编辑的冲突清单。 （您可以在Google文档中执行此操作。）
4. 我们开始逐个文件地合并冲突。当我们其中一个人开始处理新文件时，我们会从列表中查看它。检查意味着“它已完成或正在处理”。
5. 当我们完成一个文件时，我们会将其复制到原始的“目标”仓库并提交/推送这些更改。
6. 当所有冲突的文件都被解析并推送时，一个人从“目的地”做了一次拉动以获得所有更改并继续进行'git merge source'

绝对不优雅，但它完成了工作。我理解“最好不要让这些东西积累起来”但是当他们这样做时，他们需要修复，这就是我们能够以分布式方式做的事情。