version-control - 使用 Mercurial 的按功能分支工作流

我们有 10 名开发人员的团队，他们针对不同的功能并行工作，有时这些功能使用通用代码有时不使用。
现在我们将流程更改为按功能分支，似乎 mercurial 更适合此类开发。

我看到这个过程是这样的:
1.从默认(主干)制作发布分支(r-b)
2.从默认(主干)制作功能分支(f-b)

当开发人员认为他的功能完成时，他可以将 f-b 合并到 r-b。当需要进行 QA 时，我们将所有完成的 f-b 合并到 r-b 并为我们的 QA 创建发布。

问题:

当 QA 发现 bug 时，开发人员应该修改他的 f-b 并再次将其合并到 r-b。这是否意味着开发人员只需切换到他的 f-b 并开始修复错误，然后再次简单地将 f-b 合并到 r-b？

当发布通过 QA 时，它会转到 PROD - 我们如何卡住更改？ “hg tag”是不错的选择，但如果他真的想要的话，有人可以更新标签。

谢谢

最佳答案

如果您要合并到特定的发布分支，那么您的功能分支应该从发布分支而不是主干分支。与父分支合并比与非父分支合并更简单。

1) 如果你真的想做功能分支，那么每个 bug 都会有自己的分支。这将有助于将错误修复与新功能分开。毕竟，它是每个功能的分支而不是每个开发者的分支。

2) Mercurial 标签是我用过的。如果有人真的想移动标签，你是对的，但标签是版本化的，你可以在主 hg 存储库上安装钩子(Hook)以在标签移动时发出警报。我真的不会担心标签被移动，除非你不能信任你的开发人员，在这种情况下你就完蛋了。

关于version-control - 使用 Mercurial 的按功能分支工作流，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/7707121/