/ 编程

利用 git 分支的开发流程

这篇 2010 年的文章 A successful Git branching model 讲了一个比较合适的使用 git 进行版本控制的流程。主要是有两个主要分支:master 和 develop 分支,和其他辅助分支:feature 分支、release 分支、hotfix 分支。

主要分支

每个 repo 包含两个永远都不删除的分支

  • master 生产环境的版本
  • develop 待发布的最新开发代码分支

develop 分支不会进行很大的功能、特性方面的开发。当 develop 分支稳定,准备发布了,把它(经过 release 辅助分支)合并到 master 分支,然后以版本号打一个标签。

辅助分支

辅助分支最终会被删除,一般是这几个分支类型:feature 分支、release 分支 和 hotfix 分支

feature 分支

  • 一般由 develop 分支创建
  • 必须合并回 develop 分支
  • 不要命名为 master, develop, release-*, hotfix-* 这样的分支名称

通常这类分支只在开发者本地仓库,不在远程代码仓库里。

流程示例

git checkout -b myfeature develop

git checkout develop
git merge --no-ff myfeature
git branch -d myfeature
git push origin develop

release 分支

  • 一般由 develop 分支创建
  • 必须合并回 develop 和 master 分支
  • 命名约定为 release-*

用在新的正式发布版本之前,进行一些很小的 bug 修改,版本号,构建日期的修改
等等。创建 release 分支之后,就暂时不要再把包含重大新特性的 feature 分支
往 develop 分支合并了
。在创建 release 分支 时,就定下当前要发布的版本号

流程示例

git checkout -b release-1.2 develop
./bump-version.sh 1.2
git commit -a -m "Bumped version number to 1.2"

git checkout master
git merge --no-ff release-1.2
git tag -a 1.2

git checkout develop
git merge --no-ff release-1.2

git branch -d release-1.2

hotfix 分支

  • 一般从 master 分支创建
  • 必须合并回 develop 和 master 分支
  • 命名约定 hotfix-*

当线上版本出现需要立即修改的 bug 时,从 master 分支创建 Hotfix 分支。不影响其他分支的开发。

流程示例

git checkout -b hotfix-1.2.1 master
./bump-version.sh 1.2.1
git commit -a -m "Bumped version number to 1.2.1"

//fix bugs, then
git commit -m "Fixed severe production problem"

git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1

git checkout develop
git merge --no-ff hotfix-1.2.1

如果当前有 release 分支,就要把 hotfix 分支先合并到 release 分支里,而不是develop 分支,release 分支最终还是会合并到 develop 分支里。


一点个人理解

  • master 分支不直接合并 develop 分支,更不直接合并 feature 分支。

  • feature 生存周期可长可短,由开发时长决定。多个 feature 可以同时开发,完成后合并到 develop 分支里,删除掉对应的feature分支

  • release 和 hotfix 分支的生存周期短,它们从比较稳定的 develop 和 master分支上创建出来,做小的改动后合并回 develop 和 master 分支,删除相应分支。可以说是“随用随删”的。

  • 在 release 分支里生成较大版本号,在 hotfix 分支里生成小版本号,在 master分支里按照版本号打上 tag 标签。

Tips

  • 合并分支时加上 --no-ff 参数,不要 fast-forward
  • 不要看国内的译名为“一个成功的 git 分支模型”的文章,翻译的像坨屎一样
  • 阮一峰写的Git分支管理策略 ,同样基于开头提到的文章,比较简洁清晰,比其他那些译文好一万倍。