版本控制经验分享

主分支，命名为master，版本分支发版后合并到该分支，只有生产部署权限可以合并其它分支到该分支；

版本分支，命名为release_版本号_发版时间，从master创建，版本发布使用，版本发布前或者发布后打tag标签，也可以不打标签看自己，版本发布后合并代码到master。

功能分支，命名为feature_[需求编号|任务编号]，从版本分支创建，每个功能分支对应一个需求。功能分支是开发人员使用的分支，开发人员的代码提交到功能分支后，在合并到版本分支之前先把版本分支代码合并一次到自己的功能分支，然后再合并到版本分支。

缺陷分支，命名为bugfix_[缺陷编号]，从版本分支创建，每个缺陷分支对应一个bug，如果觉得分支太多可以不用缺陷分支，对于缺陷的修改可以放在功能分支上。

注意事项

• 功能分支合并到版本分支的权限控制，开发人员只能发起合并请求，开发经理审批合并请求。
• 版本分支发布后也只能由开发经理合并版本分支到master分支。
• 功能分支发起合并请求前开发人员一定先把版本分支合并一次到自己的功能分支上，再发起合并请求。

上面这套流程用于单个客户的版本管理或者是自己公司产品的版本管理是最好的，对于版本的管控比较有力度，特别是结合jira可以清楚的看到每个版本的完成情况，可以清楚的看出哪个需求没完成或者哪个缺陷没修复。在版本上线后发现问题可以剔除有问题的功能，直接剔除有问题功能的分支或者缺陷分支即可。

在前期版本规划的时候就可以知道每个版本包含哪些需求，包括后面发现的缺陷修复，而每个需求每个缺陷都有对应的负责人，管理起来非常方便。按照版本规划走，预留一定的缺陷修改时间，不加班少扯皮。

如果是对应多个客户的情况，一是复制一份代码从新创建git库，每个git库对应一个客户，另一个方案是同一个git对应多个客户，分支命名上加上一个客户表示，比如主分支名master_hw，版本分支名release_hw_版本号_发版时间，功能分支名feature_hw_[需求编号|任务编号]等。

当然每个git就是一个项目，项目一般会区分环境，一般是uat环境，fat环境，dev环境等；一般是功能分支部署到dev环境，便于开发人员自己测试；用版本分支部署到fat环境，便于测试人员测试。

对于权限的控制，dev环境的开发人员有部署权限，fat测试人员有部署权限，uat环境的只能由运维人员操作。

流程是死的人是活的，找到合适自己项目的流程就可以了，不必死套流程，合适自己的才是最好的。