版本管理(4)- 简单清晰的分支策略有助于开发(Gitflow）

其它集中式分支策略

这里先挖个大坑，以后再填。

git 的分支策略

git 在一开始出现的时候真是无比的难用，后来在一些底层 git 命令的基础上封装了一层，封装后的命令还是可以接受的。不过有的时候还是需要使用一些比较底层的命令才能获取到更多的信息。

集中式的版本管理工具可以做到精细化的权限管理，可以针对分支、tag 、目录等授权，而 git 一开始是做不到这一点的，除非借助其它辅助工具。这也就导致了很难有一个大家都认可的分支使用方式，因为比较随意，每个人都可以创建分支，都可以 push 上来，所以容易引起混乱。而这个时候一个俊朗无比、天真无邪的哥们 Vincent Driessen 设计了一个使用比较多的 git 分支模型 - Gitflow

Gitflow

git-flow.png

我觉得只要使用过 git 的人肯定都见过这张图。简单解释下这张图是怎么运转的：

• master：主要用来做发布。接受来自 develop 分支的代码合并，然后打 tag 发布。
• develop：从 master 拉出 develop 分支。develop 是当前要发布版本的集成分支，一旦达到稳定状态，则合并到 master，然后在 master 上打个 tag，在 master 上进行发布
• feature branch : 可翻译成特性分支，功能分支。 实际工作中一般 FB-xx 的形式命名，也可以直接以要修复的 bug ID 来当做分支名。每当需要完成一个功能或者特性的时候，从 develop 拉出一个 feature branch，进行相关开发工作，当完成以后需要把代码合并到 develop 分支

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

• release branch: 发布分支。一般命名为 release- , rel- ，rb- 等。当 develop 分支趋于稳定的时候，从 develop 分支拉出 release branch，进行代码稳定的工作，一旦觉得可以作为正式发布的版本，则把 release branch 的代码合并到 master，合并回 develop

$ 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

• hotfix branch:缺陷修复分支，一般 hotfix- 或者 hf- 命名。是指线上有重大 bug 了，等不到下一个计划发布的版本修复了，必须立刻修复。这个时候，从 master 发布版本的 tag 上直接拉出一个 hotfix 分支，在这hotfix 分支上修复线上 bug，修复完成后，把代码合并回 master 打 tag发布，同时还要合并到 develop 带入下个发布版本。

$ 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

小结

本文把 Gitflow 的工作模式又重复了一遍。经过这么一分析是不是觉得 Gitflow 和分支开发主干上线神似？细细品味，觉得真的是啊，只不过中间多了一个 develop 分支用来做集成而已。如果当 develop 分支上功能开发完且可以发布的时候，直接在 develop 分支上打个 tag 发布，是不是就是分支开发主干发布了？是不是觉得我又把很多人绕沟里去了？

只要你对分支模型真的懂了，那么怎么折腾都不至于把你绕晕。