团队内代码分支管理
华通代码分支流程管理
随着华通开发团队成员的日益增加，系统的需求不断升级与变化，发布版本与时间经常不断变化，代码提交分支的规范性就极其重要，为了适应这一变化，我们引入目前互联网开源社区标准的git flow流程来管理代码。
以下是一个标准的git flow代码分支管理流程图：
根据华通团队的实际情况，我们将develop分支省去，目前只保留master、feature、release、hotfix四个分支。
tag我认为不是分支，只是版本记录的镜像，也缺一不可。
有一个长期分支，master分支，也是默认分支。
各分支功能及作业
master
主分支，永远保持稳定的状态，切下来就能正常运行，不允许任何成员直接提交，应该禁用成员直接push代码，只能通过Merge Request合并代码。
理论上，主分支的代码和生产上运行的代码是要保持一致的。
feature
功能分支，基于master，开发新功能时从master新建分支开发，完成后合并回master。
feature分支只用来功能代码提交，未提测的代码提交，已提测的代码尽量不要在feature上提交。
华通团队建议按照``软件版本号+迭代版本号命名，如华通本次迭代版本为2.9.4, 软件版本号为1.0.2，则新建功能分支为：feature/1.0.2_v2.9.4。
release
准备发布的分支状态，用来预发、修复bugs，基于 master, 完成后 merge 回 master。
在华通项目团队中，开发人员提测的时候，测试人员就从master分支中拉release分支,测试出的bug，开发人员在release分支上进行修复。
hotfix
紧急修复线上版本的问题, 等不及 release 版本就必须马上上线. 基于 master/tag, 完成后 merge 回master。
如果当前还有新功能release分支，也同步到release分支上。
理论上master分支代码应该和生产上一致，所以hotfix应尽量从master上拉取，但如果有并行开发的问题，就建议直接从tag镜像上拉代码。
tag
版本镜像，理论上不属于代码分支，记录release发布版本的镜像，最新的tag应该是和生产保持一致的。
分支走向是这样的：
代码分支各岗位分工与流程
【测试人员】
1. 收到提测申请后，从master分支上拉取release分支。
2. release分支建议命名：release/软件版本号_迭代版本号。
3. 测试出的bug，开发人员在release分支上进行修复。
4. release分支测试通过后，测试人员发邮件通知开发人员，测试全部通过，可进行生产发布。
5. 开发人员收到邮件后，将release分支代码合并到master,运维发布完release分支代码后，测试人员打tag。
【ps】：
release分支理论上会要求在建立分支时，将发布内容都写在分支描述上，这样测试人员也会更明确本次的测试范围。
生产发布完成并合并完代码后，建议release分支即时删除。
【开发人员】
- 每个项目或者代码仓库都应该指派一个主开发人员，主开发人员负责监督代码分支策略的规范性，督促成员严格按照代码分支策略执行。
3. 开发人员在开发期间，只能在feature分支上提交代码，提测后只能在release分支上提交代码。
4. 主开发人员在收到测试通过消息或者邮件时，将release代码合并到master。
以下为代码分支提测流程图：
