关于git分支/释放策略的指导

Question

我正在寻找关于git分支/发布策略的指导，这似乎与我迄今为止找到的任何策略都不一样。

我们正在使用VSTS，并且目前有一个主分支，每个更改都有功能分支。提交PR以审查功能分支，如果批准，则自动合并到主服务器。这会自动触发DEV环境的释放。假设一切都成功，则手动触发发布（通过批准）。

我遇到的问题是，我们可以让多个团队成员在任​​何给定的时间点处理各种功能。这意味着多次合并到master中，并向DEV发布相应的版本。一切正常。然而，当有人想要在其他人的更改准备就绪之前将其更改移至生产时，就会出现问题。在我们当前的场景中，执行发布到生产将从发布时存在的主分支到DEV。“/ p>

这可能看起来非常错误，但我们的Git repo并不真正包含代码 - 更多地将其视为配置。将配置更改单独转移到生产中是完全可以接受的。

我已经考虑过有多个分支和挑选提交，但感觉过于复杂。

我希望我错过了一些非常明显的东西。

Answer 1

我怀疑你已经知道了，但是

  

这可能看起来非常错误，但我们的Git repo并不真正包含代码 - 更多地将其视为配置。将配置更改单独转移到生产中是完全可以接受的。

与你的陈述发生冲突：

  

然而，当有人想要在其他人的更改准备好之前将他们的更改转移到生产中时会出现问题

如果您的更改可能处于未准备好的状态，则根据定义，您需要一些方法来单独进行更改。我过去在这里使用了几种不同的策略，所有这些策略都围绕着这样的想法，即合并到main并从生产到生产从根本上说应该是一个原子操作：

1. 减少更改在主分支中保留的时间而不进行生产。如果需要，回滚不令人满意的变化。这对我来说不是一个完整的解决方案，因为它不会让人们在他们可能需要的更长时间内访问您的开发或预生产环境。
2. 保持单独的Dev和Main分支，并准备樱桃选择合并到main。这并不能完全解决您的问题，因为在大多数情况下，如果多个配置更改可能会在Main中相互污染，他们也可以在Dev中执行此操作，这可能会更改您的测试结果（就像在当前系统中一样）。 / LI>
3. 检查您的开发基础架构并重新设计，以便可以在不合并的情况下正确测试开发构建。然后设置一个（门控）连续部署策略，这样当你合并到main时，你总是会开始生产。这种策略可能需要大量的工作才能开始，但可能是最接近我在大公司中遇到的生产环境而没有专门的构建基础架构团队。

Answer 2

我将建议gitflow如下：

• 每个开发人员都在自己的功能分支
上工作
• 当开发人员完成其工作时，创建一个PR以将功能分支合并到develop分支
• 当PR获得批准时，将功能分支中的更改合并到develop分支。然后将触发发布以部署到DEV环境。
• 当它准备好部署到生产环境时，将develop分支合并到master分支进行生产。

您还可以参考A successful Git branching model了解更详细的分支模型。