带有开发、暂存和生产分支的 git
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/15072243/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
git with development, staging and production branches
提问by Max Hodges
This article sounds interesting, but I'm pretty sure the diagrams are wrong. http://guides.beanstalkapp.com/version-control/branching-best-practices.html
这篇文章听起来很有趣，但我很确定图表是错误的。 http://guides.beanstalkapp.com/version-control/branching-best-practices.html
Shouldn't it be DEVELOPMENT> STAGING> PRODUCTION?
不应该是DEVELOPMENT> STAGING>PRODUCTION吗？
Merges should only flow in one direction: from feature and bug-fixes done in their own branch or in development into staging for testing. Once tested, you can merge those changes from development into production.
合并应该只流向一个方向：从在他们自己的分支或开发中完成的功能和错误修复到测试阶段。经过测试后，您可以将这些更改从开发合并到生产中。
Here I get a bit confused. So I merge Staging to Master or Master to Staging?
说到这里，我有点糊涂了。所以我将 Staging 合并到 Master 或 Master 到 Staging？
I'm using a client called SmartGit and I get confused about this point. Normally I make a branch for a feature, commit to it, then switch to master and merge it to the branch (forward). So in this new workflow with Staging and Production, I create these two extra branches, then create a branch from master (aka dev) for my feature. Commit to it, then switch to Staging and merge (forward) to my feature branch? Does that sound correct?
我正在使用一个名为 SmartGit 的客户端，但我对这一点感到困惑。通常我为一个特性创建一个分支，提交给它，然后切换到 master 并将它的合并到分支（转发）。因此，在这个包含 Staging 和 Production 的新工作流程中，我创建了这两个额外的分支，然后从 master（又名 dev）为我的功能创建了一个分支。承诺它，然后切换到 Staging 并合并（转发）到我的功能分支？这听起来正确吗？
Actually what made this so confusing is that the Beanstalk people stand behind their very non-standard use of Staging (it comes before development in their diagram, and it's not a mistake! https://twitter.com/Beanstalkapp/status/306129447885631488
实际上，让这一切如此令人困惑的是 Beanstalk 人支持他们非常不标准的 Staging 使用（它出现在他们图表中的开发之前，这不是错误！ https://twitter.com/Beanstalkapp/status/306129447885631488
Have decided to forget about Beanstalk and just go with Github.
决定忘掉 Beanstalk，只使用 Github。
Since I posted this, the Beanstalk people took my hint and renamed their stages, now calling Development "Stable".
自从我发布这篇文章后，Beanstalk 的人接受了我的暗示，并重新命名了他们的阶段，现在称开发为“稳定”。
回答by eykanal
The thought process here is that you spend most of your time in development. When in development, you create a featurebranch (off of development), complete the feature, and then merge back into development. This can then be added to the final production version by merging into production.
此处的思考过程是您将大部分时间花在development. 在开发过程中，您创建一个feature分支（脱离development），完成功能，然后合并回development. 然后可以通过合并到production.
See A Successful Git Branching Modelfor more detail on this approach.
有关此方法的更多详细信息，请参阅成功的 Git 分支模型。
回答by Mot
We do it differently. IMHO we do it in an easier way: in masterwe are working on the next major version.
我们的做法不同。恕我直言，我们以一种更简单的方式做到了：master我们正在开发下一个主要版本。
Each larger feature gets its own branch (derived from master) and will be rebased (+ force pushed) on top of master regularly by the developer. Rebasing only works fine if a single developer works on this feature. If the feature is finished, it will be freshly rebased onto master and then the master fast-forwarded to the latest feature commit.
每个较大的功能都有自己的分支（从 master 派生），并且会由开发人员定期在 master 之上重新定位（+ 强制推送）。仅当单个开发人员在此功能上工作时，重新定位才能正常工作。如果功能完成，它将重新基于主节点，然后主节点快进到最新的功能提交。
To avoid the rebasing/forced push one also can merge master changes regularly to the feature branch and if it's finished merge the feature branch into master (normal merge or squash merge). But IMHO this makes the feature branch less clear and makes it much more difficult to reorder/cleanup the commits.
为了避免变基/强制推送，还可以定期将主更改合并到功能分支，如果完成将功能分支合并到主分支（正常合并或挤压合并）。但恕我直言，这使得功能分支不太清楚，并且使重新排序/清理提交变得更加困难。
If a new release is coming, we create a side-branch out of master, e.g. release-5where only bugs get fixed.
如果新版本即将发布，我们会从 master 中创建一个侧分支，例如release-5只修复错误。
回答by Max Hodges
Actually what made this so confusing is that the Beanstalk people stand behind their very non-standard use of Staging (it comes before development in their diagram, and it's not a mistake!
实际上让这变得如此混乱的是 Beanstalk 人支持他们非常非标准的 Staging 使用（它在他们的图表中出现在开发之前，这不是一个错误！
回答by JohnNY
one of the best things about git is that you can change the work flow that works best for you.. I do use http://nvie.com/posts/a-successful-git-branching-model/most of the time but you can use any workflow that fits your needs
关于 git 的最好的事情之一就是你可以改变最适合你的工作流程..我大部分时间都使用http://nvie.com/posts/a-successful-git-branching-model/但您可以使用任何适合您需求的工作流程
