我们正在从TFVC迁移到GIT,在TFVC中,我们曾经管理DEV分支进行开发,而Master分支进行发布。
TFVC分支机构管理
使用这种方式只能管理TFVC中的DEV和Master分支。
现在,在GIT中,每个开发人员在开始进行任何PCR /新集成时都在创建自己的分支。完成更改后,将使用Pull Request将这些合并到Master中(我知道我们可以在更改合并后删除分支,但是我看到人们没有遵循此流程)。
仅两个月前,我们开始使用GIT,现在我可以看到10-15个以上的分支机构,我们没有任何专门资源来管理分支机构和此工作流程。
在完成当前Sprit / PCR / Hotfix的开发后,我们将在Staging / UAT / LIVE上部署构建。每个实时部署/发布都将维护新的分支。
因此,最好在DEV存储库中维护开发分支,并为Live / Release分支创建(Master / Release)存储库以维护发行分支。
这样我只想分开,您认为它是个好主意吗?将来我们会面对任何问题吗,或者他们有更好的解决方法吗?
在DEV存储库中维护开发分支并为Live / Release分支创建(Master / Release)存储库以维护发行分支是个好主意。
这是针对您情况的一种解决方案。即使您在不同的存储库中管理关键分支,如果开发人员在完成此拉取请求时未选择“合并后删除”或手动删除它们,它们仍将创建更多子分支并将其留在此处。并且在某种程度上违背了Git工作流程。
因此,Azure DevOps提供了存储库权限管理,如下所示。有关详细信息,请参见:设置Git或TFVC的存储库权限。您可以设置不同的权限,以允许特定成员创建分支。在“分支”页面中,您可以查看谁是分支的作者。
此外,您可以按照以下文档设置分支策略:使用分支策略提高代码质量,添加代码审阅者以在完成拉取请求之前批准代码。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句