我的开发团队已经使用颠覆工作了很长时间。管理主干和分支的方式如下：
我们（几乎）总是从主干中释放
每个版本都有自己的分支。
当一个版本准备好QA时，我们将分支合并回主干并为下一个版本创建一个新分支。
开发人员在主干或分支机构中工作，但没有特定于开发人员的分支。
最近，我们进行了一些噩梦合并会议，部分原因是应用程序发生了一些重大变化。这些并不总是顺利进行，并且在质量保证期间有时会出现问题，其中颠覆并未完全合并。
一种解决方案可能是定期将主干更改合并到发布分支中，例如每周一次，以确保最新的主干更改位于分支中。然后可以更接近实时地修复冲突。
您对此问题的体验是什么？有标准的最佳做法吗？另外，你有一个很好的方法来跟踪哪些修订已经合并到分支中（subversion中的体面评论可能会处理这个）。
答案 0 :(得分：15)
首先，在管理代码分支和发布时，我认为没有一个适合所有解决方案。但是从我的角度来谈谈你的一些观点：
是的，我会更频繁地将更改从trunk更新到发布分支。较小的块总是比一个大型集成更易于管理。当然，这意味着您正在使用最新的最稳定的代码。
主动教人们如何合并。进行更改的开发人员应该正在进行（或密切参与）合并。了解它正在采取什么以及它完成后应该是什么样子。我经常看到人们在不知道他们正在做什么以及他们期望的结果的情况下进行整合。
也许你想要一个不是主干的集成分支。这可以每天进行测试，任何问题都会在这里发生，然后再打破后备箱并吓跑每个人。
答案 1 :(得分：12)
所以假设我的模型就在这里：你在一个分支（从主干上）开始对项目进行重大更改，这可能会变得很旧。
你继续在trunk上进行其他开发，它总是拥有'live'软件，因此这些更改是次要更新和错误修复。 当您将纪念性开发分支合并回主干时，您会遇到问题。
您只能使用该模型有效管理2个并发产品版本，这可能已经足够了，但是如果您需要管理3个或4个版本，可能会以其他方式咬你。我可以建议改变你的工作方式吗？
为每个版本分配一个版本分支。这应该从trunk（在任何修订版本）分支。 修改版本分支的唯一方法是合并trunk的修订版。
这意味着您可以主要在主干上工作，而不是在大型开发分支中工作。您还可以将错误修复直接应用于主干 - 因此您没有为下一个版本存储重大集成问题。要发布以前版本的错误修复，只需将所需的主干修订合并到相应的版本分支中。
通过这种方式，您可以保留要在分支中发布的所有内容，但实际上只会发布您满意的内容，因为这是您合并到版本分支的所有内容。
如果需要，您仍然可以使用开发分支，但是您可以将它们作为目标和小目标，可能是单个功能而不是大型项目。
这将允许您以理智的方式管理多个版本，并使用svn的merge-info跟踪每个版本中的内容。
答案 2 :(得分：5)
我们的经验是明确区分：
Trunk仅用于记录稳定发布的版本，我们可以从中进行分支。
在“开发分支”中，我们可以管理重要的更改，包括一些不会在下一个版本中结束的更改（因为太复杂，没有及时准备，取决于其他后期开发，...）
合并分支代表完成发布所需的最后步骤（注意复数）。它发生在会议之后，需要传递的所有功能都经过验证。
我们只合并到“合并分支”，我们肯定会投入生产。我们继续该分支，直到最终版本。
答案 3 :(得分：2)
完全赞同Andy：没有“一刀切”的解决方案，但问题不应该是让你的发布分支更新，而是反过来。
良好的变更控制应该使您的分支不会变得不稳定。应该在发布分支上修复门控问题，然后立即合并到中继。准备好让这个“合并”变得非常重要，释放门控问题甚至可能不存在于主干上，但你需要做任何分析和测试。
这听起来就是你说你在你的树枝上开发，然后在释放之前立即合并到你的行李箱并且只是交叉你的手指。我想知道你这样做会引入多少错误。
答案 4 :(得分：2)
首先，我完全同意之前的回应者的观点，即没有一刀切的解决方案。
在我们的案例中，我们有许多相对较小的应用程序，每个应用程序通常只有一个开发人员。当我们参与协作开发时，往往只有2到4个开发人员。
我们的一般政策是：
安迪也提出了一个重点，需要强调：“主动教人们如何合并。”许多（如果不是大多数）我们的问题似乎都来自于合并不良的做法。