我正在尝试计算如何在多个环境（dev-＆gt; test-＆gt; prod）中使用git进行代码提升。我读了一些关于分支的内容，但是我不太了解如何解决我的问题，因为我必须能够同时并且彼此分开地运行所有环境。
非常感谢某种方法。
答案 0 :(得分：2)
拥有这种三层工作流程似乎是一个非常常见的主题。这是我们如何做到的。我们是一家Ruby商店，所以这里也提到了测试。
我们都在彼此分开处理个人“故事”（来自Pivotal Tracker）。这意味着如果我们都致力于主分支，那么我们就会不断地踩到彼此的脚趾。为了解决这个问题，我们每个人都为这个特定的工作块创建了一个新的分支（基于最新的 master ）。
当我们完成那一部分工作时，我们自己运行测试，如果他们正在通过，那么他们会合并回主分支，再次运行测试以确保没有破损已经介绍过了。如果有，我们尝试使用git bisect来确定它是什么，并且在99％的情况下有效。
大部分时间（因为我们真的很棒*），测试通过了。当所有测试都在主分支上传递时，我们就会部署到我们的登台服务器。所以我想这意味着 master staging 分支。当该功能（或更有可能的功能）获得批准后，我们会将这些更改合并到生产分支中，然后将该分支推送到生产站点。
通过这种设置，各个开发人员都可以为自己拥有一个可运行的应用程序副本，QA团队可以获得一个正在运行的副本，以便在他们有时间的情况下继续（这是我的“最有趣”部分）工作，聚集人就像放牧猫一样）真实世界有一个完美的网站。
理论上，无论如何。人们会犯错误。
答案 1 :(得分：1)
DVCS介绍another dimension to versioning：
“出版”（推/拉）
代码推广过去只能通过分支机构或标签进行。
对于有多种贡献的环境，像Ryan这样的本地个体分支描述效果最好。
但是使用DVCS，您只需将代码库推送到专用存储库，并将该克隆视为“测试”促销环境。
通常，您可以first rebase在远程升级代码之上的当前工作，以解决本地任何冲突。然后你会推（在远程方面快进合并）。
因此，它是您可以用于代码促销的另一个工具（同时仍然使用分支或标签：通常，“生产”最好由分支标识）。
答案 2 :(得分：1)
我的情况是，git push用于将文件从dev发布到测试服务器。然后我们每天（或每周）构建（使用phing）将应用程序导出到生产服务器（那里没有git repo）或者发布包含要下载的源代码的tarball。
工作流程取决于您的项目特定变量。
切换服务器不仅可以区分代码版本，还可以区分数据库，环境，配置和用户。
一次更改所有选项的自然方式也是更改回购，因此在dev / test / production回购之间进行推送。
但你可以编写自己的git hooks来负责所有这些开关。您可以选择许多挂钩选项。分支只是一个提交，因此您可以使用提交后挂钩，仅导出特定标记或导出特定分支的内容。