git 提交代码需要规范嘛?

Git提交信息通常遵循一定的规范,如feat表示新增功能,fix代表修复bug,docs涉及文档修改,style是格式调整,refactor是代码重构,perf优化性能,test更新测试用例,chore改变构建过程,revert回滚,merge进行代码合并。即使团队未强制要求,了解并使用这些规范能提高代码管理和协作效率。
摘要由CSDN通过智能技术生成

我总是习惯提交到代码总是直接写 修改了xxx bug 添加了 xxx 功能;
突然有一天发现有人 提交代码的时候 前面有几个 英文字母,不知道啥意思。百度查查看
原来 git 代码管理也有规范:

  • feat: 类型 为 feat 的提交表示在代码库中新增了一个功能(这和语义化版本中的 MINOR 相对应)
  • fix: 类型 为 fix 的提交表示在代码库中修复了一个 bug(这和语义化版本中的 PATCH 相对应)
  • docs: 仅仅修改了文档,比如README、CHANGELOG、CONTRIBUTE等等
  • style: 仅仅修改了空格、格式所以进、变量名等等,不改变代码逻辑
  • refactor: 代码重构、没有加新功能或者修复bug
  • perf: 优化相关,比如提升性能、体验
  • test: 测试用例,包括单元测试、继承测试等
  • chore: 改变构建流程、或者依赖库、工具等
  • revert: 回滚到上一个版本
  • merge: 代码合并同步

虽然公司没人要求,凡是还是用起来吧!!免得有人说俺技术水平不行!

做好代码管理是一个好的习惯,良好的git提交代码规范可以让你的团队更好地管理代码。下面是一些有用的建议: 1.提交消息应该清晰,准确,描述改变发生的原因,不仅是改变的内容。使用短的摘要(50个字符以内)来描述改变,然后跟上更详细的说明(不超过72个字符)。这些说明应该解释为什么这个改变被做出来,解释这个改变如何影响代码。 2.在分支上工作并提交(并合并)后,需要提交信息中给出添加或从分支中移除的功能文件或功能,以及说明下你对其如何工作的看法。 3.在撰写提交信息时,避免使用语气过度积极的字眼,这并没有太大的意义。也不要让写作变得如此无聊,以至于没有人想读或理解什么你所说的。 4.提交流程应该清楚明了。需要保持一致和合理性。在一般情况下,对应的一个功能内容的所有变化将组成一个完整的提交。 5.提交信息的编写时间和更新时间应该与提交代码的时候相同。如果需要,说明何时开始编写提交信息,何时被更新等信息。 6.最后,不要忘记提交所有相关文件。如何选择是“提交所有”或是只定部分代码自动提交,要看使用的 git 服务软件、项目的复杂度等多种因素; 有时候你可能需要提交来自整个项目的所有更改,有时候则只需提交单个文件或更改的一小部分。根据你的工作流程,采取最佳做法即可。 以上是一些关于git提交代码规范的有用建议,如果能在团队内建立好的规范,将会更加简化和加速开发流程。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

公诚士

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值