在 2 个不同的存储库中管理 Azure DEVOPS Git DEV 和发布分支是个好主意吗？

Question

我们正在从 TFVC 迁移到 GIT，在 TFVC 中，我们曾经管理 DEV 分支进行开发和 Master 分支进行发布。

TFVC 分支机构管理

1. 每个开发人员都将在 DEV 分支上工作，他们将在 DEV 分支上提交他们的更改。
2. 构建将从 DEV 分支部署到 Staging ENV（staging 是我们的内部环境。）
3. 一旦我们完成了正在进行的 Sprint 的 PCR/新集成（DEV 分支）并且我们准备好上线，我们曾经将更改从 DEV 合并到主分支。
4. 将在 UAT / BETA（客户端测试环境）上从 Master 部署构建。
5. 一旦他们验证并发出 go 信号，就会在 Live 上部署相同的构建。

使用这种方式只用于管理 TFVC 中的 DEV 和 Master 分支。

现在在 GIT 中，每个开发人员在开始处理任何 PCR/新集成时都会创建自己的分支。一旦他们完成更改，这些将使用 Pull Request 合并到 Master 中（我知道我们可以在更改合并后删除分支，但我看到人们没有遵循这个流程）。

仅 2 个月前我们开始使用 GIT，现在我可以看到超过 10-15 个分支，我们没有任何专门的资源来负责管理分支和这个工作流程。

在当前 Sprit / PCR / Hotfix 的开发完成后，我们将在 Staging / UAT / LIVE 上部署构建。 每次实时部署/发布都会维护新分支。

那么在 DEV 存储库中维护开发分支和对于实时/发布分支​​创建（主/发布）存储库以维护发布分支是个好主意。

这样我只是想把事情分开，你认为这是个好主意吗？ 将来我们会面临什么问题，或者他们有更好的方法吗？

Answer 1

在 DEV 存储库中维护开发分支是否是个好主意，对于实时/发布分支​​创建（主/发布）存储库以维护发布分支。

这是针对您的情况的一种解决方案。即使您在不同的存储库中管理关键分支，如果开发人员在complete this pull request 时不选中“合并后删除”或手动操作，他们仍然会创建更多子分支并将它们留在这里删除它们。而且在某种程度上违背了 Git 的工作流程。

因此，Azure DevOps 提供了存储库权限管理，如下所示。详情请参阅：Set repository permissions for Git or TFVC。 您可以设置不同的权限以允许特定成员可以创建分支。而在Branches page，你可以查看谁是分支的作者。

此外，您可以按照以下文档设置分支策略：Improve code quality with branch policies，添加代码审查者以在完成拉取请求之前批准代码。