具有开发、分段和生产分支的 git

这篇文章听起来很有趣，但我很确定图表是错误的。 Http://guides.beanstalkapp.com/version-control/branching-best-practices.html

不应该是 DEVELOPMENT > STAGING > PRODUCTION吗？

合并应该只向一个方向流动: 从特性和错误修复 在他们自己的分支或者在开发阶段进行测试。 经过测试之后，您可以将这些开发中的更改合并到 制作。

这里我有点困惑。所以我合并分期到主或主分期？

我正在使用一个名为 SmartGit 的客户端，我对这一点感到困惑。通常，我为一个特性创建一个分支，提交它，然后切换到 master 并将其合并到分支(正向)。因此，在这个新的工作流程中，我使用分段和生产创建了这两个额外的分支，然后从 master (又名 dev)为我的特性创建了一个分支。提交它，然后切换到阶段和合并(前进)到我的功能分支？是这样吗？

实际上，让这个问题如此令人困惑的是，Beanstalk 人员支持他们非常不标准的 Staging 使用(在他们的图中，Staging 在开发之前出现，这不是一个错误!)！ Https://twitter.com/beanstalkapp/status/306129447885631488

已经决定忘记 Beanstalk，只是去吉萨布。

自从我发布了这篇文章，豆茎的人们接受了我的提示，重新命名了他们的舞台，现在称开发为“稳定”。

155043 次浏览
小开
最佳答案

The thought process here is that you spend most of your time in development. When in development, you create a feature branch (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.

See A Successful Git Branching Model for more detail on this approach.

小开

We do it differently. IMHO we do it in an easier way: in master we are working on the next major version.

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.

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-5 where only bugs get fixed.

小开

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

小开

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


提交答案