提交代码时 git commit message 是不是写的详细点比较好？

不说多详细，起码要有一行文字看完大概知道这个 commit 是做了什么，

废话，肯定是要详细。这种写也可能是 commit 粒度太细了，没有耐心写。

git hooks 整个代码提交规范

一些大的开源类 repo 有个标准的 commit 规范，https://www.conventionalcommits.org/en/v1.0.0/，不过说实话，一般公司里很难遵守

不用很详细，但是需要清晰和一定概括性，详细的信息应该附在代码中作为注释

起码要说一下这个 commit 是做什么的吧

理论上肯定要写清楚，并且作为开发规范。

当然

也不能是 800 字的作文吧，但至少要让别人能知道你这是这个 commit 干了啥

这是基本的东西吧，每一次提交的大概变动，先不说为了团队，自己以后 debug 的时候也好看，回滚方便

我一般都是建好仓库后建一个模板文件：.gitmessage，然后执行 git config commit.template .gitmessage，之后提交的时候执行 git commit 就会自动引用模板，在相应的位置填写信息就可以了，禁止使用 git commit -m 。模板参照这个： https://github.com/angular/angular/blob/master/CONTRIBUTING.md

@yolee599 感谢，我去看看

一句话说清楚

知道干了啥就行 业务+动作

我们 commit message 有需求的一般需要贴上 jira 链接，然后大致写下实现了什么。如果是修改 bug，要说下改动点，影响范围什么的

@yolee599 Angular 扎心了，用的人少，却因为 git commit 规范被提及。

[bug 号｜需求号｜其它] 模块名 > 功能名：然后简单描述本次提交做了什么工作
我们一般这么写，仅供参考

看一下 linux 的提交记录，详细到飞起

IDE 基本都有 git commite template 插件吧 照着模版填就好了

不说要写的超级详细，起码写一下做了什么更改，为啥更改。

不写 commit 信息的都是草台班子

提交文本。一般就是，新增，修复，重构开头。然后，简单，描述一下涉及的业务功能，架构功能，修复的 bug 。等。大概知道干啥了就行。文字不要超过 20 个字。超过部分，可以作为详细解析，比如想要分享一下自己是如何思考和解决的。相当于一个详细解释。供大家没事干的时候欣赏。哈哈哈

大致做了啥总得用一句话描述一下吧…这 111 是真离谱，测试的时候这么搞一下还行，后面强制提交覆盖掉或者直接在另一个分支上搞都没啥影响，主要内容还这么搞就是单纯的不负责任了。

git cz

你这个同事有点离谱

详细点好，可以试试 @mritd 大佬写的工具 https://github.com/mritd/gitflow-toolkit

在我的团队要是有人写这种毫无意义的 commit message 的话，直接滚蛋！

@ysicing #26 还有点小 bug，终端提示有时候按快了就会没一行... 虽然不影响使用但是挺烦的，现在也没找到啥好用的终端库

建议本地随意写，push 之前 rebase 一下再修改，避免无意义的 commit 和反复的修改。。

自己分支无所谓吧，提 mr 的时候描述详细一点，然后压缩一下提交记录

git commit message 是有通用约定的（当然这是国际而非国内开发届的约定）的最小规范的：第一行写不超过 80 个字符宽度的标题，空一行从第三行开始写详细或附加内容，后者是可选的。至于具体怎么写，就没限制了，说人话就行。

至于“1”、“111”、这样的提交信息，只有刚从 SVN 或者其他 VCS 转过来的新手才会提交，而允许这种提交信息存在的团队也必然是新手团队成熟的团队这种提交压根不会被合并到主分支。

直接全局用 commitizen

最好是一行就能概括，这说明这个 commit 只做了一件事。如果有补充说明，可以换行写长篇的补充，这样的好处是在概览的时候，只看到有用的概括信息，然后详细的信息在 commit message 中也能看到。

别说别人最起码自己能知道这次改了啥。

开源项目写详细一点，公司内部无所谓了，反正没人看

@codehz 我一直都是 用的那个 interactive rebase 那个, 但是万一操作的是 公共分支, 然后 push -f 好危险, 有啥办法安全操作不, 我都是 rebase | push -f 自己的分支

第一行作为标题，一句话概括干了啥
空一行，第三行开始可以写详细的描述，非必需

哪怕什么都不写呢。。。这 1111 是什么鬼

@ckdxc 本地单独开分支搞啊，反正分支不要钱

git commit -m 'feat(工单 /功能 /可选): xxx' # 功能迭代
git commit -m 'fix: xxx' # bug 修复
git commit -m 'refactor: xxx' # 重构
git commit -m 'chore: xxx' # 杂事

https://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html
我现在就遵守这个，每一行 commit 都认真写， 至于其他人怎么写我就不管了。

@yolee599 我马一下

自己开发的时候瞎写，merge 进 master 之前 suqash，然后才会好好写。
commit 就是个 crtl+s，不能每次都写一大段吧

写清楚点方便你自己看.

一个功能一次 commit，merge 之前 suqash 写

{feat,fix,refactor,style}(模块): xxx
实在想写不说不爽的时候再空一行添加更多文字
如果在一个 commit 内存在多种更改，则「首行」的定义可以宽限到多行。

@passerbytiny JB 家的约定是首行 120 字（

不过我考虑了一下，commit msg 应当服务于 rebase -i 和 cherry pick，可以直接看出到底干了啥。

你去看看 github 看看排名前几的提交不就知道了

111 就太离谱了！

之前有同事 自己开发一个项目时候 就这么提交。
后来改代码，经常跨模块改串了，后来回滚都不知道怎么回滚。
bug 指数级增长。

这种不好好写 commit 信息的 早晚有一天恶心到自己或者恶心到别人

小公司只能靠自觉共识约束了

大公司可以搞 CI 流水线，不符合格式规范的 git commit，流水线失败，不允许合入 master

之前在外企呆过，都是规范格式，描述有误被打回 pr 的大有人在，现在养成了习惯尽可能一句话描述清楚改动
养成这习惯很有好处，有一次调试一个 bug 追踪到了 4 年前，根据详细的 commit 描述 1 小时就定位到了，如果 msg 乱写我估计 1 天都未必能找到

leader 管起来 制定规范 https://segmentfault.com/a/1190000009048911

我写这段代码的时候，只有上帝和我知道。现在，只有上帝知道了。
commit 的作用是不用去看代码，也能知道代码发生了什么变动。
贴一段 linux 内核的最新 commit：
https://github.com/torvalds/linux/commit/e04480920d1eec9c061841399aa6f35b6f987d8b
-----
Bluetooth: defer cleanup of resources in hci_unregister_dev()
syzbot is hitting might_sleep() warning at hci_sock_dev_event() due to
calling lock_sock() with rw spinlock held [1].

It seems that history of this locking problem is a trial and error.

Commit b40df57 ("[PATCH] bluetooth: fix socket locking in
hci_sock_dev_event()") in 2.6.21-rc4 changed bh_lock_sock() to
lock_sock() as an attempt to fix lockdep warning.

Then, commit 4ce61d1 ("[BLUETOOTH]: Fix locking in
hci_sock_dev_event().") in 2.6.22-rc2 changed lock_sock() to
local_bh_disable() + bh_lock_sock_nested() as an attempt to fix the
sleep in atomic context warning.

Then, commit 4b5dd69 ("Bluetooth: Remove local_bh_disable() from
hci_sock.c") in 3.3-rc1 removed local_bh_disable().

Then, commit e305509 ("Bluetooth: use correct lock to prevent UAF
of hdev object") in 5.13-rc5 again changed bh_lock_sock_nested() to
lock_sock() as an attempt to fix CVE-2021-3573.

This difficulty comes from current implementation that
hci_sock_dev_event(HCI_DEV_UNREG) is responsible for dropping all
references from sockets because hci_unregister_dev() immediately
reclaims resources as soon as returning from
hci_sock_dev_event(HCI_DEV_UNREG).

But the history suggests that hci_sock_dev_event(HCI_DEV_UNREG) was not
doing what it should do.

Therefore, instead of trying to detach sockets from device, let's accept
not detaching sockets from device at hci_sock_dev_event(HCI_DEV_UNREG),
by moving actual cleanup of resources from hci_unregister_dev() to
hci_cleanup_dev() which is called by bt_host_release() when all
references to this unregistered device (which is a kobject) are gone.

Since hci_sock_dev_event(HCI_DEV_UNREG) no longer resets
hci_pi(sk)->hdev, we need to check whether this device was unregistered
and return an error based on HCI_UNREGISTER flag. There might be subtle
behavioral difference in "monitor the hdev" functionality; please report
if you found something went wrong due to this patch.

Link: https://syzkaller.appspot.com/bug?extid=a5df189917e79d5e59c9 [1]
Reported-by: syzbot <[email protected]>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes: e305509 ("Bluetooth: use correct lock to prevent UAF of hdev object")
Acked-by: Luiz Augusto von Dentz <[email protected]>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
master
@torvalds
Tetsuo Handa authored and torvalds committed 13 hours ago
1 parent 0b53abf commit e04480920d1eec9c061841399aa6f35b6f987d8b

我们公司是 添加一个 hook 限制一下字数

上 husky，在 git 钩子加验证就完了，对应 jira 的 feat 或者 fix

卧槽，写这 111 不得被打一顿？
我看约定俗成的规范是

type: title
blank line
body

和写 docstring 差不多。最好先用较少的字符进行内容梗概，也即比较短的一行。如果觉得有需要详细说明的地方，隔一行，再另起一行，详细说明。如：
------------------------------
这是常见的 commit 写法

我要开始详细说明了……

1111 这不得打一顿？后面的人看了全不知道你干了啥呀。我们对 mater 的所有合并都会发通知到开发群里，群里所有人都能看见你在 commit message 上写了啥。commit message 要求用 commitizen 。

你同事这个过分了，好歹说一下干了啥，中文写都可以

我们跟包了一层 Jira 的系统关联的，不带上编号不能推送到 remote 仓库

leader: 来, 我看看你们这周都干了什么.
你: 我给项目 AAA 加了一个菜单, 对接了后端的 BBB 功能,
然后在 Webpack 配置做了一些优化, 编译时间少了 2.2s 多一点.
leader: 打的不错, 继续努力. (转过头) 那你呢?
你同事: 我 "1" 了一下, 然后 "111" 了一下.
leader: 说人话!
你同事: "。。。。"
leader: 你礼貌吗? 难道要我一行一行去代码里看你都搞了什么!

commit 基本一句话，但是 pr 会写得详细一点

你需要 commitlint

commit message 至少要能够保证：你自己过一周看到 commit message 的时候能知道这个 commit 里面干了什么。

你这同事要是跟我合作我要把他喷死

写清楚一些,会省好多事

@xz410236056 #38 这个人肯定经常组队打游戏，打 1 这个习惯应该是大多数魔兽世界玩家的通病。以前打团没有现在这些插件检查，准备就绪这些都是，团长都是听到的打 1，没到的打 1 。久而久之打 1 就演变成我知道了，明白这个意思哦了。

打开英雄联盟好友发来：1 ？（打吗）
你：1 （打）

选好位置：1 ？（还有人吗？开吗？）
你：1 （没人了开）

高层选人：1 ？（要一抢吗？）
四楼：豹女你：1 （收到）
选人：1 ？（锁吗）
四楼：1 （锁）

开始游戏了：1 ？（一级团吗）
狂野女猎手：饰品守卫（不团做眼）
狂野女猎手正在路上：1 ？（能抓？）

沙漠死神标记此处危险（不能）
疾风剑豪请求协助：1 ？（来帮）
曙光女神正在路上（来了）
狂野女猎手请求协助：1 ？（来龙？）
暗夜猎手正在路上（搞起）
狂野女猎手示意撤离：1 （足够了谢谢）
暗夜猎手表情点赞：1 （不客气这是我该做的）

@villivateur 哈哈，没必要吧

有可能临时的 commit，然后提交时没 rebase 压缩重写 commit 。

写这种提交信息的基本上都不明白为什么代码要有个提交的操作。

这种同事趁早开除，未来的屎山就是它们贡献的。

https://github.com/undertone0809/gcop 可以看看这个项目，用 ai 更加轻松地撰写优质的 git commit 。