当错误被修复并合并到主干时，协调每个任务的分支和错误修复，但错误实际上并没有充分“修复”

Question

我最近从 CVS 切换到 Plastic 以进行源代码控制。我们使用 Jira 进行问题跟踪，使用 Plastic 分支将变更集与未解决的问题联系起来。通过切换，我还采用了按任务分支的方法进行开发。在修复重新打开的错误时，这导致了一个有趣的困境（一个新的测试用例发现该错误在迭代/发布测试后没有完全修复）

我已经修复了一个错误，针对它运行了我的测试（当时可用）并且它通过了。我合并了代码，并开发了涉及同一文件的第二个功能。两项更改都在不同的分支上完成，并且都成功合并到主构建分支中。新版本进入 QA，他们发现了一种稍微不同的方法来重现相同的问题（一个新的测试用例）并重新打开错误。原始错误分支不包括添加到同一文件中的新功能，因为它们位于不同的分支上（例如错误 1 ​​修复是功能 2 分支的一部分 [因为此分支是在原始修复合并到构建分支后创建的]，但是新特性 2 的代码不在 bug 1 分支上）

考虑到这种情况：当错误被重新打开并且您使用的是按任务分支的方法时，修复错误的最佳做法是什么？

• 最好在 Jira 中克隆错误以创建新问题
  号，创建一个新分支并像新问题一样重新修复问题？
  [这基本上将新修复基于
  原始修复 + 新功能]（这会使合并变得更加困难
  如果您必须跟踪同一版本的多个修复，则跨版本
  问题？）
• 回到原来的分支会不会更好
  原问题已修复，重新修复，然后再次合并，处理
  每次发生此类事情时都要解决冲突？

注意：

1. 创建分支以与错误跟踪系统 (Jira) 链接，因此 分支名称包括问题编号。
2. 因为这个链接，我不能创建两个同名的分支 除非他们有不同的父母。因此，我可以从原始分支创建第二个分支，但不能从构建分支（原始问题的父级）创建第二个分支

似乎每个任务的分支方法会导致在错误修复和功能之间重复发生冲突解决，直到两者都经过完全测试和解决，因为这些任务分支之间没有合并——只有到主干，它们会两者都不断地“过时”。

我敢打赌，对于单个开发人员来说，这不会经常发生，但在较大的团队中可能会更频繁地发生，即使它不是专门在错误和功能之间（可以想象，两个功能可能会影响同一个功能）文件，在发布前的构建/测试周期的生命周期内导致额外的冲突解决）

这个过程的工作方式与团队过去使用 CVS 的方式几乎相反，因此我试图找到“正确”的方式来做这件事，以尽量减少推进新模型的痛苦。 以前，我只会从上次构建中获取最新更改并进行新修复——因此，避免任何冲突解决问题（但我没有得到每个任务分支的好处）。

现在，我必须考虑“原始”修复是在哪个分支上完成的，如果那是“新”修复需要去的正确位置，以使问题跟踪系统与更改集列表保持同步.

Answer 1

对于您所询问的情况，有多种替代方案和解决方案，我将针对我能想到的每种情况解释我最喜欢的一种：

(1) 2 个分支集成在“发布分支”AKA“/main”中，您不想减去它们。

在这种情况下，您必须在 Jira 中创建一个新任务，将其链接到导致问题的任务，并在出现这种情况时将其设置为回归。

现在您在 Jira 中有一个新任务，您可以在 Plastic 中创建一个新分支。这个新分支将基于“/main”分支中的最后一个 cset/label。

开发修复程序并将其集成到下一个版本中，当它的所有 QA 都处于绿色状态时。

（2）任务不能留在“发布分支”，必须减去

您将对“/main”分支中创建的变更集执行减法合并，因此“发布分支”将恢复为稳定点。

重新打开 Jira 任务，甚至重新估计。

开发人员将在任务分支中继续工作，以使代码满足新的需求。

一旦任务完成，每个任务的常规分支循环就会继续。

希望对你有帮助！