Git - 多人协同开发利器,团队协作流程规范与注意事项

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

欢迎指出问题

    原文作者:liaoxinyu
    原文地址: https://segmentfault.com/a/1190000020522132
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注