Gitflow 工作流
##简介
[slide]
feature
(多个、玫红)。主要是自己玩了,差不多的时候要合并回develop去。从不与master交互。develop
(1个、黄色)。主要是和feature以及release交互。release
(同一时间1个、绿色)。总是基于develop,最后又合并回develop。当然对应的tag跑到master这边去了。生命周期很短,只是为了发布hotfix
(同一时间1个、红色)。总是基于master,并最后合并到master和develop。生命周期较短,用了修复bug或小粒度修改发布。master
(1个蓝色)。没有什么东西,仅是一些关联的tag,因从不在master上开发。
[slide]
master
和develop
都具有象征意义。master分支上的代码总是稳定的(stable build),随时可以发布出去。develop上的代码总是从feature上合并过来的,可以进行Nightly Builds,但不直接在develop上进行开发。当develop上的feature足够多以至于可以进行新版本的发布时,可以创建release分支release
分支基于develop,进行很简单的修改后就被合并到master,并打上tag,表示可以发布了。紧接着release将被合并到develop;此时develop可能往前跑了一段,出现合并冲突,需要手工解决冲突后再次合并。这步完成后就删除release分支。- 当从已发布版本中发现bug要修复时,就应用到
hotfix
分支了。hotfix基于master分支,完成bug修复或紧急修改后,要merge回master,打上一个新的tag,并merge回develop,删除hotfix分支。 - 由此可见release和hotfix的生命周期都较短,master/develop虽然总是存在但却不常使用。
[slide]
分支详解
主分支 (Historical Branches)
- 主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和development分支。
[slide]
master 分支
master分支上存放的应该是随时可供在生产环境中部署的代码(Production Ready state)。当开发活动告一段落,产生了一份新的可供部署的代码时,master分支上的代码会被更新。同时,每一次更新,最好添加对应的版本号标签(TAG)。
[slide]
develop分支
develop分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码(Nightly build)。因此这个分支有时也可以被称作整合分支(integration branch)。
[slide]
辅助分支
- 用于开发新功能时所使用的feature分支;
- 用于辅助版本发布的release分支;
- 用于修正生产代码中的缺陷的hotfix分支。
[slide]
feature 分支
使用规范:
- 可以从develop分支发起feature分支
- 代码必须合并回develop分支
- feature分支(有时也可以被叫做“topic分支”)通常是在开发一项新的软件功能的时候使用,这个分支上的代码变更最终合并回develop分支或者干脆被抛弃掉(例如实验性且效果不好的代码变更)
[slide]
release分支
- 可以从develop分支派生
- 必须合并回develop分支和master分支
- 分支命名惯例:release-*