1

git 分支模型有一个工作流，其中我们有两个具有无限生命周期的分支：其中develop反映了生产就绪状态和具有最新交付的开发更改的状态。mastermasterdevelop

要从develop进入master我们要经过一个中间状态，release branch它支持准备新的生产版本。在这些准备工作（shell 脚本或手动更改）之后，我们将发布分支合并到 master，标记它并将其推送到生产环境。

此时，仅对生产进行更改，因为例如，外部服务在生产中的 URL 与它们在暂存环境中的 URL 不同。

master除非我develop将它重新合并到develop.

如果我（a）这样做，我所有的生产只有在发布分支中所做的更改将被合并回开发

如果我（b）不这样做，我的主人将永远领先和落后develop，并且在从主人分支出来的修补程序的情况下，我最终会在修复后将所有内容重新合并develop。

使用此模型的最佳方法是什么，同时确保我仅将生产更改远离我的开发分支？

4

1 回答 1

1

这实际上更像是一个配置管理问题，而不是一个 git 问题。这个问题不是 git 独有的，是所有版本控制系统的问题。最佳做法是消除所有仅用于生产的更改，或者至少将它们减少到最低限度。

这可以通过多种方式完成：

  • 将配置值放入数据库。这一直有效，直到您对必须更改数据库以更改简单配置感到恼火

  • 将配置放在一个文件中，并使用基于生产中更改的单个变量的 if 语句。例如：

    if ( 生产 ) value = key
    else value = otherkey

    这也不是很好，因为现在您基本上拥有未经测试的代码。

  • 将配置放入环境变量中。这工作得很好，但您最好确保您的部署过程实例化并填充它们。

  • 但是，如果您想获得真正的最新技术，请将您的配置放在它自己的存储库中，并使用像 puppet 和 chef 这样的自动化工具

于 2013-11-05T03:48:19.603 回答