共计 1398 个字符，预计需要花费 4 分钟才能阅读完成。
首先：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 解决的是行业内多人协同开发与版本管理的痛点。身为程序员，需要拒绝粘贴复制、抄袭，拒绝千篇一律，各位可以灵活运用，因地制宜
欢迎指出问题
正文完