我最近从 CVS 切换到 Plastic 进行源代码控制。我们使用 Jira 进行问题跟踪，使用 Plastic 分支将变更集与未解决的问题联系起来。通过切换，我还采用了按任务分支的方法进行开发。在修复重新打开的错误时，这导致了一个有趣的困境（一个新的测试用例发现该错误在迭代/发布测试后没有完全修复）
我已经修复了一个错误，针对它运行了我的测试（当时可用）并且它通过了。我合并了代码，并开发了涉及同一文件的第二个功能。两项更改都在不同的分支上完成，并且都成功合并到主构建分支中。新版本进入 QA，他们发现了一种稍微不同的方式来重现相同的问题（一个新的测试用例）并重新打开错误。原始错误分支不包括添加到同一文件中的新功能，因为它们位于不同的分支上（例如错误 1 修复是功能 2 分支的一部分 [因为此分支是在原始修复合并到构建分支后创建的]，但新功能 2 代码不在 bug 1 分支上）
鉴于这种情况：当重新打开错误并且您使用的是按任务分支的方法时，修复错误的最佳实践是什么？
- 克隆 Jira 中的错误以创建新问题
编号、创建新分支并像新问题一样重新修复问题会更好吗？
[这基本上将新修复基于原始修复+新功能的组合]（ 如果您必须跟踪同一问题的多个修复，
这是否会使跨版本合并变得更加困难 ？） - 回到
原来问题被修复的原始分支，并重新修复它，然后再次合并，
每次发生这种事情时处理冲突解决会更好吗？
笔记：
- 创建分支以与错误跟踪系统 (Jira) 链接，因此分支名称包含问题编号。
- 由于这个链接，我不能创建 2 个同名的分支，除非它们有不同的父级。因此，我可以从原始分支创建第二个分支，但不能从构建分支（这是原始问题的父级）
似乎每个任务方法的分支会导致在错误修复和功能之间反复发生冲突解决，直到两者都经过完全测试和解决，因为这些任务分支之间没有合并 - 仅到主干，它们都将连续彼此“过时”。
我敢打赌这对于单个开发人员来说不会经常发生，但它可能会在更大的团队中更频繁地发生，即使它不是专门在错误和功能之间（可以想象，两个功能可能会影响同一个文件（s )，在发布之前的构建/测试周期的生命周期内导致额外的冲突解决)
这个过程的工作方式几乎与团队过去使用 CVS 的方式相反，所以我试图找到“正确”的方式来完成它，以尽量减少推进新模型的痛苦。以前，我只会从上次构建中获取最新更改并进行新修复——因此，避免任何冲突解决问题（但我没有得到每个任务分支的好处）。
现在，我必须考虑“原始”修复是在哪个分支上完成的，如果那是“新”修复需要去的正确位置，以使问题跟踪系统与更改集列表保持同步。