中文链接:http://roclinux.cn/?p=2129#more-2129
GIT是一个无中心的分布式版本控制系统,但为了方便管理,最好是维护一个中心版本库。
一个中心版本库(我们叫它origin)应该至少包括两个分支,即“主分支(master)”和“开发分支(develop)”。要确保团队成员从主分支(master)获得的都是处于可发布状态的代码,而从开发分支(develop)应该总能够获得最新开发进展的代码。
为了管理上的方便至少还应设置三类“辅助分支”,称之为“Feature branches”,“Release branches”,“Hotfix branches”。
到此,形成了如下这张最重要的组织组,包含了两个粗体字分支(master/develop)和三个细体字分支(feature/release/hotfixes)。其中“辅助分支”的最大特点就是“生命周期十分有限”,完成使命后即可被清除。
“Feature branches”,起源于develop分支,最终也会归于develop分支。“Feature branches”常用于开发一个独立的新功能,且其最终的结局必然只有两个,其一是合并入“develop”分支,其二是被抛弃。最典型的“Fearture branches”一定是存在于团队开发者那里,而不应该是“中心版本库”中。
“Feature branches”的生命期中会有如下操作:
![merge-without-ff merge-without-ff](http://roclinux.cn/wp-content/uploads/2010/12/merge-without-ff.png)
“Release branch”,起源于develop分支,最终归于“develop”或“master”分支。这类分支建议命名为“release-*”。“Relase branch”通常负责“短期的发布前准备工作”、“小bug的修复工作”、“版本号等元信息的准备工作”。与此同时,“develop”分支又可以承接下一个新功能的开发工作了。“Release branch”产生新提交的最好时机是“develop”分支已经基本到达预期的状态,至少希望新功能已经完全从“Feature branches”合并到“develop”分支了。
在一段短时间内,在“Release branches”上,我们可以继续修复bug。在此阶段,严禁新功能的并入,新功能应该是被合并到“develop”分支的。经过若干bug修复后,“Release branches”上的代码已经达到可发布状态,此时,需要完成三个动作:第一是将“Release branches”合并到“master”分支,第二是一定要为master上的这个新提交打TAG,第三是要将“Release branches”合并回“develop”分支。
“Release branches”生命期中会有如下操作:
“Hotfix branches”源于“master”,归于“develop”或“master”,通常命名为“hotfix-*”,“Hotfix branches”类似于“Release branch”,但产生此分支总是非预期的关键BUG。建议设立“Hotfix branches”的原因是:希望避免“develop分支”新功能的开发必须为BUG修复让路的情况。
“Hotfix branches”生命期中有如下操作: