时间戳

首页 > 解决方案 > 在 2 个不同的存储库中管理 Azure DEVOPS Git DEV 和发布分支是个好主意吗？

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

问题描述

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

TFVC 分支机构管理

  1. 每个开发人员都将在 DEV 分支上工作，他们将在 DEV 分支上提交他们的更改。
  2. 构建将从 DEV 分支部署在 Staging ENV 上（staging 是我们的内部环境。）
  3. 一旦我们完成了正在进行的 Sprint 的 PCR / 新集成（DEV 分支）并且我们准备好上线，我们曾经将更改从 DEV 合并到 Master 分支。
  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 存储库中维护开发分支并为实时/发布分支​​创建（主/发布）存储库以维护发布分支是个好主意。

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

标签： gitazure-devopsversion-controlrepositoryrelease-management

解决方案

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

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

因此，Azure DevOps 提供了存储库权限管理，如下所示。有关详细信息，请参阅：为 Git 或 TFVC 设置存储库权限。 在此处输入图像描述 您可以设置不同的权限以允许特定成员可以创建分支。在Branches 页面中，您可以查看谁是分支的作者。

此外，您可以按照此文档设置分支策略：使用分支策略提高代码质量，添加代码审查者以在完成拉取请求之前批准代码。

推荐阅读