所有分类
  • 所有分类
  • 未分类

git使用流程与规范

简介

本文git提交流程与规范是宝贵靠谱的经验,它能解决如下问题:

  1. 分支差距过大,导致合代码无数的冲突
  2. 合完代码后发现代码丢失
  3. 分支不清晰,无法追溯问题
  4. 合代码耗时很长,占用大量时间。

git的基本使用规范

  1. git用户名要指定为名字拼音的第一个(或前两个)字母。比如:李四(ls),张三(zhs)
    1. 不要搞稀奇古怪的英文,因为这样追溯代码时不好找对应的人。
  2. 要选择rebase,禁用merge
    1. merge会丢代码(我周围的人踩过很多这个坑)。
    2. git提交清晰
    3. rebase是人类的正常思维:远程的代码优先。
      1. rebase是本地git先跟上远程git的最新提交点,再去提交代码
      2. merge是让远程git以本地git为基点(这样会导致本来领先的远程git又退回了)

IDEA选择rebase的方法

拉代码

推代码

项目从0-1时

说明

将git分支分为主分支和临时分支。

  • 主分支:develop(开发)、test(测试)
  • 临时分支:需求点和bug修改
  • 开发阶段:
    • develop(只有这一个分支)
  • 测试阶段:
    • 开发完毕后从develop新拉分支,命名为test,用于测试(develop分支废弃)
    • 若有新需求:
      • 从test新拉临时分支写代码,分支命名为:test_需求名
      • 代码写完后,压点,cherry pick到test。(合到test的只有一个提交点,若test已更新,要选择rebase,不要选择merge)
    • 若有bug:
      • 小bug:直接在test改
      • 大bug:方法与上边“若有新需求”一致。
  • 上线阶段:
    • 测试完毕后从test新拉分支,命名为prod,用于测试

上线完毕后,项目0-1阶段结束,开启1-100阶段。删除develop分支,新代码全部从prod新拉分支写。

项目从1-100时

说明

将git分支分为主分支和临时分支。

  • 主分支:test(测试)、pre(预发布)、prod(生产)
  • 临时分支:需求点和bug修改

开发与提交流程

  1. 每个修改点(需求或bug)都要从prod新拉分支(即:临时分支)
  2. 合代码(代码都写在临时分支,合代码时从临时分支cherry pick到目的分支(主分支))
    1. 往test分支合代码时,需要先把自己的临时分支压缩为一个点,再cherry pick到test。
    2. 往pre分支合代码时,从临时分支cherry pick到pre分支,不要从test分支cherry pick。(因为test肯定有没测试的,不能上pre)
    3. 往prod分支合代码时,组员告诉组长自己的提交点,由组长从临时分支cherry pick到prod分支(因为pre肯定有没测试的,不能上正式)
  3. 远程有更新时,要rebase(以远程为基准),不要用merge(以本地为基准)
  4. 修改点上线(临时分支cherry pick到master)后,删除临时分支(防止分支过多)
  5. 定期(两三周)对test进行清理,删除test并重新从prod拉分支,作为test分支。(防止test与prod差距较远,导致临时分支往test分支合代码时冲突很多)
  6. 定期(两三周)对pre进行清理,删除pre并重新从prod拉分支,作为pre分支。(防止pre与prod差距较远,导致临时分支往pre分支合代码时冲突很多)

优点

以上步骤是我之前所在某个公司的提交流程,按这个流程来做,可以做到:合代码基本不出问题、合代码速度快(一般不会超过3分钟)。

以上步骤每一步都是有原因的:

  • 从prod拉新分支:可保证新分支代码是基于生产的,可以保证新分支是纯粹的自己的修改点
  • 合代码时都是从临时分支cherry pick到目的分支:可保证不会将其他人代码合到目的分支
  • 定期删除test、pre并从prod拉分支:从临时分支合到主分支时基本不会有冲突;而且可以删除test里无用的代码

感言

一个正常的功能点,如果合代码超过10分钟,那么,项目的git管理大概率有问题。如果超过30分钟,项目的git管理问题有点儿大。如果超过一个小时,那么这个项目肯定是经常丢代码,经常出奇怪的线上问题,客户投诉率肯定很高(亲眼见过)。 ​

0

评论0

请先

B站:远舟说编程,分享靠谱技术事儿
显示验证码
没有账号?注册  忘记密码?

社交账号快速登录