关于基于git分支开发流程的一点看法

很多公司（软件开发）都采用git来进行管理，git的分布式特性及文件比较（比较文件内容）方式让其优势远大于svn；而在日常开发中基本上都是采用分支开发，这个流程的合理性非常重要；

错误使用例子

很多公司有三套环境，相互隔离：test，pre（预发），product（正式）；pre其实就是product的预演，除了功能没正式对外使用，数据库等资源与线上使用是相同的，测试同学通过在pre环境测试即将发布的功能

• 有些公司在使用分支开发的时候的流程是这样的

  一个新功能开发，从master拉出一个分支A
  开发完成，测试通过，合并到master
  测试通过，直接发布master
  

• 来看看这个流程有什么问题

  初看没毛病
  再仔细想想，有一个场景，有两个同学在一个项目上开发2个功能，这个时候，两个同学分别拉去了branchA和branchB，
  同学A开发完了，测试环境也ok了，准备上预发测试，这个时候，把代码合并到master，上了预发，上了预发发现有功能遗漏或者有严重bug短时间内不能修复，而同学B的功能需要上线了，这个时候怎么办，只能回滚操作了，各种git操作，把master代码切回到上次发布的代码
  然后B同学继续预发
  

  • 第一个毛病：合并master太随意，如果你在预发的时候，同学C有任务，在这个时候拉了分支出来，进行开发了，如果代码写了很多了，而master又需要回滚，非常混乱
  • 第二个毛病，上了预发的代码要下掉，很麻烦，都是人的手工操作，一不小心直接操作错误，回滚多了，或回滚少了，都是坑（这还是没有上线的操作呢）

思考

1、为什么预发要发master分支呢，master分支不应该是封版的代码码
2、master这么重要的东西，为什么开发人员能随意合并呢，合并操作的时候还是有操作失误的
3、如果大项目预发要占用几天，而又有紧急bug需要上线怎么办（手段很多，但是都是非常规操作）

解决方案

预发不发布master的代码，但是上预发的时候，发布脚本需要自动合并master的代码到分支（不进行push操作），如果有冲突提示出来，开发人员拉下master的代码，合并到开发分支，解决冲突，提交分支代码，继续预发布
任何的开发人员均没有分支合并到master的权限（即不能push master的代码到代码库）
每次预发重新拉去代码，将master代码合并到分支代码进行打包部署
正式发布的时候，才是将分支代码合并到master，部署master项目到product环境，并推送到代码库，纯机器行为，不人工参与master的代码

解决核心问题

1、预发不发布master代码，而是机器脚本将master合并到分支，但是不进行push操作
2、master代码只允许机器脚本来操作（将分支代码合并到master）