我正处于向我的上级出售 git 的风口浪尖。无论如何，他们正在听我们谈论它。有一件事我不确定，我想看看人们如何处理这个问题。基本上我的问题来自基本理解，即允许一对分支越远，它们就越难合并。
我正在考虑提出这个相当简单的工作流程：假设我有一个主（发布）分支、一个开发分支和主题分支。不同的开发人员正在开发他们单独的主题分支，只要他们觉得他们有工作代码，就会经常将这些主题分支拉到一个中央仓库。定期，当开发人员要求这样做时，维护人员（在我们的组织中，这个人的头衔是“技术主管”）从他们的功能分支合并到开发分支，将其放在临时服务器上并进行测试，一旦功能测试完成，它与 master 合并并推送到生产环境。
这是我的问题。开发人员是否应该定期合并他们的主题分支？这样做可以确保它们都相当干净地合并回 dev 中（或者至少在它们失控之前尽早发现冲突）。我知道我的经理唯一不喜欢的是，这是他们必须做的工作来安抚他们的工具，而不是为项目提供代码。想法？
我们都知道会有冲突。真正的问题是：谁应该解决这些冲突？
如果最接近导致此冲突发生的更改的人是修复它的人，那将是有益的。如果您让维护人员（或其他开发人员）处理此问题，该人可能不知道代码的全部内容。所以是的，开发人员可能应该负责解决合并冲突。这是一个权衡。
您的问题与工作流程有关，您的老板可能不喜欢技术主管正在利用他的时间来解决冲突。否则，这个模型一点也不坏。技术主管的这个角色通常被称为“集成商”，通常涉及解决冲突，这意味着集成商需要了解代码并需要与开发人员进行大量沟通（git 中还有其他工具可以简化这种情况）。
你可以做的是让开发人员不要从服务器推送和拉取他们的主题分支，而是将他们的主题分支保留在本地，并且只有在服务器上拥有例如 master 和 development。如果他们改为从开发中提取，合并他们的东西，在本地解决冲突，并在他们推动开发之前进行本地测试。这样，开发人员可以转而推动开发，而技术负责人可以专注于测试开发并进行其他类型的测试，例如性能测试等。
但是，如果您仍然想要集成者角色，则有一个名为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/
干杯