1

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

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

鉴于这种情况：当重新打开错误并且您使用的是按任务分支的方法时，修复错误的最佳实践是什么？

  • 克隆 Jira 中的错误以创建新问题
    编号、创建新分支并像新问题一样重新修复问题会更好吗？
    [这基本上将新修复基于原始修复+新功能的组合]（ 如果您必须跟踪同一问题的多个修复，
    这是否会使跨版本合并变得更加困难 ？）

  • 回到
    原来问题被修复的原始分支，并重新修复它，然后再次合并，
    每次发生这种事情时处理冲突解决会更好吗？

笔记：

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

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

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

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

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

4

1 回答 1

1

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

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

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

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

开发修复程序并将其集成到下一个版本中，因为它的所有 QA 都是绿色的。

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

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

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

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

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

希望能帮助到你！

于 2013-06-28T11:41:57.500 回答