将多个Mercurial分支合并在一起

Pau*_*aul 3 mercurial branching-and-merging

我有一群开发人员使用分支机构修复bug.我的需要:自动化(或有办法)将所有这些分支合并到一个主分支中的最佳方法是什么,"默认".

谢谢

ang*_*son 6

注意:这是我的观点,这里可以有多个意见,但至少在这里理解我的观点并决定你想要它与众不同.

首先,这里缺少一些东西,我认为从长远来看这将为您带来工作流问题.

合并不是应该被跳过或委托给其他人的东西,在这些分支中工作的开发人员应该合并自己.他们,可能只有他们,会知道他们做了什么,以及如何解决合并冲突.

无论如何,完全自动化,这是行不通的.

这是开发人员应该使用的工作流程(在我看来).

例如,每天早上,分支上的开发人员应定期检查构建服务器以确保构建默认分支.如果它(它应该!),它们默认分支合并到它们自己的分支.

这有三个主要好处:

  1. 他们总是在自己的分支中拥有最新的代码,并且不会陷入解决已经在另一个分支中修复的已知错误的问题
  2. 它们不断地处理来自其他分支的合并冲突,而冲突很小,并且这些变化在开发者的头脑中仍然是新鲜的.
  3. 由于你每天处理合并冲突(如果有的话),当你到达那个分支的生命周期时,它几乎完全与默认分支合并,所以将它合并回默认分支的工作现在应该便宜,如果不是免费的话.

在某些时候,他们被阅读以将他们的工作重新集成到默认分支中(或者是定期的,即部分发布新功能,或者最后,一切都已完成),然后他们又将另一个合并默认返回到他们的自己的分支.这可确保任何延迟合并冲突由该团队在其分支中处理,然后再将其发布给其他开发人员.

当他们处理由于该合并引起的任何合并冲突时,他们可以合并另一个方向,从其分支返回到默认.此时,除非有人在此期间设法将任何冲突的更改合并/推送到默认值,否则根本不存在合并冲突.

这样做可以确保:

  1. 进行合并的开发人员可以进行合并培训
  2. 进行更改的开发人员仍然会记忆中的这些更改
  3. 您可以通过经常进行合并冲突来分摊与合并冲突相关的工作,并将其分成小部分.
  4. 在项目结束时,你没有得到一个大的合并 - "周",当时每个人都忘记了所有的变化,他们为什么要完成以及谁做了他们

如果其中任何一项不清楚,请发表评论,我会相应地更新/编辑.