前言
毕业时进了一家小型项目外包公司，代码版本管理工具用的是SVN，几个人开发一个项目时，每个人开发完自己的功能后，使用svn commit提交代码到仓库，然后配置的勾子会自动把代码拉到测试环境，测试通过之后，在正式环境的服务器使用svn update命令将代码更新到最新版本。平时下班前会提交代码到仓库，如果遇到某个同事开发进度较慢，要优先发布其它同事完成的功能，就需要将没开发好的功能代码先注释掉，或者等到那个同事开发完再进行发布，那时候也没有深入研究svn有没有更好的办法解决这种问题。在第二家公司用的是GIT，在开发新能时，首先会基于master分支创建一个新版本分支，例如2.7.1分支，用来开发2.7.1版本，然后参与这个版本开发的人员，从这个2.7.1分支再切一个属于自己的分支，例如feature-basil-2.7.1，开发完成后发起合并到2.7.1请求，通过之后拉取代码到测试环境测试，测试通过只有，再把2.7.1合并到master，然后拉取代码到正式环境，那时候只知道按照这样的流程走，没搞清楚为什么要这样搞，后面用的多了，就渐渐明白了一些git的分支管理与多人协作方式。接下来讲的是目前所在公司的Git代码管理与协作方式。
基于分支发布的代码管理与协作方式
分支说明
主要包括6个分支，常驻分支有production、dev、test、preOnline，临时分支有feature、hotfix
production生产分支
用于生产发布，保存着最新生产环境的代码，不允许在此分支上直接修改，只能通过preOnline分支进行合并
preOnline预上线分支
用于预上线测试，不允许在此分支上直接修改，只能通过feature或hotfix分支进行合并
test测试分支
用于测试，不允许在此分支上直接修改，只能通过其它分支进行合并
dev开发分支
用于开发，不允许在此分支上直接修改，只能通过其它分支进行合并
feature功能分支
基于production，用于开发新功能
hotfix bug修复分支
基于production，用于修复bug
开发场景工作流说明
新功能开发
- 例如A、B两位同事共同开发feature-1.0.0版本，这时候一般会划分为两个模块，一人负责一个模块。首先从
production分支切出feature-1.0.0分支，然后A和B分别从feature-1.0.0分支切出自己的本地分支feature-1.0.0-A和feature-1.0.0-B，A、B开发完后将本地feature-1.0.0-A和feature-1.0.0-B合并到feature-1.0.0分支，接着再将feature-1.0.0分支合并到dev分支，合并到dev分支后自动部署到开发环境，在开发环境上进行开发联调，联调完成之后将feature-1.0.0合并到test分支自动部署到测试环境，测试通过之后将feature-1.0.0合并到preOnline分支自动部署到预上线环境，预上线测试完成之后，将preOnline分支合并到production分支自动部署到生产环境，至此，多人进行新版本开发从编写代码到发布上线就完成了。
bug修复
如果生产环境出现bug，则从production分支切出hotfix分支，修改完bug之后，将hotfix分支合并到dev分支进行开发调试，调试完成之后将hotfix分支合并到test分支进行测试，测试完成之后将hotfix分支合并到preOnline分支进行预上线测试，预上线测试通过之后将preOnline分支合并到production分支发布到生产环境。
答疑
- 为什么使用
feature以及hotfix分支合并到test、preOnline分支，而不是将dev合并到test，然后将test合并到preOnline？
因为dev分支用于开发联调，可能包含了其它可能版本或者没有开发好的代码，如果使用dev分支合并到test和preOnline就会把其它版本或者没有开发好的代码更新到测试环境或者预上线环境，而使用feature或者hotfix分支单独合并到test、preOnline，则可以单独更新开发好的版本或者模块，就算多个同事开发同一个版本，某个同事开发的模块没有完成，要延后发版，也可以先发其他同事开发好的模块。 - 如果多个同事共同开发一个版本，每个人负责不同的模块，但每个模块有共用的代码怎么办？
大家沟通之后，某个同事可以将共用的代码在自己的分支写好，然后再合并到共用分支，然后其他同事再将共用分支合并到自己的分支进行复用，例如上面新功能开发场景的A同事将公用代码在自己的feature-1.0.0-A分支上写好之后，合并到feature-1.0.0分支，B同事将feature-1.0.0分支合并到自己的feature-1.0.0-B分支后就可以复用公用代码了。 - 为什么在开发新功能的时候已经有了
feature分支了，每个人还有基于这个feature分支创建一个属于自己的分支？
因为每个人负责的模块不一样，而这两个模块的耦合性可能没那么高，可以将某个模块单独发布，这样的话可以对模块进行单独发布，而不必等两个模块开发好了再发布。
补充说明
- 这套git代码分支管理方式是基于分支通过Jenkins等工具进行自动部署代码的，
dev对应开发环境、test对应测试环境、preOnline对应预上线环境、production对应生产环境。 - 这是根据目前公司的情况所摸索出来的git分支管理与协作方式，可能还有很多需要优化的地方，个人见识有限，欢迎批评指正，提出宝贵的优化建议。