在修复错误并将其合并到主干时，协调每个任务的分支和错误修复，但该错误实际上并未充分“修复”

Question

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

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

鉴于这种情况：在重新打开错误并使用每个任务分支方法时，错误修复的最佳做法是什么？

• 克隆Jira中的错误以创建新问题是否会更好？ 编号，创建一个新分支并重新解决问题，就好像它是新的一样？ [这基本上将新修复基于组合 原始修复+新功能]（这会使合并更难） 如果您必须跟踪相同的多个修复，请跨版本 问题？）
• 回到原来的分支会不会更好 原始问题已修复，并重新修复，然后再次合并，交易 每当这种事情发生时，冲突解决？

注意：

1. 创建分支以与错误跟踪系统（Jira）链接，所以 分支机构名称包括发行号。
2. 由于此链接，我无法创建具有相同名称的2个分支 除非他们有不同的父母。所以，我可以从原始分支创建第二个分支，但不能从构建分支（原始问题的父代）创建第二个分支。

似乎每个任务分支方法会导致错误修复和功能之间反复出现冲突解决，直到完全测试和解决，因为这些任务分支之间没有合并 - 只有主干，他们会两者都不断相互“过时”。

我认为这对于单个开发人员来说并不常见，但是对于较大的团队来说可能会更频繁地发生，即使它不是特定于错误和功能之间（可以想象，两个功能可能会影响相同）文件，在发布之前的构建/测试周期期间导致额外的冲突解决方案）

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

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

Answer 1

对于你所要求的情况有多种选择和解决方案，我将为我能想到的每种情况解释我最喜欢的一种：

（1）2个分支被整合到“发布分支”AKA“/ main”中，您不想减去它们。

在这种情况下，您必须在Jira中创建一个新任务，将其链接到导致该问题的任务，如果是这种情况，则将其设置为回归。

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

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

（2）任务无法保留在“发布分支”中并且必须减去

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

Jira任务重新开放，甚至重新估算。

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

任务完成后，每个任务的常规分支周期继续。

希望它有所帮助！