使用Git进行代码升级 [英] Code Promotion with Git

问题描述

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

非常感谢一些方法。

解决方案

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

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

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

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

通过这种设置，单个开发人员都可以为自己拥有应用程序的可运行副本，QA团队可以在他们有时间的情况下获得正在运行的副本（这是最有趣的我的工作的一部分，收集人就像放牧猫一样），而真实世界有一个完美的网站。理论上，无论如何。人们犯错误。

I'm trying to figure how can I use git for multiple environments (dev->test->prod) with code promotion. I read a bit about branching but didn't understand much how can this solve my problem since I must have the ability to run all of the environments concurrently and separately from each other.

Will be very thankful for some kind of how-to.

解决方案

It seems to be quite the common theme to have this three-tier workflow. Here's how we've done it. We're a Ruby shop, so there's some mention of testing here too.

We all work on individual "stories" (from Pivotal Tracker) separately from each other. This means that if we were all committing to the master branch, then we'd be stepping on each other's toes constantly. To stop this problem, each of us creates a new branch (based off the latest master) for that specific chunk of work.

When we complete that chunk of work, we run the tests ourselves and if they're passing then they get merged back to the master branch where the tests are ran again to ensure that there's no breakages that have been introduced. If there have been, we try using git bisect to figure out what it was, and that works in 99% of cases.

Most of the time (because we're really awesome*), the tests pass. When all the tests are passing on the master branch then we deploy to our staging server. So I guess this means that master is the staging branch. When that feature (or more likely, features) have been given approval, then we merge those changes into a production branch and then push that branch up to the production site.

With this setup, the individual developers are all able to have a runnable copy of the application for themselves, the QA team gets a running copy to go over when they have the time (this is the "most fun" part of my job, gathering people is like herding cats) and the Real World has a perfect site.

In theory, anyway. People make mistakes.

这篇关于使用Git进行代码升级的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！