背景：我是公司唯一的开发人员，又被迫当系统管理员。我们还必须每年升级几次，用枪指着我们的头。即不可能延迟升级。
这就是我一直在做的事情
版本1：开发和发布分支。
升级之前，从“版本 1 发布”分支创建“版本 2 发布”。
代码升级后，从“版本 2 发布”生成构建并应用于 PROD。
产品升级后，从“版本 2 发布”创建“版本 2 开发”分支，并应用“版本 1 开发”中的挂起变更集以继续工作。
您发现这有什么问题吗？我们的分支机构大小如果 < 500 mb.
我更喜欢上面的方法（这是非标准的，必须在工作中学习），因为一旦代码升级，就没有合并回分支的麻烦。合并回来后也不需要生成构建并进行健全性检查。此外，我之前的分支仍然处于活动状态，以防产品上需要最后一刻的代码修复。
考虑到您的限制以及在升级过程中最小化风险的需要，您的方法似乎非常实用。
通过在升级之前创建新的发布分支，您可以避免合并回更改的复杂性，这可能容易出错。
保持较早的分支处于活动状态可以在需要时进行快速修复，这在生产环境中至关重要。
您还可以查看文档针对此主题选择具有 DevOps 思维的分支策略。
需要提及的是，DevOps 产品团队逐渐计划在所有新项目和组织中
phase out TFVC