一篇文章说明白Git使用规范,收藏慢慢看

大家好,我是厚厚。

好久不见,转眼已经来到了2022年,疫情还没有消散……

不过我们的生活早已经恢复正常

新的一年,Flag还是要立的,万一都完成了呢?

一起加油呀!

最近在项目中发现,有些小伙伴在使用Git的时候,不是那么的规范,抽空整理了一波,希望可以帮到你。

文章主要包含:分支规范、提交合并规范、分支使用流程等。

划重点:提交合并你还在用merge吗?rebase了解一下

一、分支规范

在开发过程中,一般会存在以下几种分支:

main分支(master)

master为主分支,也是用于部署生产环境的分支,一般由 dev 以及 fixbug分支合并,任何时间都不能直接修改代码。

dev分支

develop 为开发分支,始终保持最新完成以及bug修复后的代码。一般开发新功能时,feature 分支都是基于 dev 分支下创建的。

feature-[功能名称/版本信息]

feature为需求分支,以 dev 分支为基础创建 feature 分支。每个开发人员基于feature分支,创建自己的开发分支。

fixbug-[bug编号]

线上出现紧急问题时,需要及时修复,以 master 分支为基线,创建 fixbug分支,修复完成后,需要合并到 master 分支和 dev 分支。

二、Commit 提交规范

2.1 提交的日志格式

每次git提交日志格式为: 类型:描述

  • 类型

    用于说明 commit 的类别,只允许使用下面7个标识。

    • feat:新功能
    • fix:修补bug
    • docs:修改文档
    • style: 格式化代码结构,没有逻辑上的代码修改
    • refactor:重构,即不是新增功能,也不是修改bug的代码变动,比如重命名变量
    • test:增加测试代码,单元测试一类的,没有生产代码的变更
    • chore:构建过程或辅助工具的变动(不会影响代码运行)
  • 描述

​ 是本次commit的描述,说明白本次提交都干了些啥

​ 例如:

git commit -m "feat: 新增用户详情页接口"
git commit -m "fix: 修复用户注册时电话号码校验逻辑问题"
git commit -m "docs: 新增项目Readme 文档"

2.2 提交频率

  1. 提交粒度按照功能点进行提交,切记不要一直不提交,积攒一大堆代码再提交;
  2. 在push之前压缩那些临时的或者无意义的commit;

切记压缩多个commit,只能对自己的提交进行压缩,不要操作别人的提交,不然可能会被同事追着打

  • 命令行方式
# 找到需要合并的commit;例如:想对最近4次提交进行合并,该如何操作呢?
# -i 等价于 --interactive
$ git rebase -i HEAD~4  
# 或者 通过git log 找到最近4次提交的父类提交,也就是第5次提交的commitId进行合并操作
$ git log 
$ git rebase -i 6ecc2741a2337d6b50f2c35ba877aa040eea3531
# 接下来会进入vi 操作,会自动列出需要合并的提交,结构是这样:操作  commitId 提交备注 例如:
# pick f77f9da list branch update two
# pick ff65dd9 feat: list branch update three and four
# 解释一下常用的操作:pick: 保留这次提交;squash:保留这个commit,但是会将这个commit融入到上一个commit;fixup:同squash,但是会丢弃掉log message
# 修改完之后,保存(:wq)
# 保存之后,紧接着进入修改commit 的vi操作。
# 修改完commit之后,保存(:wq),完工
# 在使用git log 就可以看到之前4个提交日志,只能看到两个了。

pick:保留该commit(缩写:p)

reword:保留该commit,修改该commit的注释(缩写:r)

edit:保留该commit,rebase时会暂停,允许你修改这个commit(缩写:e)

squash:会将当前commit与上一个commit合并(缩写:s)

fixup:与squash相同,但不会保存当前commit的提交注释信息(缩写:f)

exec:执行其他shell命令(缩写:x)

drop:丢弃该次提交(缩写:d)

  • IntelliJ IDEA开发工具自带方式

一篇文章说明白Git使用规范,收藏慢慢看

2.3 更新、合并规范

原则:

① 下游分支更新上游分支代码用rebase

② 上游分支合并下游分支代码用merge

③ 更新本分支代码用--rebase (如果本分支有多人共同使用开发的时候);

这样可以消除自动产生的无用merge记录,有利于后续查看开发记录。

下游分支在更新上游分支代码的时候,如果使用merge,会产生一条无用的合并记录,比较影响查看历史,使用rebase则不会。

下面分场景说明应该如何操作,目前有个xx需求,由a、b两名同学进行开发分支说明(建立个人开发分支是为了方便做代码review):

  • master:主分支
  • dev:测试分支
  • feature-xx:订单详情需求分支
  • feature-xx-a:订单详情a开发分支
  • feature-xx-b:订单详情b开发分支
场景一:feature-xx分支代码有个更新,本地feature-xx更新代码。

c、d两位同学共同在feature-xx分支上开发,其中一个push了代码,另外一个更新。

  • 命令行方式
# 目前代码处于feature-xx分支,且都已经本地提交(没提交的可以使用暂存功能)
同步远程库代码变动
$ git fetch origin
# 使用rebase进行代码更新代码
$ git pull origin feature-xx --rebase 
  • IntelliJ IDEA开发工具自带方式

一篇文章说明白Git使用规范,收藏慢慢看

场景二:feature-xx分支代码有了新代码的更新,a要合并代码。

梳理下思路:

feature-xx-a更新远程分支代码(不更新也行,因为只有a在使用);

② 合并origin/feature-xx分支代码,有冲突解决冲突,没有冲突将代码push到服务器;

③ 发起合并。

  • 命令行方式
# 假设所有代码已经都提交,无需进行提交或者暂存代码的操作;
$ git checkout feature-xx-a
# 同步远程库代码变动
$ git fetch origin
# 使用rebase进行代码合并
$ git rebase origin/feature-xx
# 如果此时有冲突,解决冲突,并将解决完冲突的代码提交,在执行rebase 即可
$ git rebase --continue
# 合并完之后,push代码,push完之后,a的代码已经到远程feature-xx-a分支了
$ git push 
# 此时,如果需要进行代码审核,发起一个合并请求即可;
# 如果不需要进行代码审核,后续操作就是合并到feature-xx分支
# 切换分支,并更新代码
$ git checkout feature-xx
$ git pull --rebase 
# 合并张三分支代码,并推送远程
$ git merge feature-xx-a
$ git push
  • IntelliJ IDEA开发工具自带方式

步骤①参考场景一,这里只展示一下步骤②应该如何操作。

一篇文章说明白Git使用规范,收藏慢慢看

2.4 分支使用及发版流程

负责人排定发版计划,并执行发版控制,注意前/后端的协同。测试版本可根据开发计划,拆解生产版本任务,组织阶段测试。

提测冒烟通过后拉分支继续开发、版本内有bug修复后合到已提交版本重新发版。具体流程如下:

一篇文章说明白Git使用规范,收藏慢慢看

上一篇:ROS-control-gazebo-moveit-grasp(一、场景搭建)


下一篇:git中关于工作区,暂存区,本地仓库,远程仓库的一些问题