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 开发被阻塞。