使用Git进行代码升级

Question

我想知道如何在代码升级的情况下将git用于多种环境（dev-> test-> prod）。我读了一些关于分支的知识，但不太了解如何解决我的问题，因为我必须有能力同时并且彼此分开地运行所有环境。

会非常感谢某种方法。

Answer 1

这个三层工作流程似乎是相当普遍的主题。以下是我们如何做到的。我们是一家Ruby商店，所以这里也提到了一些测试。

我们所有人都从单独的“故事”（来自Pivotal Tracker）分别开展工作。这意味着如果我们都致力于主人分支，那么我们会一直踩着彼此的脚趾。为了解决这个问题，我们每个人都会为该特定的工作创建一个新分支（基于最新的主人）。

当我们完成这部分工作时，我们自己运行测试，如果他们通过测试，他们会合并回主分支分支，测试再次运行以确保没有引入中断。如果有的话，我们尝试使用git bisect找出它是什么，并且在99％的情况下工作。

大部分时间（因为我们真的很棒*），测试通过。当所有的测试都通过主分支后，我们将部署到我们的登台服务器。所以我猜这意味着大师是分段分支。当该功能（或更有可能的功能）已获得批准后，我们​​会将这些更改合并到生产分支中，然后将该分支推送到生产站点。

通过这种设置，单个开发人员都可以拥有应用程序的可运行副本，QA团队可以在有时间的情况下获得正在运行的副本（这是“最有趣”的一部分）我的工作，收集人就像放牧猫），真实世界有一个完美的网站。

理论上，无论如何。人们犯错误。

Answer 2

DVCS介绍another dimension to versioning：
“公开”（推/拉），用于排他地由通过分支，或通过标签

代码推广。

对于具有多重贡献的环境，像瑞恩这样的本地独立分支机构描述最佳作品。

但是通过DVCS，您可以简单地将代码库推送到专用存储库，并将该克隆视为“测试”升级环境。
通常情况下，您将first rebase您目前的工作放在远程升级的代码之上，以解决本地的任何冲突。然后你会推动（在远程端快速合并）。

所以它是另一个可用于代码升级的工具（虽然仍然使用分支或标签：通常，“生产”最好由分支标识）。

Answer 3

在我的情况下，git push是用于从dev发布文件到测试服务器。然后，我们每天（或每周）构建（使用phing）将应用程序导出到生产服务器（那里没有git回购）或发布包含源代码的tarball以供下载。

工作流程取决于您的项目特定变量。

切换服务器不仅可以区分代码版本，还可以区分数据库，环境，配置和用户。

一次更改所有选项的自然方式也是更改回购，因此在开发/测试/生产回购之间进行推送。

但是你可以编写你自己的负责所有这些交换机的git钩子。有许多钩选项可供选择。 Branch只是一个提交，所以你可以拥有post-commit钩子，只导出特定的标签，或者导出特定分支的内容。