英文原文:

http://nvie.com/posts/a-successful-git-branching-model/

中文版:

在这篇文章中,我提出一个开发模型。我已经将这个开发模型引入到我所有的项目里(论在工作还是私人)已经一年有余,并且它被证明是非常成功的。我打算写这些已经很久了,但我一直找不到时间来做,现在终于有时间了。我不会讲任何项目的具体细节,仅是关于分支策略和释放管理相关内容。

它主要体现了Git对我们源代码版本的管理。

为何是Git?

对于Git与其他集中式代码管理工具相比的优缺点的全面讨论,请参见这里。这样的争论总是喋喋不休。作为一个开发者,与现今的其他开发工具相比较,我更喜欢Git。Git真得改变了开发者对于合并和分支的思考。我曾经使用经典的CVS/Subversion,然而每次的合并/分支和其他行为总让人担惊受怕(“小心合并里的冲突,简直要命!”)。

但是对于Git来说,这些行为非常简单和搞笑,它们被认为是日常工作中的核心部分。例如,在很多CVS/Subversion书里,分支与合并总是在后面的章节中被讨论(对于高级用户使用),然而在每个Git书中,在第3章就已经完全涵盖了(作为基础)。

简单和重复的特性带来的结果是:分支与合并不再是什么可以害怕的东西。分支/合并被认为对于版本管理工具比其他功能更重要。

关于工具,不再多说,让我们直接看开发模型吧。这个模型并不是如下模型:在管理软件开发进度方面,面对每个开发过程,每个队员必须按一定次序开发。

分布式而非集中式

对于这种分支模型,我们设置了一个版本库,它运转良好,这是一个事实上 版本库。不过请注意,这个版本库只是被认为是中心版本库(因为Git是一个分布式版本管理系统,从技术上来讲,并没有一个中心版本库)。我们将把这个版本库称为原始库,这个名字对所有的Git用户来说都很容易理解。

每个开发者都对origin库拉代码和提交代码。但是除了集中式的存取代码关系,每个开发者也可以从子团队的其他队友那里获得代码版本变更。例如,对于2个或多个开发者一起完成的大版本变更,为了防止过早地向origin库提交工作内容,这种机制就变得非常有用。在上述途中,有如下子团队:Alice和Bob,Alice和David,Clair和David。

从技术上将,这意味着,Alice创建了一个Git的远程节点,而对于Bob,该节点指向了Bob的版本库,反之亦然。

主分支

在核心部分,研发模型很大程度上靠其他现有模型支撑的。中心库有2个可一直延续的分支:

  • master分支
  • develop分支

每个Git用户都要熟悉原始的master分支。与master分支并行的另一个分支,我们称之为develop分支。

我们把原始库/master库认作为主分支,HEAD的源代码存在于此版本中,并且随时都是一个预备生产状态。

辅助性分支

我们的开发模型使用了各种辅助性分支,这些分支与关键分支(master和develop)一起,用来支持团队成员们并行开发,使得易于追踪功能,协助生产发布环境准备,以及快速修复实时在线问题。与关键分支不同,这些分支总是有一个有限的生命期,因为他们最终会被移除。

我们用到的分支类型包括:

  • 功能分支
  • 发布分支
  • 热修复分支

每一种分支有一个特定目的,并且受限于严格到规则,比如:可以用哪些分支作为源分支,哪些分支能作为合并目标。我们马上将进行演练。

从技术角度来看,这些分支绝不是特殊分支。分支的类型基于我们使用的方法来进行分类。它们理所当然是普通的Git分支。

功能分支

可能是develop分支的分支版本,最终必须合并到develop分支中。

分支命名规则:除了master、develop、release-*、orhotfix-*之外,其他命名均可。

功能分支(有时被称为topic分支)通常为即将发布或者未来发布版开发新的功能。当新功能开始研发,包含该功能的发布版本在这个还是法确定发布时间的。功能版本的实质是只要这个功能处于开发状态它就会存在,但是最终会或合并到develop分支(确定将新功能添加到不久的发布版中)或取消(譬如一次令人失望的测试)。

功能分支通常存在于开发者的软件库,而不是在源代码库中。

创建一个功能分支

开始一项功能的开发工作时,基于develop创建分支。

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

合并一个功能到develop分支

完成的功能可以合并进develop分支,以明确加入到未来的发布:

$ git checkout develop
Switched to branch develop
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
DeleTED branch myfeature (was 05e9557).
$ git push origin develop

no-ff标志导致合并操作创建一个新commit对象,即使该合并操作可以fast-forward。这避免了丢失这个功能分支存在的历史信息,将该功能的所有提交组合在一起。 比较:

后一种情况,不可能从Git历史中看到哪些提交一起实现了一个功能——你必须手工阅读全部的日志信息。如果对整个功能进行回退 (比如一组提交),后一种方式会是一种真正头痛的问题,而使用no-ffflag的情况则很容易.

是的,它会创建一个新的(空)提交对象,但是收益远大于开销。

不幸的是,我还没找到一种方法,让no-ff时作为合并操作的默认选项,但它应该是可行的。

Release 分支

Release分支可能从develop分支分离而来,但是一定要合并到develop和master分支上,它的习惯命名方式为:release-*。

Release分支是为新产品的发布做准备的。它允许我们在最后时刻做一些细小的修改。他们允许小bugs的修改和准备发布元数据(版本号,开发时间等等)。当在Release分支完成这些所有工作以后,对于下一次打的发布,develop分支接收features会更加明确。

从develop分支创建新的Release分支的关键时刻是develop分支达到了发布的理想状态。至少所有这次要发布的features必须在这个点及时合并到develop分支。对于所有未来准备发布的features必须等到Release分支创建以后再合并。

在Release分支创建的时候要为即将发行版本分配一个版本号,一点都不早。直到那时,develop分支反映的变化都是为了下一个发行版,但是在Release分支创建之前,下一个发行版到底叫0.3还是1.0是不明确的。这个决定是在Release分支创建时根据项目在版本号上的规则制定的。

创建一个release分支

Release分支是从develop分支创建的。例如,当前产品的发行版本号为1.1.5,同事我们有一个大的版本即将发行。develop 分支已经为下次发行做好了准备,我们得决定下一个版本是1.2(而不是1.1.6或者2.0)。所以我们将Release分支分离出来,给一个能够反映新版本号的分支名。

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified sucCESsfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

创建新分支以后,切换到该分支,添加版本号。这里,bump-version.sh 是一个虚构的shell脚本,它可以复制一些文件来反映新的版本(这当然可以手动改变目的就是修改一些文件)。然后版本号被提交。

这个新分支可能会存在一段时间,直到该发行版到达它的预定目标。在此期间,bug的修复可能被提交到该分支上(而不是提交到develop分支上)。在这里严格禁止增加大的新features。他们必须合并到develop分支上,然后等待下一次大的发行版。

完成一个release分支

当一个release分支准备好成为一个真正的发行版的时候,有一些工作必须完成。首先,release分支要合并到master上(因为每一次提交到master上的都是一个新定义的发行版,记住)。然后,提交到master上必须打一个标签,以便以后更加方便的引用这个历史版本。最后,在release分支上的修改必须合并到develop分支上,以便未来发行版也包含这些bugs的修复。

在Git中的前两步是:

$ git checkout master
Switched to branch master
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

发行版现在已经完成,为以后引用打上标签。

编辑:你可能也想使用The-sor-u flags来标记你的标签。

为了是修改保持在release分支上,我们需要合并这些到develop分支上去,在Git上:

$ git checkout develop
Switched to branch develop
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

这个步骤可能会导致合并冲突(可能由于改变版本号更是如此)。如果是这样,修复它然后提交。

现在我们真正的完成了,这个release分支将被删除,因为我们不再需要它了。

$ git branch -d release-1.2
DeleTED branch release-1.2 (was ff452fe).

热修复分支

可以基于master分支,必须合并回develop和master分支。
分支名约定:hotfix-*

热修复分支与发布分支很相似,他们都为新的生成环境发布做准备,尽管这是未经计划的。他们来自生产环境的处于异常状态压力。当生成环境验证缺陷必须马上修复是,热修复分支可以基于master分支上对应与线上版本的tag创建。

其本质是团队成员(在develop分支上)的工作可以继续,而另一个人准备生产环境的快速修复。

创建修补bug分支

hotfix branch(修补bug分支)是从Master分支上面分出来的。例如,1.2版本是当前生产环境的版本并且有bug。但是开发分支(develop)变化还不稳定。我们需要分出来一个修补bug分支(hotfix branch)来解决这种情况。

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified sucCESsfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

分支关闭的时侯不要忘了更新版本号(bump The version)

然后,修复bug,一次提交或者多次分开提交。

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

完成一个hotfix分支

完成一个bugfix之后,需要把butfix合并到master和develop分支去,这样就可以保证修复的这个bug也包含到下一个发行版中。这一点和完成release分支很相似。

首先,更新master并对release打上tag:

$ git checkout master
Switched to branch master
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

编辑:你可能也会想使用 -sor-u 参数来对你的tag进行加密

下一步,把bugfix添加到develop分支中:

$ git checkout develop
Switched to branch develop
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

规则的一个例外是: 如果一个release分支已经存在,那么应该把hotfix合并到这个release分支,而不是合并到develop分支。当release分支完成后, 将bugfix分支合并回release分支也会使得bugfix被合并到develop分支。(如果在develop分支的工作急需这个bugfix,等不到release分支的完成,那你也可以把bugfix合并到develop分支)

最后,删除临时分支:

$ git branch -d hotfix-1.2.1
DeleTED branch hotfix-1.2.1 (was abbe5d6).

摘要

尽管这个分支模型没有任何震撼的新东西, 文章开头的图表在我们的项目中表现出惊人的实用性。它形成了一个优雅的思维模型,易于领悟并使团队成员发展出对分支和发布过程的共同理解。

这里提供一份高质量PDF格式图表。去吧,把它挂载墙上以便能随时快速参考。

介绍一个成功的 Git 分支模型 Release 分支的更多相关文章

  1. 一个成功的 Git 分支模型

    在这篇文章中介绍的开发模型在大约一年前已经在我的私有项目和工作引入的,而且已经被证明是非常成功的.我想写一些关于这个模型的东西已经好一段时间了,但是一直苦于没有时间,不过现在可以了.我不想探讨任何项目 ...

  2. 一个成功的 Git 分支模型(适用于商业应用开发)

    在这篇文章中,我将推广一下大约一年前我介绍过的一些项目(公私皆有)中使用的开发模型,它们的结果都非常成功.有段时间我非常想写出来分享一下,但是我至今才抽出时间来.我不会言及任何项目细节,仅讨论分支策略 ...

  3. 一个成功的Git分支模型

    原文: http://www.juvenxu.com/2010/11/28/a-successful-git-branching-model/ 本文中我会展示一种开发模型,一年前该模型就已经被我用在所 ...

  4. 项目开发中git常用命令、git工作流、git分支模型

    #新建代码库git init # 在当前目录新建一个Git代码库git init [project-name] # 新建一个目录,将其初始化为Git代码库git clone [url] # 下载一个项 ...

  5. Git flow的分支模型与及经常使用命令简单介绍

    Git flow是git的一个扩展集,它基于Vincent Driessen 的分支模型,文章"A successful Git branching model"对这一分支模型进行 ...

  6. 近期关于CI/CD策略以及git分支模型的思考

    近两个月由于个人处于新环境.新项目的适应阶段,没怎么提笔写些文章.中间有好几个想法想记录下来分享,但受限于没有很好的时间段供自己总结思考(也可以总结为间歇性懒癌和剧癌发作),便啥也没有更新.借这个周末 ...

  7. Git 分支模型

    翻译自:https://nvie.com/posts/a-successful-git-branching-model/ 在这篇文章中,主要介绍 Git 分支模型.不会谈论任何项目的细节,只讨论分支策 ...

  8. Git 最佳实践:分支管理

    5月份,为统一团队git分支管理规范,刚开始准备自己写,在网上搜了下,发现不少不错的git分支管理实践.最后我为团队选择了这个git分支管理实践 A successful Git branching ...

  9. 【技术博客】Git Flow模型管理代码版本

    参考GIT版本管理:Git Flow模型,在此基础上加入了自己的理解,增加人员分工和相应代码,并根据本次项目的实际情况进行相应修改. 在本学期的软件工程开发过程中,我们从alpha阶段就使用了git ...

随机推荐

  1. fiddler使用之坑

    今天一上午都在搞fiddler,之前可以抓到浏览器的请求,今天突然不行了,弄得我花一上午时间去设置浏览器代理的事情,遇到各种各样的问题,现将解决办法记录如下: 1.原来fiddler安装在E盘中,安装 ...

  2. 这样就算会了PHP么?-8

    关于PHP的一些时间函数,这个小节完之后,就可以进入PHP比较高级的内容啦... <?php date_default_timezone_set("Asia/Shanghai" ...

  3. POJ 3525 Most Distant Point from the Sea

    http://poj.org/problem?id=3525 给出一个凸包,要求凸包内距离所有边的长度的最小值最大的是哪个 思路:二分答案,然后把凸包上的边移动这个距离,做半平面交看是否有解. #in ...

  4. Keil 3光标问题 以及汉字问题

    初次使用keil3,光标总是定位不准,修改十分麻烦,google后解决问题,修改tools.ini如下(蓝色为加入项): NAME="YGLenovo User", "a ...

  5. 再论dynamic 关键字

    有关动态数据类型 ,大家估计在实际中用的比较多了,不是很陌生.有关自己在项目中 的实际钉子总结: 1  匿名对象中的字段,是只读的,不能赋值 2 动态类型 指向强类型实例,注意观察内部的属性可访问性 ...

  6. mina变长帧处理

    通过mina进行TCP开发,遇到对数据进行解码处理,网上例子基本都是帧长度定长,在doDecode中通过in.remaining()就可以判断得到的数据帧长度为多少,是否能够正常解析,长度不对返回fa ...

  7. HDU 4276 The Ghost Blows Light

    K - The Ghost Blows Light Time Limit:1000MS     Memory Limit:32768KB     64bit IO Format:%I64d & ...

  8. 我所理解的设计模式(C++实现)——状态模式(State Pattern)

    概述: 看看我们平时用的开关,同样一个开关他有2种状态:开和关,当她处于不同的状态的时候她的行为是不一样的,比如当她是开着的时候,你按她一下,她就变成了关闭状态,她是关着的时候按她一下,她就变成了开着 ...

  9. Android Studio:You need to use a Theme.AppCompat theme (or descendant) with this activity. AlertDialog

    学习<第一行代码>的时候遇到的问题. Process: com.example.sevenun.littledemo, PID: 2085 java.lang.RuntimeExcepti ...

  10. poj 1328 Radar Installation(贪心)

    Description Assume the coasting is an infinite straight line. Land is in one side of coasting, sea i ...