##简介


[slide]

  1. feature(多个、玫红)。主要是自己玩了,差不多的时候要合并回develop去。从不与master交互。
  2. develop(1个、黄色)。主要是和feature以及release交互。
  3. release(同一时间1个、绿色)。总是基于develop,最后又合并回develop。当然对应的tag跑到master这边去了。生命周期很短,只是为了发布
  4. hotfix(同一时间1个、红色)。总是基于master,并最后合并到master和develop。生命周期较短,用了修复bug或小粒度修改发布。
  5. master(1个蓝色)。没有什么东西,仅是一些关联的tag,因从不在master上开发。

[slide]

  1. masterdevelop都具有象征意义。master分支上的代码总是稳定的(stable build),随时可以发布出去。develop上的代码总是从feature上合并过来的,可以进行Nightly Builds,但不直接在develop上进行开发。当develop上的feature足够多以至于可以进行新版本的发布时,可以创建release分支
  2. release分支基于develop,进行很简单的修改后就被合并到master,并打上tag,表示可以发布了。紧接着release将被合并到develop;此时develop可能往前跑了一段,出现合并冲突,需要手工解决冲突后再次合并。这步完成后就删除release分支。
  3. 当从已发布版本中发现bug要修复时,就应用到hotfix分支了。hotfix基于master分支,完成bug修复或紧急修改后,要merge回master,打上一个新的tag,并merge回develop,删除hotfix分支。
  4. 由此可见release和hotfix的生命周期都较短,master/develop虽然总是存在但却不常使用。

[slide]

分支详解

主分支 (Historical Branches)

  1. 主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和development分支。

[slide]

master 分支

master分支上存放的应该是随时可供在生产环境中部署的代码(Production Ready state)。当开发活动告一段落,产生了一份新的可供部署的代码时,master分支上的代码会被更新。同时,每一次更新,最好添加对应的版本号标签(TAG)。
[slide]

develop分支

develop分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码(Nightly build)。因此这个分支有时也可以被称作整合分支(integration branch)。

[slide]

辅助分支

  1. 用于开发新功能时所使用的feature分支;
  2. 用于辅助版本发布的release分支;
  3. 用于修正生产代码中的缺陷的hotfix分支。

[slide]

feature 分支

使用规范:

  1. 可以从develop分支发起feature分支
  2. 代码必须合并回develop分支
  3. feature分支(有时也可以被叫做“topic分支”)通常是在开发一项新的软件功能的时候使用,这个分支上的代码变更最终合并回develop分支或者干脆被抛弃掉(例如实验性且效果不好的代码变更)

[slide]

release分支

  1. 可以从develop分支派生
  2. 必须合并回develop分支和master分支
  3. 分支命名惯例:release-*