前言
自从大学毕业后来到公司实习，发现公司使用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（包管理）的区别
