用于多个暂存/生产环境的 git-flow答案

【问题标题】：git-flow for multiple staging / production environments用于多个暂存/生产环境的 git-flow
【发布时间】：2011-02-19 23:22:32
【问题描述】：

我正在尝试将 git-flow 应用于具有多个共享相同代码库的网站的项目。

我目前使用许多功能分支、一个开发分支、一个支持分支和许多生产分支：每个站点一个，因为每个站点都自定义了一些配置文件。

git flow 工具并没有提出很多主/生产分支，而是一个。 我能做什么？

【问题讨论】：

【解决方案1】：

坦率地说，这听起来像是一个应用程序配置问题——而不是 git 问题。

我们已经在我们的系统中找到了原生支持“覆盖”文件的方法——系统首先查找自定义文件并回退默认文件。

如果你不能让你的应用程序在运行时动态定制，我会实现一个在部署时进行覆盖的构建过程。

【讨论】：

嗯，是的，也不是。我知道这不是 git 问题，但它仍然是 git flow 问题。
假设您有一个 Web 应用程序要以 3 种风格部署：iphone 应用程序、android 应用程序等。您将需要 3 个部署分支，每个分支都需要对您的应用程序进行平台的必要调整.现在我的问题类似：每个网站都有自己的生命周期和版本号等。而且每个网站都打包成一个debian包，用于部署在prod服务器上。这些软件包中的每一个都有自己的版本颠簸。所以这不仅仅是关于运行时定制。
考虑多个 git repos 怎么样？一个“库”存储库，然后为每个导入基本库的应用程序风格一个单独的存储库。尽管我仍然认为您可能从错误的角度看待这个问题；打包各种部署类型和位置的应用程序的过程实际上是一个构建问题——而不是 SCM 问题。 HTH。
我会为共享库的东西实现 Git 子模块。例如，您有 4 个存储库：iphone app repo、android app repo、windows phone app repo 和 shared lib repo。您将共享库存储库子模块到每个其他存储库中，这样您就可以与平台存储库中的特定配置内容分开开发和测试共享库代码。只是一个想法。

【解决方案2】：

解决方案 1) 在子项目中开发 maven 工件并将它们上传到自定义关系。那么你的每个项目都可以导入这些工件

解决方案 2) 使 git-flow 适应您自己的需求。例如，在我们的例子中，我们有几个发布分支并且没有开发分支。每个分支都是从 master 创建的。通过这种方式，我们非常灵活，可以即时创建短期和长期版本，只需将所有功能分支合并到一个版本中即可。这样，您还可以为每个环境创建特殊版本

ps：如果你使用 git-flow scripts-bundle，那么你必须忘记那些并自己做（没那么难）

【讨论】：

【解决方案3】：

我的解决方案如下：

当我需要部署时，我会在我的 PC 上运行一个脚本：

在服务器上，我运行一个脚本：

【讨论】：