Git工作流程和发布分支:很多,一个或没有?

时间:2011-12-02 15:22:39

标签: git workflow

对于我们的网站开发,我们每天进行每周部署。有些情况下我们会向QA部署一些内容,但是他们几天都没有对它进行测试,然后我们会有一个生产修复或需要更新的增强功能。两个问题:

(1)这会是一个很好的工作流程吗?

(2)有一个连续的,长寿命的分支称为生产或发布,与每个版本的新版本分支相反,或者只是做主要的事情并相应地标记它有什么优点和缺点?同样,这是针对具有可以备份的频繁发布的Web开发。

4 个答案:

答案 0 :(得分:12)

我不太确定我是否正确理解了您的问题,但我的情况与您的情况类似,我使用(修改)以下方法:http://nvie.com/posts/a-successful-git-branching-model/

简而言之,它是关于2个主要分支(开发)和几种类型的支持分支(功能发布修补程序)。说到你的情况,你可能会将你的发布分支部署到QA,然后当你有生产修复时,你可以在 hotfix 分支中进行,然后将它合并到两者 - 主分支和发布分支。

关于你的第二个问题......嗯,你知道,关于分支策略有很多不同的意见(example ...)我会说,连续生产分支很有用(并且它没有这意味着你不能拥有发布分支来支持你的工作流程。

答案 1 :(得分:7)

在我之前的工作中,我们使用了类似于@Alexis提到的方法,主要区别在于。请记住,我们正在研究一些非常重要的遗留软件的新版本(我们的代码库是几百万行代码,介于Java,flex和COBOL之间),并为我们进行了客户合作伙伴beta测试。发布是双/周,包括对客户(虽然它们通常是最新的一个版本,因为那个将首先通过QA),并且在那一周我们不得不做一个'削减',测试,基本QA我们代码的客户,该公司的另一位开发人员,然后发布到真正的QA。

基本上,master是我们的dev分支。如果开发项目需要花费一天或两天的时间,它就会在功能分支上完成,然后在准备就绪时合并到dev中。还有另一个“未来”开发分支,专门用于相当严肃的新功能工作(任何以显着方式改变程序的东西)或重大重构。在某些时候,当我们决定有时间对错误进行适当测试和解决时,或者是时候引入新功能并应对不可避免的痛苦时,这将成为主要的“开发”:)

当发布时,创建了一个名为'release_x'的新分支,然后来自QA的所有修复都在那里实现并合并'up'。我的意思是我们可以在任何时候都有两个或三个版本,所以如果他们找到了一个showstopper,那么客户显然会拥有最老的我们可以解决的问题。这将在相关版本的修补程序分支上完成,该分支将在某个时刻合并到该版本并删除(因此您可以轻松地在分支列表中看到未完成的修补程序)并完成另一个构建并发送给客户。存在“修补程序”分支,以便我们可以选择进入特定构建的内容,该内容适用于客户发布以及开发人员发布,以避免针对小型问题的潜在风险修复,从而破坏针对showstopper的修复程序的发布

然后将合并到QA人员发布的版本,然后将合并到其他开发人员正在使用的版本(总是最新版本,因为他们依赖我们的插件和j2ee基础设施来完成他们的工作),然后回到开发阶段,只是为了让所有东西保持在水平上。

目前正在发布的所有版本在Jenkins以及dev分支中都有自己的自动构建循环,其中一些自动化功能测试运行在更重要的(主要是dev和QA)上。每个构建都在用作HEAD的提交的报告中添加了一个标记,并且程序中提供了构建编号,以便我们可以看到完全错误报告者正在使用的版本。

基本上,两个开发分支,其中一个主要工作稍后将作为新的主要版本发布。为每个版本发布分支,其中包含修补程序分支。找到最新版本是一件容易的事情,寻找数量最多的发布分支。

唯一的缺点是,如果您在发布多个版本时做了很多修复,那么合并图表......有趣的是:)

答案 2 :(得分:6)

你绝对应该

  • 制作发布分支
  • 在QA反馈后提供您所做的修复
  • 将它们合并回主人。

这是一种自然而有效的工作流程。

答案 3 :(得分:1)

我们使用了Gitflow workflow分支模型,该模型源自nvie的Vincent Driessen,就像上面提到的Alexis。

这个想法是你将拥有两个主要分支Develop和Master。开发人员可能拥有自己的功能分支,一旦功能准备好,最终会合并回Develop。当开发完成一个功能时,你将一个发布分支从Develop开始,它将启动你的发布周期。将在此分支上进行测试,如果引入任何错误,它们也将在此分支上修复,但不会向此分支添加任何新功能。一旦每个人都对发布感到满意,它就会合并到Master中并标记版本号。您还将它合并回Develop。

如果在生产代码中发现错误,则从Master分出新的Hotfix分支。修复完成后,将Hotfix合并到Master中。如果在发布周期中创建了Hotfix,则将其合并到Release中,否则将合并到Develop。

没有修补程序:

功能 - >开发< =>发布 - >

在发布周期中使用修补程序:

功能 - >开发< =>发布< - Hotfix< => '大师'

在发布周期后使用修补程序:

功能 - >开发< - Hotfix< => '大师'