我与一个中型开发团队合作，他们都在开发一种产品。开发人员编写代码来解决功能或错误修复故障单，然后将其检入我们的主要开发分支（在Subversion中）。一旦QA人员对票证进行了测试和验证，我就将其合并到主干中。我通常会手动执行此操作，因为很多票证都会进行多次修订，这些修订并不总是顺序的，可能会同时修复几张票。
我确信有一件事可以帮助开发人员每次修订只签一张票。我们使用Jira来跟踪我们的任务，因此每个Subversion修订都应该在日志中有一个Jira问题ID - 当我合并代码时，我会去寻找包含我正在合并的问题的修订。
还有其他方法可以更好地管理这个吗？每个机票和问题都有其他团队从主干分支出来吗？正如我所说，我们有一个主要的开发分支，至少部分是因为我们正在快速构建许多新功能，而且我想如果我们为每张票制作一个分支，我们很快就会找到几十个分支。
答案 0 :(得分：4)
这个问题与DVCS无关。这是一个过程问题，而不是技术问题。以下是我对很多人正在做的事情的看法，以及ClearCase UCM推广的过程：
/project/trunk
/branches
/release-1.0-JIRA1023
/release-1.0-darthcoder-JIRA1029
/darthcoder-JIRA1029
/branches/release-1.0-tfix <- This is the patch trunk. Main trunk is future dev
当我修复我的错误时，我会将其提升回主干，或者我正在尝试修复的特定版本。我将合并到release-1.0-tfix和trunk，因为它需要在几个地方修复。当我完成后，我删除分支并继续下一个问题。所以我有两个代码分支，其中包含JIRA修复程序，而我正在测试它并处理问题（如果修复程序非常不同）。
但是除非运行成功的构建/测试周期，否则不会将任何内容提升为trunk或-tfix树，并且它具有用于跟踪的JIRA属性。这样，您可以将每个单独的修复程序绑定到开发人员，分支，并验证是否正确修复了问题。此问题也不会丢失（哦，JIRA1029是否已经进入1.2版本？你可以通过在你的存储库中查找JIRA1029来验证这一点。你永远不需要GUESS，这就是使软件开发可重复的原因并让我们关闭错误== 0。
答案 1 :(得分：0)
您是否正在处理并发版本？对于我没有多少并发版本开发的项目（通常是＆lt; 10 devs），我们在trunk中工作。单一登记应仅适用于单张票。如果碰巧修复了另一张票，则会更新票证并标记为测试。
你为什么要合并？这是您的代码审查或确保构建不被破坏的方式。我个人会建立一些持续集成并跳过这一步。您应该能够相信您的开发人员不要破坏构建，并且如果他们这样做，CI会捕获它们。