缓解主题分支合并冲突的工作流程策略
我正准备将 git 卖给我的上级。无论如何，他们正在听我们谈论这件事。有件事我不确定，我想看看人们如何处理这个问题。基本上，我的问题来自于这样的基本理解：一对分支允许的距离越远，它们就越难合并。
我正在考虑提出这个相当简单的工作流程：假设我有一个主（发布）分支、一个开发分支和从中分支出来的主题分支。不同的开发人员正在处理各自的主题分支，只要他们认为自己有工作代码，就会将这些主题分支拉动和推送到中央存储库。定期地，当开发人员要求这样做时，维护者（在我们的组织中，该人拥有“技术主管”的头衔）从他们的功能分支合并到开发分支，将其放在临时服务器上并进行测试，一旦该功能测试完成后，它与 master 合并并推送到生产环境。
这是我的问题。开发人员是否应该定期合并他们的主题分支？这样做将确保它们都能相当干净地合并回开发中（或者至少在冲突失控之前尽早捕获冲突）。我知道我的经理会不喜欢的唯一一件事是，这是他们必须做的工作来安抚他们的工具，而不是向项目交付代码。想法？
I'm right on the cusp of selling git to my higher-ups. They're listening to us talk about it, anyway. There's one thing I'm unsure of, and I'd like to see how people deal with this. Basically my question comes from the fundamental understanding that the further apart a pair of branches are allowed to get, the harder they are to merge.
I'm considering proposing this fairly simple workflow: Say I have a master (release) branch, a development branch, and topic branches off of that. Different developers are working on their separate topic branches, pulling and pushing those topic branches to a central repo as often as they feel they have working code. Periodically, when asked to do so by a developer, the maintainer (in our organization that person has the title "technical lead") merges from their feature branch into the development branch, that's put on a staging server and tested, and once the feature test complete, it's merged with master and pushed to production.
Here's my question. Should the devs merge their topic branches periodically? Doing so would ensure that they'll ALL merge back into dev fairly cleanly (or at least catches conflicts early before they can get out of hand). The only thing that I know my manager is going to dislike about that is, that's work they have to do to placate their tool, rather than work to deliver code to the project. Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们都知道，会有冲突。真正的问题是：谁应该解决冲突？
如果最接近导致冲突发生的变化的人是解决冲突的人，那将是有益的。如果您让维护人员处理此问题（或其他开发人员），那么该人可能不知道代码的全部内容。所以是的，开发人员可能应该负责解决合并冲突。这是一个权衡。
您的问题与工作流程有关，您的老板可能不喜欢技术主管利用他的时间来解决冲突。否则这个模型一点也不坏。技术主管的这个角色通常被称为“集成商”，通常涉及解决冲突，这意味着集成商需要了解代码并需要与开发人员进行大量沟通（git 中还有其他工具可以简化这种情况） ）。
您可以做的是让开发人员不要从服务器上推送和拉取他们的主题分支，而是将他们的主题分支保留在本地，并且只在服务器上拥有例如master和develop。如果他们从开发中拉出，合并他们的东西，在本地解决冲突，并在推动开发之前本地测试。这样，开发人员可以推动开发，而技术主管可以专注于测试开发并进行其他类型的测试，例如性能测试等。
但是，如果您仍然想要集成商角色，有一个名为 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/
干杯
We all know that there will be conflicts. The question is really: Who should resolve the conflicts?
It's beneficial if the person closest to the changes that made this conflict happen is the one fixing it. If you let a maintainer handle this (or some other dev) that person might not know what the code is all about. So yes, the devs should probably be responsible for solving merge conflicts. It's a trade off.
Your problem is related to the workflow and that your boss might not like that the technical lead is using his time to solve conflicts. Otherwise this model is not at all a bad one. This role that the technical lead has is often called "integrator" and often involves resolving conflicts and means the integrator needs to know about the code and needs to communicate a lot with the devs (there are also other tools in git that can simplify this scenario).
What you could do, is to let the devs not push and pull their topic branches from the server, but instead keep their topic branches locally and only have e.g. master and develop on the server. If they instead pull from develop, merge their stuff, resolve conflicts locally, and also test locally before they push up develop. That way the devs can instead push up develop and the technical lead can focus on testing develop and do other types of testing like performance testing etc.
However, if you still want the integrator role, there is a tool called git rerere. It enables the integrator to periodically merge branches, solve conflicts, reset to undo the merge and git will automatically record how the conflict was resolved. This is a very good way to minimize the work solving conflicts. You could even automate this with a git hook, e.g. do the merge with a script and just notify the integrator if a conflict has happened.
Some reading:
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/
Cheers