首先: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 解决的是行业内多人协同开发与版本管理的痛点。身为程序员,需要拒绝粘贴复制、抄袭,拒绝千篇一律,各位可以灵活运用,因地制宜
欢迎指出问题