Closed 。这个问题需要多问focused 。目前不接受答案。
我与一个中型开发团队合作，他们都致力于同一个产品。开发人员编写代码来解决功能或错误修复问题，然后将其签入我们的主要开发分支（在 Subversion 中）。一旦 QA 人员对票证进行了测试和验证，我就会将其合并到主干中。我通常手动执行此操作，因为许多票证跨越多个修订，这些修订并不总是连续的，并且可能同时包含多个票证的修复。
我确信会有所帮助的一件事是鼓励开发人员每次修订只签入一张票。我们使用 Jira 来跟踪我们的任务，因此每个 Subversion 修订版都应该在日志中包含一个 Jira 问题 ID - 当我合并代码时，我会寻找包含我要合并的问题的修订版。
还有其他方法可以更好地处理这个问题吗？其他团队是否会针对每张票证和问题从主干中分支出来？正如我所说，我们有一个主要的开发分支，至少部分是因为我们正在快速构建许多新功能，而且我想如果我们为每张票创建一个分支，我们很快就会拥有数十个分支。
这个问题与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和主干，因为它需要在几个地方进行修复。完成后，我删除该分支并继续下一期。因此，当我测试它并解决问题时（如果修复有很大差异），我有两个代码分支，其中包含 JIRA 修复。
但是，除非运行成功的构建/测试周期，否则不会将任何内容提升到主干或 -tfix 树，并且它具有用于跟踪的 JIRA 属性。通过这种方式，您可以将每个单独的修复与开发人员、分支联系起来，并验证问题是否得到正确修复。而且这些问题也不会丢失（哦，JIRA1029 进入了 1.2 版吗？那么您可以通过在存储库中查找 JIRA1029 来验证这一点。您永远不必猜测，这就是使软件开发可重复并让我们更接近错误的原因== 0。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
