用于缓解主题分支合并冲突的工作流程策略
我正处于向上级销售git的风口浪尖。 无论如何，他们都在听我们谈论它。 有一件事我不确定，我想看看人们如何处理这件事。 基本上我的问题来自于基本的理解，即一对分支越容易得到，他们就越难合并。
我正在考虑提出这个相当简单的工作流程：假设我有一个主（发布）分支，一个开发分支和主题分支。 不同的开发人员正在研究他们各自的主题分支，并将这些主题分支拉到中央回购站，并且他们认为他们有工作代码。 定期地，当开发人员要求这样做时，维护人员（在我们的组织中，该人员拥有“技术负责人”的头衔）从其功能分支合并到开发分支中，然后将其放到分段服务器上并进行测试，一旦功能测试完成后，它会与主人合并并推向生产。
这是我的问题。 开发者是否应该定期合并他们的主题分支？ 这样做可以确保他们能够相当干净地重新合并到开发者中（或者至少在可能发生失控之前尽早捕获冲突）。 我知道我的经理唯一不喜欢的就是，他们需要做的工作是安排他们的工具，而不是将代码交付给项目。 思考？
我们都知道会有冲突。 问题是：谁应该解决冲突？
如果与发生这种冲突的变化最接近的人是修复它的人，那么这是有益的。 如果你让一个维护者处理这个（或者其他一些开发者），那个人可能不知道代码是什么。 所以是的，开发者可能应该为解决合并冲突负责。 这是一种折衷。
你的问题与工作流程有关，你的老板可能不喜欢技术主管正在利用他的时间来解决冲突。 否则，这种模式并不是一件坏事。 技术负责人所担任的角色通常称为“集成人员”，通常涉及解决冲突，意味着集成人员需要了解代码并需要与开发人员进行大量沟通（git中还有其他工具可以简化这种情况）。
你可以做的是让开发人员不要将他们的主题分支从服务器上推送下来，而是将他们的主题分支保留在本地，并且只有例如主服务器和在服务器上开发。 如果他们取而代之的是开发，合并他们的东西，在本地解决冲突，并且在推动开发之前在本地进行测试 。 这样，开发人员可以推动开发，技术主管可以专注于开发测试和进行其他类型的测试，如性能测试等。
但是，如果您仍然希望集成角色，那么有一种名为git rerere的工具。 它使集成商能够定期合并分支，解决冲突，重置以撤销合并，git将自动记录冲突如何解决。 这是减少工作冲突的最佳途径。 你甚至可以用git钩子自动化这个，比如用脚本进行合并，并在发生冲突时通知集成商。
一些阅读：
http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html
http://gitfu.wordpress.com/2008/04/20/git-rerere-rereremember-what-you-did-last-time/
干杯
链接地址: http://www.djcxy.com/p/6921.html上一篇: Workflow strategies for mitigating merge conflicts from topic branches
下一篇: How can I generate Service Model Metadata without rebooting