首先：Git大法好～

独立开发、一两人开发、十人协同开发、百人协同开发，Git大法虽好，但得用的好。

独立开发与人少的时候协同开发，问题不大。人多了就容易出事。
一般开发会约定如下分支:

• master分支：线上分支，不允许随意提交修改，仅允许develop分支合并，仅管理员操作（一般是开发老大）
• develop分支：开发分支，不允许直接修改，但允许程序员发起pr合并至develop，用于检出新feature-名字分支开发新功，也用于合并至master分支。为什么不直接从master检出新分支开发？下文会指出原因
• release分支：测试代码分支，不允许直接修改，但允许程序员发起pr合并至release，用于测试环境使用
• feature-名字分支：程序员开发使用的功能分支，从develo上检出的开发分支

那么，正常开发流程：
譬如我要开发一个登录功能

1.首先，从develop上检出新分支`feature-login`分支至本地，开发
2.完成开发后，push至远程`feature-login`
3.此时我们需要测试新增的登录功能，那么，我们应该发起一个marge request（pr）至release分支（上文所说的测试分支），开发老大（管理员）同意pr，即成功合并至release分支
4.然后走测试流程
5.测试通过后，准备上线，那么，需要从`feature-login`分支发起pr至develop分支，管理员审核后，由管理员操作develop分支，合并至master

为什么不从feature-login分支直接pr至master分支？

原因：

• 1.master分支为线上生产环境代码，不应该随意合并提交，合并前应审核代码；
• 2.多人协同，极易出现代码冲突，故应约定所有人先合并代码至develop分支，解决冲突后再由develop合并至master。所有人从develop分支检出feature分支开发，保证了代码的一致性，这也是为什么不直接从master检出分支的原因。

注意事项：

• release分支对应测试环境，绝不要将release分支合并至develop或master分支上

  • release分支为测试分支，应于master、develop分离（测试/线上分离）
  • release分支上可以放任意测试代码，代码混乱，可能今天a程序员pr至release测试功能，下午b程序员也pr了新功能测试，但都不是今天上线的且需要测试的功能，然后c程序员直接将release分支合并至master分支，那么将会出现不可预估的bug，后果极其严重
• feature分支发布之前，可以先从develop拉去代码至本地的feature分支，以解决冲突，解决后push feature分支至远程，然后再请求合并至develop，管理员合并时将无需面临代码冲突问题。
• 代码合并至develop分支后，应删除远程端的feature分支。因已合并至develop，后续改动依旧需要从develop分支上检出代码（因为其他人可能在此期间合并了新的功能至develop分支，此操作可保障代码一致性，极为关键），原feature分支无任何存在的必要。
• 严格执行以上流程，Git将是多人协同开发利器

其他流程大同小异，Git解决的是行业内多人协同开发与版本管理的痛点。身为程序员，需要拒绝粘贴复制、抄袭，拒绝千篇一律，各位可以灵活运用，因地制宜

欢迎指出问题