Dan*_*Ray 7 git branching-and-merging git-workflow
我正在向我的高层阶段出售git.无论如何,他们正在听我们谈论它.有一点我不确定,我想看看人们如何处理这件事.基本上我的问题来自于基本的理解,即允许一对分支越远,它们就越难合并.
我正在考虑提出这个相当简单的工作流程:假设我有一个主(发布)分支,一个开发分支,以及主题分支.不同的开发人员正在研究他们各自的主题分支,将这些主题分支拉到中央仓库并将其推送到中央仓库,因为他们认为自己有工作代码.定期,当开发人员要求这样做时,维护者(在我们的组织中,该人员具有"技术主管"头衔)从他们的功能分支合并到开发分支中,将其放在登台服务器上并进行测试,并且一旦功能完成测试完成后,它与master合并并推向生产.
这是我的问题.开发者应该定期合并他们的主题分支吗？这样做可以确保他们所有人都可以相当干净地合并回dev(或者至少在他们失控之前抓住冲突).我知道我的经理唯一不喜欢的就是,他们必须做的工作是安抚他们的工具,而不是努力为项目提供代码.思考？
我们都知道，会有冲突。真正的问题是：谁应该解决冲突？
如果最接近导致冲突发生的变化的人是解决冲突的人，那将是有益的。如果您让维护人员处理此问题（或其他开发人员），那么该人可能不知道代码的全部内容。所以是的，开发人员可能应该负责解决合并冲突。这是一个权衡。
您的问题与工作流程有关，您的老板可能不喜欢技术主管利用他的时间来解决冲突。否则这个模型一点也不坏。技术主管的这个角色通常被称为“集成商”，通常涉及解决冲突，这意味着集成商需要了解代码并需要与开发人员进行大量沟通（git 中还有其他工具可以简化这种情况） ）。
您可以做的是让开发人员不要从服务器上推送和拉取他们的主题分支，而是将他们的主题分支保留在本地，并且仅在服务器上拥有例如 master 和development 。如果他们从开发中拉出，合并他们的东西，在本地解决冲突，并在推动开发之前在本地进行测试。这样，开发人员可以推动开发，而技术主管可以专注于测试开发并进行其他类型的测试，例如性能测试等。
但是，如果您仍然想要集成商角色，可以使用一个名为git rerere的工具。它使集成商能够定期合并分支、解决冲突、重置以撤消合并，并且 git 将自动记录冲突的解决方式。这是最小化工作解决冲突的一个非常好的方法。您甚至可以使用 git hook 自动执行此操作，例如使用脚本进行合并，并在发生冲突时通知集成商。
一些阅读：
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/
干杯