前言
自从大学毕业后来到公司实习,发现公司使用Git来管理代码提交。公司大牛也整理了很多帮助新人快速上手的文档,其中一个就是有关Git的(知识库)。但公司留不住人才,两位大牛在半年多时间内都溜溜球了。虽然大牛溜溜球了,但我们还是会有很多联系,这篇文章就是受到他们的影响而归纳写下的在开源项目中Git提交规范建议。
一次提交流程体验
先聊聊一般在开发中提交代码的流程吧:
- 找到对应项目链接,
git clone
到本地;git checkout -b 自己的分支
;- 只修改部分代码,完成自己的任务(暂不考虑安装依赖,把项目跑起来);
git add .
;git commit -m "可能会随意写一些提交备注,每个人写的格式还都不同"
;git push
(如果推的是新创建的分支,Git会有对应提示)。
这个是非常理想化的提交流程体验。但在真实开发中,可能开发到一半,突然要去修bug了,修完bug又跑回来开发,开发开发着可能又去忙其他东西了。可以想象,这次提交代码会产生很多提交备注(commit),而且每次提交的备注可能过一阶段再看,不知所云。自己如果都看不懂,那么CR的时候会非常痛苦(应该没人会想看赖赖长的东西吧)。
上面这段话其实主要想说明两个问题:
- 每次提交的备注可能过一阶段再看,不知所云(
commit不规范
);- 提交代码会产生很多提交备注(
没有rebase,化繁为简
)。
Commit书写规范
这里只是建议大家这么去书写,并不是最佳实践(这里指git commit -m " "
双引号内的书写
)。
- feat: 新功能简单说明
- fix: 解决bug问题简单说明
- style: 修改样式的简单说明
- refactor: 重构的简单说明
- merge: 合并代码
这里贴一个阿里的提交规范zhuanlan.zhihu.com/p/182553920(更加详细,但一般小公司用到上面几个就够了)。
适当Rebase
rebase其实是我新接触的知识,也是深受大牛的影响。之前我的合并请求打开后也会偶尔存在提交记录有多条的情况,接下来我总结下什么叫适当rebase。
- 当我们在完成
一个任务
,但由于中途去做其他事情,导致写了很多个提交,这个时候我们需要把多个提交合并成一个
(这样的提交看上去会更加简洁明了)。- 但也不是强制一个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使用的场景,接下来聊聊怎么用。
- 使用
git log
找到第一次提交的id;- 再
git rebase -i 再加上刚找到的id
;- 结束之后会进入一个交互界面(
: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以及码云这两款比较热门的代码仓库使用的一些细节。
其实这两款代码仓库的功能大差不差。
- 我们可以在GitHub或者码云(
issues中创建工单
,指明是新功能还是bug,工单命名规范和提交规范是相同的
。他人也可以给你的项目提出宝贵的建议,也是通过issues创建工单和你互动);- 创建完一个工单之后,会有一个
#工单编号
,这里我称它为#issueId
;- 完成一次提交流程体验(上面已经介绍过啦);
- 提交PR的时候,
自动关联并关闭
刚刚创建的issue工单,有以下两种方法:
close #issueId
(close可以用fix、fixes、fixed、closes、closed、resolve、resolves、resolved任何一个代替);- GitHub(在提交PR的时候,点击右侧的
Development
关联一个已存在的问题),码云(在提交PR的时候,点击右侧的关联 Issue
)。
自我批评
笔者对于git rebase还需要进一步学习,有关rebase和merge的差异也未在此文中阐述,感兴趣的小伙伴可以搜索下,如果小伙伴们看完之后还存有疑惑的地方,请记得留言互动噢,共勉~
下期预言
- npm,pnpm,yarn(包管理)的区别