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