对于 azure git devop 的持续交付，这是一个好的或可接受的分支策略吗？

Question

我们正在使用带 git 存储库的 azure 管道。目前，我们有一个 master 分支、一个 sprint 分支和一个 feature 分支。对于生产部署，我们部署 sprint 分支，然后将其合并回 master。

sprint 分支将部署到 dev、QA、UAT 和 Prod。 但是，经过几个月的工作，出现了一些实际问题：

1. 每次sprint后，我们都要记得合并回master分支。
2. 要进行热修复，我们需要从 master 创建一个分支，因为通常我们从 sprint 分支部署，我们必须分拆一个新的部署管道和热修复发布管道。
3. 如果我们只想部署几个功能，这并不容易（因为 sprint 分支可能包含我们不想部署的功能，所以必须还原。

我们现在正在想的是：

1. 我们还有 Master、Sprint 和功能分支。但是现在我们只从 Master 分支部署到生产环境。
2. 对于sprint 分支，我们只部署到Dev 和QA 环境。当 sprint 完成后，我们需要先合并回 Master，然后部署到 UAT，然后再部署到生产环境。
3. 对于hotfix，我们在Master上创建hotfix分支，部署到UAT，然后部署到production。
4. 如果只部署几个功能，我们可以将需要的功能合并到 Master 分支，然后再部署。但是，这需要我们在 PR 之后保留这些特性分支（否则很难找到特性分支）。
5. 在每个 sprint 之后，我们 运行 一些作业来自动删除功能分支。

似乎这样一切都顺畅了一些。我的想法有什么问题或更好的方法吗？

Answer 1

在我看来，你的想法是合理的。

您可以使用 master 部署到生产和 UAT 阶段。 master分支需要保留最新发布的内容

因此，当您有任何功能或修补程序时，您可以基于 master 创建一个分支。

然后您可以对创建的分支进行一些更改（例如添加功能或修复问题）。

最终需要将这些合并到master分支中，部署master分支。

也就是说，你需要保证部署到Production/UTA的分支是master分支。

对于Sprint Branch，也可以基于master创建。如果你想在 Sprint 分支中添加特性，你可以将 features 分支合并到 Sprint 中进行测试。 如果要部署feature，可以直接将feature分支合并到master分支部署。

这样的话，Azure Repo的管理会更方便。

希望对您有所帮助。