我正在向我的高层人员出售git。无论如何，他们正在听我们谈论它。有一点我不确定，我想看看人们如何处理这件事。基本上我的问题来自于基本的理解，即允许一对分支越远，它们就越难合并。
我正在考虑提出这个相当简单的工作流程：假设我有一个主（发布）分支，一个开发分支，以及主题分支。不同的开发人员正在研究他们各自的主题分支，将这些主题分支拉到中央仓库并将其推送到中央仓库，因为他们认为自己有工作代码。定期，当开发人员要求这样做时，维护者（在我们的组织中，该人员具有“技术主管”头衔）从他们的功能分支合并到开发分支中，将其放在登台服务器上并进行测试，并且一旦功能完成测试完成后，它与主人合并并推向生产。
这是我的问题。开发者应该定期合并他们的主题分支吗？这样做可以确保他们所有人都可以相当干净地合并回dev（或者至少在他们失控之前抓住冲突）。我知道我的经理唯一不喜欢的就是，他们必须做的工作是安抚他们的工具，而不是努力为项目提供代码。想法？
答案 0 :(得分：3)
我们都知道会有冲突。问题是：谁应该解决冲突？
如果最接近发生此冲突的变更的人是修复它的人，那将是有益的。如果你让维护者处理这个（或其他一些开发者）那个人可能不知道代码是什么。所以是的，开发者应该负责解决合并冲突。这是一种权衡。
您的问题与工作流程有关，您的老板可能不喜欢技术主管利用他的时间来解决冲突。否则这个模型根本不是坏的。技术主管的这个角色通常被称为“集成商”，通常涉及解决冲突，这意味着集成商需要了解代码并需要与开发人员进行大量沟通（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/
干杯