版权声明：本文为博主原创文章，未经博主允许欢迎转载，但请注明出处。 https://blog.csdn.net/liumiaocn/article/details/81942188
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分支并提交
[root@platform 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 .
[root@platform master]# svn commit -m "release for F1001.01"
Sending .
Adding C2
Adding C3
Adding C4
Committed revision 12.
[root@platform master]#Step 5： 切换至develop分支
[root@platform master]# cd ../develop/
[root@platform develop]#Step 6： 合并Release分支内容到develop分支并提交
[root@platform 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 .
[root@platform develop]# svn commit -m "release for F1001.01"
Sending .
Adding C4
Committed revision 13.
[root@platform develop]# 总结
release分支搭建了一座桥梁用于链接develop和master。最简单的release直接将内容合并到master就完成了，但是考虑到release过程中的bug对应，同时这次对应不会被后续的发布所覆盖，就会复杂一些。
在实际中，release虽然是对master的操作，但是更多考验的是develop分支管理的好坏，比如按照发布时间来看，很晚才会发布的代码很早就合并进来并不一定是很赞的事情，或者明显来说是会很痛苦的事情，每次发布你都需要将这些代码移除去，发布完毕后再合进来，这也是DevOps实践中避免的浪费，这些都需要仔细地考虑。