谁在分支机构(企业开发)之间传播错误修正? [英] Who propagate bugfixes across branches (corporate development)?

问题描述

我们有许多发布和自定义分支.当错误修复发生时，它必须传播到许多分支.

We have many release and custom branches. When bugfix occur it MUST propagated across many branches.

我有几个相关的问题:

• 谁决定(哪个角色)在哪里传播错误修复
• 谁控制(哪个角色)错误修复的传播
• 在哪里修复错误 - 在主干/默认还是在选定的分支中?
• 是否需要由错误修复开发人员在所有分支上测试错误修复，还是仅在原始分支上测试错误修复并将另一个分支测试传递给 QA 团队?
• 谁传播错误修复 - 最初的错误修复创建者或指定的单独人员(哪个角色)?

推荐答案

DVCS 方面有点不同，因为 合并与发布正交(拉/推).

The DVCS aspect is a bit different, because merging is orthogonal to publication (pulling/pushing).

这意味着你需要区分:

• 分支之间的传播(合并)
• repo 之间的传播(拉/推 public 分支，即在 repo 之间复制的分支)

• propagation between branches (merge)
• propagation between repo (pull/push of public branches, ie branches made to be replicated amongst repo)

一旦你确定了这些分支，开发者应该从他/她的 bugfix 分支发起一个 bugfix 升级到 common dev 分支，然后发布.
错误修复本身应该在一个专门的分支中修复.

Once you have those branches identified, a bugfix promotion should be initiated by the developer from his/her bugfix branch to the common dev branch, and then published.
The bugfix itself should be fixed in a dedicated branch.

您可以通过发布到 Q/A 存储库来设置受保护的提交原则，该存储库将通过测试并在失败时拒绝提交.
请参阅您见过的最聪明的源代码库使用方法是什么?"，例如预先测试的提交或私有构建.

You can setup a guarded commit principle by publishing to a Q/A repo which will pass the test and reject the commit if those fails.
See "What is the cleverest use of source repository that you have ever seen?" for examples of pre-tested commits or private builds.

这篇关于谁在分支机构(企业开发)之间传播错误修正?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！