手动测试阶段的版本分支/稳定化

mubassirameheja

如果拉取请求只是“挥手通过如果只讨论格式和小细节，这也表明存在问题。以下技巧应该使您团队的拉取请求变得生动起来： 最低人数：至少应有两名审稿人。这极大地提高了审查的质量，因为每个审查者都知道其他人也在检查代码。这是防止“挥手”的最重要措施。 分担责任：责任应该在团队内分担——所以不应该有一个超级架构师总是检查一切。每个团队成员都会接受其他人的审查！ 行为准则：应该有一个行为准则来规范审查期间的行为方式。一个很好的例子是微软开源行为准则：友善、耐心、热情、尊重、理解意见分歧。当然，仅靠行为准则并不能解决任何问题，但它确实有助于持续改进，因为您可以参考它。 集成到现有流程中：例如，如果您按照 Scrum 工作，那么您应该将审核流程的评估和改进集成到 Scrum 中。


这意味着在每个冲刺结束时，团队成员应该互相提供评审反馈，然后调整评审实践。 越多越好 瑞士 电话号码 审稿人太多总比审稿人太少好。特别是对于特殊主题（用户界面/企业身份、安全性、基础设施等）。如果这些事情受到变更的影响，那么相关专家——即使他们不是团队的一部分——也应该作为评审者参与进来。大多数 Git 系统都具有自动执行此操作的功能（GitHub 中的代码所有者、Azure Repos 中的自动审阅者）。 手动测试阶段的版本分支/稳定化 如果版本经历较长的稳定阶段，或者环境或平台需要不同的版本，则可以为此创建版本分支。我的建议是不要依赖发布分支的标签。这些都被遗忘得太快了。此外，发布分支应该是单向的，并且永远不会合并回来。




如果需要修复错误或进行其他更改，您可以使用选择性挑选将它们转移到新功能分支，然后使用拉取请求合并它们（参见图 3）。根据您的工作方式，在 master 分支中进行更改然后将它们传输到发布分支也很有意义 - 这将确保所有更改都存在于 master 分支中。当然，此工作流程对于特定于客户或平台的调整没有意义。在这种情况下，重要的错误修复将被推送到 master，其余的将在发布分支中本地更改。重要的是，发布分支永远不会直接集成回主分支。对于小型团队和新产品，这些安全预防措施可能看起来有些过度 - 但我认为最好从适用于大型团队的流程开始。大多数时候，您不会注意到当您越过界限时，您仍然可以控制复杂性。