从0到1聊聊Git提交

72 阅读5分钟

前言

自从大学毕业后来到公司实习,发现公司使用Git来管理代码提交。公司大牛也整理了很多帮助新人快速上手的文档,其中一个就是有关Git的(知识库)。但公司留不住人才,两位大牛在半年多时间内都溜溜球了。虽然大牛溜溜球了,但我们还是会有很多联系,这篇文章就是受到他们的影响而归纳写下的在开源项目中Git提交规范建议。

一次提交流程体验

先聊聊一般在开发中提交代码的流程吧:

  1. 找到对应项目链接,git clone到本地;
  2. git checkout -b 自己的分支
  3. 只修改部分代码,完成自己的任务(暂不考虑安装依赖,把项目跑起来);
  4. git add .
  5. git commit -m "可能会随意写一些提交备注,每个人写的格式还都不同"
  6. git push(如果推的是新创建的分支,Git会有对应提示)。

这个是非常理想化的提交流程体验。但在真实开发中,可能开发到一半,突然要去修bug了,修完bug又跑回来开发,开发开发着可能又去忙其他东西了。可以想象,这次提交代码会产生很多提交备注(commit),而且每次提交的备注可能过一阶段再看,不知所云。自己如果都看不懂,那么CR的时候会非常痛苦(应该没人会想看赖赖长的东西吧)。

上面这段话其实主要想说明两个问题:

  1. 每次提交的备注可能过一阶段再看,不知所云(commit不规范);
  2. 提交代码会产生很多提交备注(没有rebase,化繁为简)。

Commit书写规范

这里只是建议大家这么去书写,并不是最佳实践(这里指git commit -m " "双引号内的书写)。

  • feat: 新功能简单说明
  • fix: 解决bug问题简单说明
  • style: 修改样式的简单说明
  • refactor: 重构的简单说明
  • merge: 合并代码

这里贴一个阿里的提交规范zhuanlan.zhihu.com/p/182553920(更加详细,但一般小公司用到上面几个就够了)。

适当Rebase

rebase其实是我新接触的知识,也是深受大牛的影响。之前我的合并请求打开后也会偶尔存在提交记录有多条的情况,接下来我总结下什么叫适当rebase。

  1. 当我们在完成一个任务,但由于中途去做其他事情,导致写了很多个提交,这个时候我们需要把多个提交合并成一个(这样的提交看上去会更加简洁明了)。
  2. 但也不是强制一个PR都要rebase成一次提交。你也可以多次提交,但要注意每次提交保证只做一件事情。如果遇到第一条所说的,就需要合并。

下面举个例子来体会下:

  • git commit -m "feat: finish A1"
  • git commit -m "feat: finish A2"
  • git commit -m "feat: finish A3"
  • git commit -m "feat: finish B"
  • git commit -m "feat: finish C"
    (上面的命令都需要先add .再commit)执行完后,我们需要把A1,A2,A3,rebase合并成A(一个任务原则),而B,C放着不用合并。

Rebase使用

刚刚介绍了rebase使用的场景,接下来聊聊怎么用。

  1. 使用git log找到第一次提交的id;
  2. git rebase -i 再加上刚找到的id
  3. 结束之后会进入一个交互界面(:wq是退出)
    下面的表格详细介绍交互界面中使用到的命令
命令目的
p, pick不对该commit 做任何处理
r, reword保留该 commit,但是修改提交信息
e, edit保留该 commit,但是 rebase 时会暂停,允许你修改这个commit
s,squash保留该 commit,但是会将当前 commit 与上一个 commit 合并
f, fxup与 squash 相同,但不会保存当前 commit 的提交信息
x,exec执行其他 shell 命令
d, drop删除该 commit

我用的比较多的还是p,s,f。但我还是觉得merge简单一点(虽然PR的时候会多一条merge的记录)。rebase的时候会遇到很多问题,并不是一帆风顺,但如果你团队的规范是使用rebase的话,不妨试试,毕竟技多不压身嘛。

GitHub码云等代码仓库使用

我们想pull拉取,和push推送更加方便,我们就要考虑把项目存储起来,而不是用U盘保存下来吧哈哈哈。市面上也有很多存放代码的仓库,这里会聊聊GitHub以及码云这两款比较热门的代码仓库使用的一些细节。

其实这两款代码仓库的功能大差不差。

  1. 我们可以在GitHub或者码云(issues中创建工单,指明是新功能还是bug,工单命名规范和提交规范是相同的。他人也可以给你的项目提出宝贵的建议,也是通过issues创建工单和你互动);
  2. 创建完一个工单之后,会有一个#工单编号,这里我称它为#issueId
  3. 完成一次提交流程体验(上面已经介绍过啦);
  4. 提交PR的时候,自动关联并关闭刚刚创建的issue工单,有以下两种方法:
    • close #issueId(close可以用fix、fixes、fixed、closes、closed、resolve、resolves、resolved任何一个代替);
    • GitHub(在提交PR的时候,点击右侧的Development关联一个已存在的问题),码云(在提交PR的时候,点击右侧的关联 Issue)。

自我批评

笔者对于git rebase还需要进一步学习,有关rebase和merge的差异也未在此文中阐述,感兴趣的小伙伴可以搜索下,如果小伙伴们看完之后还存有疑惑的地方,请记得留言互动噢,共勉~

下期预言

  1. npm,pnpm,yarn(包管理)的区别