为什么我选择使用约定式提交规范: feat, doc, chore, fix
使用约定式提交规范可以让代码的提交信息更明确,方便团队成员之间的沟通。
比如:
feat 表示添加了新的功能
doc 表示更新了文档
chore 表示做了一些日常的事务
fix 表示解决了某个 bug 。
我个人认为,使用约定式提交规范可以提高代码的可读性和维护性,你们常用的提交规范有哪些?
分享两个实用的:- 各大编辑器插件市场搜索“ai commit 或者 git commit”- 开发人员必备的备忘单: cheatsheets.zip/conventional-commits
补充Markdown格式的备忘单链接: cheatsheets.zip/conventional-commits
我用 idea 里面的一个插件 Git Commit Template 。除了你列的这几个还有很多别的
因为用 close/fix/resolve 可以在相关 issue 里直接显示
merge:这个不用解释了吧;refactor: 代码重构,未改变逻辑,只做代码优化;style: 只修改了样式,这个前端会用到;
我也喜欢用这个,有时候还附带个括号表明修改范围
style 不是指样式吧 s2.loli.net/2024/03/13/zcOMrPDlmqwu6X9.png
也可以通过 Github Actions 生成友好的 Changelog
“Code changes that do not impact the functionality (e.g., formatting, white-space, etc)” -- 摘自这份约定式提交备忘单: cheatsheets.zip/conventional-commits
你说的对,代码格式化可以使用 style ,css 的修改一般是有语义的,使用 style 可能不太合适。
虽然用,但是不够理解,有时候还是会犹豫到底用哪个 type ,要是有人可以做个类似 distrochooser.de/zh-hans 的工具就好了
这不是很常见的规范之一吗。
这不是在企业里面必须遵守的规定吗?而且也不止这几个啊。
这个不是可以安装下插件,git cz 直接选相关的提交类型就可以了,还会让你写简略和详细说明,是否有 breaking change , 然后配合相关的版本和 change-log 的工具,发布版本时候自动更新 changelog ,这套流程已经算很成熟了
jb 系列的 ide 里有什么推荐的插件吗
搜了下 jetbrains 里面好多类似的插件,有哪款比较好用的吗
前端的话 建议用这个 github.com/legend80s/git-commit-msg-linter 省的自己配 husky 了 用的是 ng 的那套约定 我觉得足够一般开发了
用 Emoji 好了
idea 的 Git Commit Message Helper 插件也可以看看。
比较流行的是 commitlint 吧,这个才 300 多 star 有点小众了
npx czg ai 命令行里面可以使用 gpt
npm 装个全局 git-cz 就能摆脱编辑器,直接命令行写了
git-cz 和 czg ai 可以的
用的 utools 的插件
commit logs 有意义即可要说方便沟通我更喜欢这种: github.com/ahmadawais/Emoji-Log
有一个小疑问,根据 commit msg 生成 changelog 的话,如果中间提交 要怎么写,比如一个新功能 feat: xxx ,但是我写了 bug ,然后修复,这个时候是 feat: xxx 还是用 fix: xxx?
gitmoji.dev/
10 年 一万多个 commits 全是这种
公司的主要项目之一,最高的时候月流水一千万
这个写的很详细的 www.conventionalcommits.org/zh-hans/v1.0.0/
我感觉 chore 的意义很模糊,所有的改动都可以说是 feat 或 fix 什么样的改动算是 chore 呢
相同的提交规范,只不过我会在后面加点干了些啥活
足够用了 而且你看 readme 就是平替 commitlint 的 起码你的工程里不需要 commitlint+husky 只要这一个就够了 对我来说比配置 commitlint 来的简单 install 之后基本就可以用了
#26 这可能才是大多数项目
比如改个版本号. 就可以用 chore 吧
我们的格式是 [jira 号] chore/feature/fix: commit message. 在 Gitlab 上 jira 号可以配置成 link. 方便到对应的 jira 上.
逗笑我了
搞复杂了,我就一个字母 ’m‘ ,表示 modify
兄弟,这里不是小红书:doge:
我们是 A(add)/M(modify)/B(bug)/O(optimization)
现实执行过程中,很常见,就是有些人习惯性的在 commit debug ,所以根本无法描述当前提交的内容,只能 update
style 指的是代码格式调整这种不影响功能的,而不是页面样式。比如前端说,我就改了个样式,那其实是有可能引入 bug 的
merge 本来就有足够的信息了,我觉得不用画蛇添足
我也很疑惑,有时候写了一些代码,但是又不足以称得上是一个完整的功能,feat 不合适,又不知道该标记什么
尽量保证每次提交都是单一的
就是先用 高级语言,例如 ruby python 把功能做出来,然后让大语言模型翻译成 低级语言,例如 go c/ 一般来说,翻译完了还有一点小问题,一般是一些语法细节,所以你…
VSCode 中 Python 扩展的测试发现功能,出现点小问题就全部不能发现,导致全部不能用。 不同文件夹中的测试文件重名,直接崩溃 有测试文件是 unittest 直接崩…
iPhone 手机,最近用了拼多多,在删除软件之后,重新下载,发现首页全是之前买或者搜过的东西。有些商品下面还有‘你收藏的商品’,我确实收藏了这些,但是我没有登录账号,它是怎么…