release分支

Release分支主要目的是用于大型项目中各个特性分支开发完毕之后，定义了一个准备就绪到工作完成的中间阶段，一般会和项目的管理工作结合进行，比如进行发布的申请和批准，结果确认和审核，
由于不同的开发流程不仅需要考虑到技术本身，还要考虑到各个公司实际的流程规范/audit等等，以保证release能够正常进行。虽然可以在此分支上进行小量的修改，但是大规模的功能修改请尽可能地规避。

Release分支在使用时候一般遵循如下步骤：

步骤	内容	git 命令
Step 1	以develop分支为基础创建release分支	svn copy develop分支URL releases分支下的URL
Step 2	做Release准备或者小的bug对应，然后进行提交	svn commit -m “release相关信息”（没有修改可跳过）
Step 3	切换至master分支	cd ../../master
Step 4	合并Release分支内容到master分支并提交	svn merge release分支名称; svn commit
Step 5	切换至develop分支	cd ../develop（没有修改可跳过）
Step 6	合并Release分支内容到develop分支并提交	svn merge release分支名称; svn commit （没有修改可跳过）

Release分支的使用注意事项如下：

注意事项	详细说明
源分支	release分支需要以develop分支为源分支
目标分支	特性分支的合并目标分支为develop分支和master，在此分支上的诸如小的bug修正必须同时反映到develop分支和master分支，不然就会给下次发布留下隐患
分支命名	gitflow建议以release-*进行分支的命令，但是由于svn方式的不同，所有的release分支已经在releases以下，建议不要再使用重复信息。
分支删除	gitflow建议删除分支，但是根据svn的特点以及使用上的习惯，使用svn方式的话，releases即普通方式下的tags下的分支是为了记录发布历史的，因为有这个特殊的用途，所以建议不要删除
分支只读	gitflow的release分支是可写的，而传统svn的分支模型在tags下的分支一般是只读的，如果希望对其进行修改，一些做法是在此分支上svn cp生成新的分支，而使用gitflow则可以不必如此麻烦，关键是需要同步到哪里才能导致所做修改不至于丢失。
tag	在gitflow中会创建tag，而svn中不删除的那个分支实际就是tag，所以实现起来反而更加方便

模拟

场景说明：以分支开发为基础的开发，在某一特性分支开发完成之后，所做的内容已经合并回开发主线，开发主线上保存的是随时可以进行上线的内容，整体来说只是比master稍新而已，gitflow的分支模型中有两条长期分支master和develop，这两条分支之间是有一定的延迟的，而release分支就是为了建立二者同步的机制。在上篇文章中特性分支F1001开发完毕之后合并回了develop分支，release分支的场景就是将develop分支上开发的内容和F1001的内容进行发布

Step 1： 以develop分支为基础创建release分支

[root@platform gitflow-repo]# svn cp svn://192.168.163.129:3690/gitflow-repo/develop svn://192.168.163.129:3690/gitflow-repo/releases/F1001.01

Committed revision 10.
[root@platform gitflow-repo]# 

Step 2： 做Release准备或者小的bug对应，然后进行提交

[root@platform gitflow-repo]# svn update
Updating '.':
A    releases/F1001.01
A    releases/F1001.01/C1
A    releases/F1001.01/C2
A    releases/F1001.01/C3
Updated to revision 10.
[root@platform gitflow-repo]# cd releases/F1001.01/
[root@platform F1001.01]# ls
C1  C2  C3
[root@platform F1001.01]# touch C4; svn add C4; svn commit -m "add in release F1001.01"
A         C4
Adding         C4
Transmitting file data .
Committed revision 11.
[root@platform F1001.01]#

Step 3： 切换至master分支

[root@platform F1001.01]# cd ../../master
[root@platform master]#

Step 4： 合并Release分支内容到master分支并提交

[[email protected] master]# svn merge svn://192.168.163.129:3690/gitflow-repo/releases/F1001.01
--- Merging r3 through r9 into '.':
A    C2
A    C3
 U   .
--- Recording mergeinfo for merge of r3 through r9 into '.':
 G   .
--- Merging r10 through r11 into '.':
A    C4
--- Recording mergeinfo for merge of r10 through r11 into '.':
 G   .
[[email protected] master]# svn commit -m "release for F1001.01"
Sending        .
Adding         C2
Adding         C3
Adding         C4

Committed revision 12.
[[email protected] master]#

Step 5： 切换至develop分支

[root@platform master]# cd ../develop/
[root@platform develop]#

Step 6： 合并Release分支内容到develop分支并提交

[[email protected] develop]# svn merge svn://192.168.163.129:3690/gitflow-repo/releases/F1001.01
--- Merging r10 through r12 into '.':
A    C4
--- Recording mergeinfo for merge of r10 through r12 into '.':
 U   .
[[email protected] develop]# svn commit -m "release for F1001.01"
Sending        .
Adding         C4

Committed revision 13.
[[email protected] develop]# 

总结

release分支搭建了一座桥梁用于链接develop和master。最简单的release直接将内容合并到master就完成了，但是考虑到release过程中的bug对应，同时这次对应不会被后续的发布所覆盖，就会复杂一些。
在实际中，release虽然是对master的操作，但是更多考验的是develop分支管理的好坏，比如按照发布时间来看，很晚才会发布的代码很早就合并进来并不一定是很赞的事情，或者明显来说是会很痛苦的事情，每次发布你都需要将这些代码移除去，发布完毕后再合进来，这也是DevOps实践中避免的浪费，这些都需要仔细地考虑。