这是我们团队的 Git 分支管理规范。每个人对工具的使用往往各有偏好,各种方法各有利弊,无所谓对错。但涉及团队协作的方面需要有一些一致的规范,所以请大家务必遵守。
除了一致性之外,这个规范的目的是以下几点:
每个官方的 repo(leancloud/
下的都是官方 repo)有且仅有以下的 branch 和 tag。
Branch: master
和 release
。其中 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。
master
;master
branch 的代码进行测试,如果发现 bug,把对应的 bugfix merge 到 master
;release
branch,并从当前的 master
创建新的 release
branch;release
branch 发起新的 build 并发布;release
branch 打上对应版本的 tag。这里的 bugfix 指的是修复已经发布的程序(release
branch)中的缺陷。master
里的 bug 请直接 merge bugfix 到 master
。
master
中还存在,请先 merge bugfix 到 master
,否则跳到下一步;release
branch 从 master
cherrypick 修复该缺陷的一个或多个 commit;release
branch;release
branch 打上递增的 tag。比如,如果上一个 tag 是 2.5.1
,这个 tag 应该是 2.5.2
;如果上一个是 2014.11.13
,这个就是 2014.11.13a
。并不是每个 bug 都有专门发布 bugfix 版的必要,对于不紧急的 bug,可以在 master
里 fix 后随下一个版本发布。