团队开发代码版本git分支工作流程规划（个人总结性推荐）

一、问题背景

      在日常团队开发过程中，对代码的版本管理显示日常重要，最终顺利发布上线是工作的结果，对于源代码分支管理模式贯穿了开发、集成和发布的整个工作过程，是开发人员每天不能不面对的最重要的一个亲密工具伙伴，但如何根据我们自己团队和业务的特点选择适合的git分支模式，这是每个开发团队面对的首要问题，分支的目的是为了隔离，但多一个分支就多一个维护的成本，从开发和发布的角度有以下组合：

• 主干开发，主干发布：
• 分支开发，主干发布；
• 主干开发，分支发布；
• 分支开发，分支发布；

二、术语

　　

三、分支方案介绍

  主要常见的有：单主干TBD，gitHub Flow, GitLabFlow, Git-Flow.

四、单主干TBD模型（最符合敏捷开发的思想，我个人推荐这种） ：

     需要团队成员有同理心并且开放，最好不要有个人主义很强的人，这样才能贯彻主干开发流程 。

    （1） 只有一个Master分支，团队所有成员基于这个分支开发，不再使用任何分支，没有分支合并概念。

    （2）新功能拆分成很小的块来实现，完成后及时推送到主干上，提高了部署的频率。

      (3)  代码质量与知识共享：不需要合并的审核代码，只需要“四眼原则”，即两个开发人员查看并批准代码进行入主分支，可以结队原则。

五、github工作流程 ( 适合开源产品，这个审核合并代码工作量很大）：

      （1）master主干保持可以部署的状态（它就是产品正式发布的版本），进行新开发作业时，从master创建新的分支进行开发，例如新分支命名为feature-XX。

      （2） 本地仓 库的新分支上进行提交，同时github端仓库创建同名的分支，定期push。

      （3）需要合并时，提出pull request请求，

      （4）经讨论和评估你的代码同意后，才能合并

      （5）与master分支合并后，立刻部署，原来拉出来的分支可以被删除了。

 

   六、gitlab-flow开发流程 （这个用的人很多）：

 

      （1）吸收了git-flow和github flow的优点，最大原则就是“上游原则”，只存在一个master，只有上游分支采纳了代码变化，才能应用到其它分支上。

        (2)通常分为开发分支Master, 预发布环境pre-production， 生产环境分支production.

        (3) 通常Master设置了保护，不是每个人可以修改这个分支以及拥有审批pull request的权力。

 

七、git-flow(太过复杂，不推荐）:

 

  

（1）有一个主干分支master用来发布和独立的开发分支develop用来开发，其它的功能分支均从develop来创建。

  （2）老要在开发中切换到develop分支是烦人的。