某公司只有一个程序员，一开始并没有版本管理的概念。项目开发只有一个人在参与，所以也没用版本管理工具。

      后来，老板又招了两个程序员，老板说：“研发管理要规范！”，经过一番调研，选用了 Git，三个人开始使用 Git 进行开发上的协作。

      一开始，三个人都是通过一个仓库，在 master 分支上进行协作。每天上班第一件事就是先把最新的代码从服务器上拉到本地的 master 分支，下班前再把代码给推到服务器上的 master 分支，项目就这样展开了协作。

             3人通过本地仓库 master 分支向远程仓库 master 分支提交代码

      协作了几天，团队发现提交代码 master 时候，经常产生代码冲突，要么张三和李四的代码冲突，要么李四跟赵六的代码冲突。这时总要有人把代码拉下来解决冲突。才能保证后续开发工作顺利进行。同时，由于缺少代码审查。部分质量较差的代码和无关内容也时不时被提交上去。

       为了解决单一分支频繁更新容易发生冲突的问题，三人开始研究使用分支的方式进行协作。通过在本地 master 检出新分支，修改后将新分支推送到远程仓库，再通过 拉取合并请求（Pull Request）在远程仓库上合并分支到 master 分支。最后再把代码从远程 master 拉取到本地 master 进行更新。在这个基础上，团队也开始展开相互的 代码审查（Code Review）工作。

本地 master 分支检出新分支开发推送到远端仓库后，通过 Pull Request 合并到 master，然后拉回本地 master。

      经过一番折腾，几个人的协作总算能比较稳定地进行。在后续数周内，团队开发工作顺利展开，项目也得以落地，进入快速迭代阶段。为了解决迭代的版本问题，团队使用分支对每次版本发布检出一个分支进行保留。

通过远程仓库 master 分支在版本发布时，检出一个以版本号命名的分支，作为特定版本管理。

      两个月后，公司迎来了业务的快速增长。技术团队从原来三个人快速增长到十来个人。原来的成员开始带着新人做业务，随着团队的增长，原有的协作方式再次遇到各种各样的问题。经过短短一周的磨合，三人无比疲惫地坐到一起，对过去一周遇到的问题进行了复盘：

      经过讨论三个人都意识到了问题所在，但无奈三人对于多人协作开发经验不多，讨论无果后，决定各自调研，再对比讨论。两天后，三个人带着方案展开了探讨。 

单个仓库还是多个仓库？

       在仓库管理的方案上，张三主张使用 单仓库多分支 的方式进行管理，李四则主张使用 多仓库多分支 的方式进行管理。

       经过讨论，为了降低反复增加加仓库协作者名单的协作成本，三人统一意见继续保留使用 单仓库多分支 的方式。

       在分支策略上，张三提出了使用 分支模式 作为分支管理规范化的解决方案，从 分支类型、用途 等角度规范开发的协作方式。

        经过一番讨论，三人达成了一致的意见，并针对上面的 分支模型 提出了些许细节的调整。

       针对单个仓库协作可能存在分支数量增长的问题，张三提出通过 Git tag 来取代 release/* 版本分支的作用。

      除了在远程仓库上的管理方案，张三还建议提倡团队成员通过 [git-flow] 一系列的脚本扩展，规范本地的分支管理和开发流程。现网络上最流行的 git-flow 方案应该是 AVH 版 git-flow：https://nvie.com/posts/a-successful-git-branching-model/ 。通过安装后，开发成员可以在本地通过对项目的各类功能分支进行定义。

 Git-flow 通过交互方式定义各类功能分支  

通过一系列命令简化各种分支模型的管理操作，小范围功能可以通过本地合并到本地分支，或直接推送到远程再通过 Pull Request 合并操作。

      经过一番调研和讨论，三人最终决定了团队在代码协作上使用 单仓库多分支 的方式，采用 分支模型 进行管理。

      接下来的问题就比较简单了，在码云 gitee.com 上新建仓库，选择相应的分支模型即可。Git 的分支相比 SVN 来说是非常轻量级的，善用分支有利于更清晰的进行开发过程的管理。

码云企业版

https://gitee.com/enterprises