git与开发,阶段和生产分支


75

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

它不应该是DEVELOPMENT> STAGING> PRODUCTION

合并只能朝一个方向进行:从在自己的分支机构或开发中完成的功能和错误修复到测试阶段。经过测试后,您可以将这些更改从开发合并到生产中。

在这里,我有点困惑。因此,我将暂存合并为Master还是将Master合并为暂存?

我正在使用一个名为SmartGit的客户端,对此我感到困惑。通常,我会为功能创建一个分支,提交给它,然后切换到master并将其合并到分支(转发)。因此,在这个具有暂存和生产功能的新工作流程中,我创建了这两个额外的分支,然后为我的功能从master(aka dev)创建了一个分支。提交,然后切换到暂存并合并(转发)到我的功能分支?听起来正确吗?


实际上,使之如此混乱的原因在于,Beanstalk员工支持非常不标准的Staging使用(它出现在图表开发之前,这不是错误! https://twitter.com/Beanstalkapp/status/306129447885631488

决定忘掉Beanstalk并选择Github。


自从我发布了这篇文章以来,Beanstalk的人就听了我的提示,并重命名了他们的阶段,现在将Development称为“ Stable”。


1
您可能要合并从登台到生产的修订。以测试为目的合并到暂存,然后在测试完成后将开发合并到生产中,这留下了开发方面的额外工作被合并到从未合并到暂存中的生产的可能性。
wadesworld

经典分支工作流程不容易应用于Git,因为Git中的分支要轻得多。它们只是指向历史中(单个)提交的指针,历史本身可以在多个方向分支。这就是为什么很难将分支视为独立开发的“线”(这也适用于“成功的Git分支模型”中的图)。

是的,这不完全是泳道。但是我的问题更具体:我是否切换到暂存并合并到开发人员,反之亦然?我是git的新手,对此感到困惑。也许我应该直接向Windows git客户端SmartGit的制造商提出这个问题。
Max Hodges

我一直在寻找一个确切的问题。搜索Google并获得第一个号码。Yaay(y)
NullPointer

Answers:


86

这里的想法是,您将大部分时间都花在development。在开发过程中,您将创建一个feature分支(关闭development),完成功能,然后合并回development。然后,可以通过合并到,将其添加到最终生产版本中production

有关此方法的更多详细信息,请参见成功的Git分支模型


25
为“成功的Git分支模型” +1。就git工作流程而言,这基本上已成为标准。
Mike Weller

11
对于只有几个人参与的小型项目,“成功的Git分支模型”有点复杂。我喜欢更简单的方法,其中开发是在master分支中完成的,稳定版本在master分支中被标记,并且如果需要,它们具有用于补丁的稳定分支。参见stackoverflow.com/questions/14858075/…scottchacon.com/2011/08/31/github-flow.html
Josef

1
谢谢@JosefKufner github流文章非常有帮助
Max Hodges

2
@eykanal您合并developmentproduction还是feature合并production
endo64

4
本文中没有暂存分支。他们如何从开发服务器部署到登台?我只看到他们如何直接从dev部署到生产-将dev分支合并到master,但这并不安全,因为它跳过了暂存环境,不是吗?
拉兹

6

我们做的不同。恕我直言,我们以一种更简单的方式做到这一点:master我们正在开发下一个主要版本。

每个较大的功能都有其自己的分支(源自master),并且开发人员会定期在master之上重新建立基础(+强制按下)。仅当一个开发人员使用此功能时,重新部署才能正常工作。如果功能已完成,它将重新基于主机重新构建,然后将主机快速转发到最新的功能提交。

为避免重新调整/强制推送,还可以将主更改定期合并到功能分支,如果完成,则将功能分支合并到主分支(正常合并或壁球合并)。但是恕我直言,这会使功能分支变得不清楚,并使重新排序/清理提交变得更加困难。

如果要发布新版本,我们将在master之外创建一个分支,例如release-5,仅修复错误。


9
我不知道这意味着什么。
Max Hodges

6
您不了解什么?
蒙特


By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.