公司开始 Run Git Flow 也已经超过 3 个月了，记录一下，随着团队扩大、需求和用户增加，版本控制流程的演变过程。
这样的流程有助于我们稳定地、持续地进行交付。
# 一条主分支
master
- Team Lead 的个人项目，也没什么用户在使用，
master就是我的游乐场，我想怎么改就怎么改，反正改坏了趁没人发现的时候再改回来就好。
# 两条主分支
masterdevelop
- 业务需求增加，加入初期团队成员。开始分 branch，分别是
develop和master，团队成员直接在develop上做开发，develop和master分别绑上测试和正式环境的 CI/CD，develop用于测试，master用于交付，每次开发周期将develop合并到master一次，作为新版本发布。
# 两条主分支、一条副分支
master（主）develop（主）feature（副）
为确保代码质量，每个人在实现需求的时候都要从
develop开启feature分支，每次合并回develop都要发 Pull Request，由 Team Lead Review 合并。为了让自己的代码容易 Review，如果开发的过程需要重构，另外开一个用于重构的
featurebranch 来重构代码，新的功能则基于这个重构的 Branch 继续做开发，一个功能可以分别发好几个 PR，尽量减少每个 PR 改动文件的数量。需求做不完，团队人员再度增加，为增进团队交流、保持同步，随着项目扩大，每个人在发 PR 的时候都可以 Assign 给相关成员（曾经接触过这里的代码，或将要接触这部分代码的人），团队的中心分散，每个人都可以对彼此的代码发表评论与 Approved。
同步 Coding Style，每隔固定周期，对这个周期发送的 PR 做 Review，将 Coding Style 写成文档，方便未来入职的人能快速地理解项目，并融入团队。
# 两条主分支、两条副分支
master（主）release（副）develop（主）feature（副）
- 以
develop作为测试环境，当多人协作时，不小心把没写好的代码合到develop的时候，就会影响测试人员 QA 做测试，于是我们新增了releasebranch 来代替develop测试的功能，将原来测试环境的 CI/CD 从develop改绑到release上面。这样一来，PR 合并到develop的时候就不会部署，不仅减少不必要的 build time，当releasebranch 出现问题的时候，还可以即时将releaserebase 到develop上面没有问题的 commit，让 QA 的测试不会被影响；测试遇到问题时也可以即时在release上面做修正，只不过最后要记得再合并回主要的develop分支。
# 两条主分支、三条副分支（GitFlow）
master（主）hotfix（副）release（副）develop（主）feature（副）
- 即便走过这个流程，还是会有 Bug 被部署到正式环境的情况发生，这时候就需要从
master开出一个hotfixbranch 做抢修，确认没问题之后，同样要合并回master和develop两个大分支；如果没有将hotfix合并到develop，在下个周期部署的时候，很可能会把修好的 hotfix 盖掉。
你有什么不使用 Git Flow 的理由吗？欢迎在下面留言与我分享。