Git 分支协作模式

开始

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

解决频繁的代码提交冲突

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

初步解决代码迭代版本问题

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

团队增长带来的困扰

随着协作人数增多，远程仓库分支数量快速增长，查找起来很麻烦，经常出现分支重名问题。
分支命名混乱，提交新功能的分支和修复Bug的分支经常混淆在一块。
版本迭代的速度太快，产生了一大堆的 Realease 分支，又带来了一堆的管理问题。
还没来得及合并或独立维护的分支，时间久了容易出现管理遗漏和维护混乱。
虽然有 Code Review，但程序的 Bug 数和 Crash 频率明显随团队规模而增长，生产事故发生率和回滚率提高。
还有人把手头未完成开发的分支扔到远程仓库进行托管。

单个仓库还是多个仓库？

用「分支模型」规范分支管理

灵活使用 Git tag 和发行版管理功能

在 git 中，标签（tag）是特定提交（commit) 的一个指针，也就是每个 tag 对应一个特定的 commit。release/* 系列分支在实质上就是合并到 Product (master) 分支上成为一个特殊提交，所以 tag 的存在使得没有必要保留 release/* 分支。
另外，一般形如[码云]这样的 git 代码托管平台，本身自带「发行版（Release）」功能。
通过 git 本身只能记录项目的修改，而版本发布带来的项目构建物（特别是二进制文件）本身在某种意义上就不适合通过 git 进行存储。
通过「发行版（Release）」功能，可以将对应版本的源代码和生成的项目构建物（比如exe/dmg）保存下来，还支持编写对应的 Changelog，便于查找下载。

使用 Git-flow 脚本规范本地分支和开发

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

最后

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