谁在分支机构之间传播错误修复(公司发展)?
我们有许多发布和自定义分支。当错误修复发生时,它必须传播到许多分支。
我有几个相关的问题:
- 谁决定(哪个角色)在哪里传播错误修复
- 谁控制(哪个角色)错误修复传播
- 在哪里修复错误 - 在主干/默认还是在选定的分支中?
- 是否需要由 bugfix 开发人员在所有分支上测试 bugfix,还是仅在原始分支上测试 bugfix,然后将另一个分支测试传递给 QA 团队?
- 谁传播错误修复 - 原始错误修复创建者或指定的单独人员(哪个角色)?
We have many release and custom branches. When bugfix occur it MUST propagated across many branches.
I have several related questions:
- who decide (which role) where propagate bugfix
- who control (which role) bugfix propagation
- where fix bug - in trunk/default or in selected branch?
- is it need test bugfix on all branches by bugfix developer or only on original and pass another branch testing to QA team?
- who propagate bugfix - original bugfix creator or assigned separate person (which role)?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
DVCS 方面有点不同,因为合并与发布是正交的 (拉/推)。
这意味着您需要区分:
一旦识别了这些分支,就会修复错误升级应该由开发者从他/她的bugfix分支发起到common dev分支,然后发布。
错误修复本身应该在专用分支中修复。
您可以通过发布到 Q/A 存储库来设置受保护的提交原则,该存储库将通过测试并在失败时拒绝提交。
请参阅“您见过的源存储库最巧妙的用法是什么?”,了解预先测试的提交或私有构建的示例。
The DVCS aspect is a bit different, because merging is orthogonal to publication (pulling/pushing).
That means you need to distinguish between:
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.
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.