分支
topic分支和merge分支的运用实例
我们用简单的实例来讲解topic分支和merge分支的操作方法。
例如,在开发功能的topic分支操作途中,需要修改bug。
这时,merge分支还是处于开发功能之前的状态。在这里新建修改错误用的主题分支,就可以从开发功能的作业独立出来,以便开始新的工作。
完成bug修正的工作后,把分支导入到原本的merge分支后就可以公开了。
回到原本的分支继续进行开发功能的操作。
但是,如果要继续进行操作,你会发现需要之前修正bug时提交X的内容。有2种导入提交X的内容的方法:一种是直接merge,另一种是和rebase导入提交X的合并分支。
这里我们使用rebase合并分支的方法。
在导入提交X的内容的状态下继续进行开发功能。
这样,有效地利用分支的话就可以同时进行不同的作业了。
专栏「A successful Git branching model」
作为Git的分支的用例 ,这里介绍 A successful Git branching model
原文:http://nvie.com/posts/a-successful-git-branching-model/
这个用例主要分为
- 主分支
- 特性分支
- release分支
- hotFix分支
分别使用4个种类的分支来进行开发的。
主分支
主分支有两种:master分支和develop分支
- mastermaster分支只负责管理发布的状态。在提交时使用标签记录发布版本号。
- developdevelop分支是针对发布的日常开发分支。刚才我们已经讲解过有合并分支的功用。
特性分支
特性分支就是我们在前面讲解过的topic分支的功用。
这个分支是针对新功能的开发,在bug修正的时候从develop分支分叉出来的。基本上不需要共享特性分支的操作,所以不需要远端控制。完成开发后,把分支合并回develop分支后发布。
release分支
release分支是为release做准备的。通常会在分支名称的最前面加上release-。release前需要在这个分支进行最后的调整,而且为了下一版release开发用develop分支的上游分支。
一般的开发是在develop分支上进行的,到了可以发布的状态时再创建release分支,为release做最后的bug修正。
到了可以release的状态时,把release分支合并到master分支,并且在合并提交里添加release版本号的标签。
要导入在release分支所作的修改,也要合并回develop分支。
hotFix分支
hotFix分支是在发布的产品需要紧急修正时,从master分支创建的分支。通常会在分支名称的最前面加上 hotfix-。
例如,在develop分支上的开发还不完整时,需要紧急修改。这个时候在develop分支创建可以发布的版本要花许多的时间,所以最好选择从master分支直接创建分支进行修改,然后合并分支。
修改时创建的hotFix分支要合并回develop分支。