如果有的话，有些怎样的规范？

大家会在 commit message 里加需求链接或者 bug 链接吗？像 jdk 或者 linuxkernel 那样？

cz

AI 规范，直接点击 "Add AI generated commit message"：img

模版大概是在这样的:[optional scope]: optional body

一般会加个开头吧 fix feat perf 之类的，但是这个好像也不是通行标准，有不少大厂的重要开源项目也不这么搞

gist.github.com/ericavonb/3c79e5035567c8ef3267 www.conventionalcommits.org/en/v1.0.0/＃specification网上有很多，组里遵循不遵循与我无关，我都按照一定的风格写。

约定式提交规范 www.conventionalcommits.org/zh-hans/v1.0.0/根据自己项目改改

开头加 fix feat perf 其实主要是为了方便用工具自动生成 release note

＃2 好用吗

有，用的是 angularjs 的规范。咦，我好像发现 angularjs 本身不怎么样，但是它搞的很多规范很实用。。。。

没人管，我是尽量确保第一行简洁明了的写出改了什么，第二行空白，第三行看情况补充说明，
有规范，毕竟每一个 commit 都是有原因的，所以会加上追踪信息。

ticket-number project name: what changed

conventional commits+husky

有的，一般会加上任务 ID 或者 bug ID

用，和 angular 一样的规范。

update, update xxx, update...

新增/修复(范围):描述

有，要标记一下是 bug 修复还是功能开发bug 修复要加上 bugid

(fix|update|change|feat|remove): (模块-子模块-页面-组建). 功能描述内容巴拉巴拉. 如果有 issue 就再加上井号+id, 其他非同一平台的不管

同 6 楼，conventional commit

自己的项目绝大部分情况用 conventional commits ，别人的项目就 git log 看看过往提交风格，模仿着写，如果过往提交没有统一风格，就按照自己喜好写。这东西跟项目管理情况是息息相关的。比如开发一个本地特色的项目，也大可不必坚持用英文，只要能快速、准确、工整表达核心信息就可以了。再比如写的可能不是程序，而是个文档项目，只是想用 Git 来做版本控制，那么可以自己找或设计一套适合文档的提交风格。

husky 做 git 钩子拦截commitlint 做校验信息git cz 填写内容

commitlint + /config-conventional

直接用哈士奇

有规范，并且 commit message 也会链接 tapd

规范不规范的我不知道，有的同学啊，提交倒是写了介绍，但点开一看，内容完全对不上咱不如每次都写“a bunch of code”，还省事

angular 规范 用 commitlint 约束

Description:TraceNo:

这是什么编辑器？

Visual Studio 2022 的 17.9 版本

vs 越来越牛逼了

imgur.com/a/oT6Ee8O 这两周 VSCode 直接把这个功能集成进 source control 了

是不是必须开通 GitHub Copilot?

我原本以为是 Copilot 引入的，但你这么一说，我禁用插件测试了一下，发现是 "GitLens — Git supercharged v14.5.1"，抱歉前面的信息造成了误解

＃＃ github.com/Nutlope/aicommitsaicommits --type conventional＃＃ github.com/di-sukharev/opencommitoco ＃＃ github.com/zurawiki/gptcommitgit commit -a＃＃ github.com/appleboy/CodeGPTcodegpt commit --preview --template_file your_file_path＃＃ github.com/RomanHotsiy/commitgptnpx commitgpt

我自己的规范：commit 加 jira link ，简单说明，长度不超过 GitHub 标题的长度（其实他的标题可以很长，但是 commit 的时候好像有个固定长度，超了就自动进入 description 了）。

所有人不允许直接 git push 。用自己写的系统做 code review 。review 里面要写明白细节。

不知道 commit message 里面塞表情符号算不算规范的一部分

💥 feat(compiler): add 'comments' option🐛 fix(compiler): fix some bug📝 docs(compiler): add some docs🌷 UI(compiler): better styles🏰 chore(compiler): Made some changes to the scaffolding🌐 locale(compiler): Made a small contribution to internationalization

要写的。方便日后 有 问题时查看 commit log ， 如果是开源项目，便于日后自动生成 release note. 比如： github.com/go-eagle/eagle/releases

没有，只要求交 PR 的时候 squash 成一个 commit ，然后信息需要有一定的描述性。你说 PR 太大，没法放一个 commit ，那要重新考虑这个 PR 的任务范围划分

用 git 官方推荐的，但是我们组 99%的人胡逼写。

要用这个功能，是不是需要填入自己的 GPT APIKeys?还是说不需要额外购买 GPT 了？

有的，还有 git hook 脚本自动检查，不符合规范不给 commit

11.25......11.26........updatefixbugfix

www.jenkins.io/changelog/ 参考 jenkins

带上任务或是 bug 的 ticket id ，这样就好管理一些

Conventional Commits www.conventionalcommits.org/zh-hans/v1.0.0/

看实际情况，假如你的 commit 除了你没人看，你怎么写都行，也没人会叼你

gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53

用法的 conventional commitlint 。 github.com/conventional-changelog/commitlint

plugins.jetbrains.com/plugin/9861-git-commit-templatecommit message 与 semver 挂钩

自己的 git 也会写一些关键词，起码以后看起来知道这里干了什么。

feat: fix ** bug.

推荐 git commit -a github.com/zurawiki/gptcommit

就目前而言，这个功能不需要填入 APIKeys

以前用 Fabricator 协作过，所以都是 fabricator 上的 comments

跟着项目来，有些项目写的很细就写很细，有些新增功能就打个 1 ，修改就打个 fix ，我也跟着

比较喜欢用 Module: Comment.