git 项目分支管理

2010年人家写的，(2010年我还不认识git)。原文在这http://nvie.com/posts/a-successful-git-branching-model/

做者以本身的项目经验，画了一个图，以下，全文都是以据这个图来讲的。

中间讲了为啥用git，为啥，每一个人理解都不同，讲也白讲,干脆不讲。而后说，他们怎么用git的。

他说，他们在开过程当中，用到5类分支，哪5类(所谓分类只是从功能名字上区分，git branch是平等的)

1，master

2，develop

以上两个，他们又被称为，主分支

3，feature

4，release

5， hotfix

这三个又被称为，支持分支

而后讲，这几个分支是干啥用到，何时建立。

1，master 分支，项目开始的始祖分支。项目不死，它就不灭。其余分支都是它的子孙分支。

这个分支上的代码是随时可上发生产，打tag的分支。不建议直接修改。只能由其余分支把代码合并上来。

 

2， develop  分支，它上面的代码老是，下个版本（有release版本号的）最新的代码。能够理解为，按项目计划主要功能的开发分支。也是CI工具的集成测试分支。每当这个分支上的代码测试完，能够上生产了，就须要先合并到master分支，指定一个版本号，打个tag。显然，它也是项目不死，这个分支就一直存在。

3， feature 分支，首先它是从develop分支拉出的分支，主要开发一些新功能，但这个功能何时上线，或发布在哪一个版本上还不肯定。反正单独开个分支，慢慢弄吧。还有，可能最后不被采用都有可能，而后分支删除。若是被采用了，首先要合并到develop分支。而后仍是删除这个分支。因此相对主分支，它是个短命的分支，开发完成，或者最后决定抛弃，就删除了。最后他还说，在合并 feature 到develop时，你用

git merge --no-ff myfeature

命令，其中加上--on-ff，和不加--on-ff区别以下图，主要是看日志时，知道有个 feature 分支存在过，方便看 feature 日志。

4，release 分支，这个分支也是从develop分支拉出来，而且必须合并回develop分支去的，能够命名为

release-*。release分支其实就是为立刻要分布的新版本准备的，支持随时测试，一些小bug的修复，作些新版本发布的基础数据的准备等。拉release分支讲究一个时间点。说，必须在全部准备在这个版本发布的feature分支代码都已经合并到develop分支后，而且develop分支上已经开发完成了，准备着个版本上的新功能，但可能此次发布的具体版本号尚未定下来的时候。你能够拉个 release分支 。也就是说，每次发布新版本前，都拉个realease分支来作测试发布。他说，这样作，能够保证develop分支能够继续接受别人新的代码。最后要先合并到maseter，而后打tag发布；

5，Hotfix 分支，命名能够是hotfix-*，这个分支是从master分支拉出的分支，这个分支和release分支类似的是，它也是准备发布生成环境的分支，只是它是因为，线上一个紧急须要解决的bug所引起的发布分支。它是master分支上对应生产环境版本的tag上拉取的分支。这个分支发布后，要同时合并到develop和master分支上。最后就能够删除这个分支了。 这样作，也是能够保证develop分支能够继续接受别人新的代码 ，不至于 develop 开发被阻塞。