代码分支管理指南

规范明确,清晰,一致性 Git 分支管理,帮助多人协作时更加和谐。

介绍

这是我的 Git 分支管理规范,应用于我的个人项目,以及由我主导的独立项目。

每个人对工具的使用往往各有偏好,各种方法各有利弊,无所谓对错。但涉及团队协作的方面需要有一些一致的规范,遵守一致的规范也能提升大家的效率。

除了一致性之外,这个规范的目的是以下几点:

我的 Git

私有仓:Bitbucket

公开仓:GitHub

规范

branch 和 tag

每个项目的 repo(Jarvis-Tang/ 下的都是我的 repo)有且仅有以下的 branch 和 tag。

Branch: masterrelease。其中 master 对应目前的开发分支,所有的 pull request 都应该发到这个分支。release 是当前发布的分支,在这个分支只能增加从 master cherrypick 过来的 commit。详见本文后面的说明。

Tag: 对应每个发布版本的 tag。SDK 和应用程序的 tag 遵照 <major>.<minor>.<patch> 的命名,如 2.5.1;服务端程序的 tag 以发布的日期命名,如 2014.11.13,如果有 bugfix,则在后面增加小写字母,如 2014.11.13 后是 2014.11.13a,然后是 2014.11.13b

目前还有部分 repo 包含多个独立部署的项目(如 uluru-platform)。在这样的 repo 打 tag 时需要附上项目名做前缀,如 bigquery-2.5.1。但我们需要逐步把这些项目拆分到独立的 repo。

发布新版流程

Bugfix 流程

这里的 bugfix 指的是修复已经发布的程序(release branch)中的缺陷。master 里的 bug 请直接 merge bugfix 到 master

其他

并不是每个 bug 都有专门发布 bugfix 版的必要,对于不紧急的 bug,可以在 master 里 fix 后随下一个版本发布。

在一个官方 repo 下只应该有以上说的 branch 和 tag,在开发过程中使用到的 feature branch 等请都放在个人的 fork,一律通过向 master 发 pull request 的方式给官方 repo 提交代码。