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

[polyang]

最近我无意中注意到同事代码时 commit message 写的是“1”、“111”、“。。。。”这种无意义的 message，就是下面这种：

进而联想到，我们在开发时，commit message 是不是写的详细一点比较好？

[AoEiuV020]

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

[Tianao]

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

[zinete]

git hooks 整个代码提交规范

[Morriaty]

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

[Kusoku]

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

[Shook]

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

[huangmingyou]

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

[q2551430130]

当然

[deplivesb]

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

[zhangchongjie]

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

[yolee599]

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

[polyang]

@yolee599 感谢，我去看看

[ch2]

一句话说清楚

[chengxynds]

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

[xwayway]

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

[gowk]

https://chris.beams.io/posts/git-commit/

[pengtdyd]

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

[whorusq]

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

[0312birdzhang]

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

[violetlai]

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

[jdhao]

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

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

[auh]

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

[locoz]

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

[zenwong]

git cz

[maninfog]

你这个同事有点离谱

[ysicing]

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

[monospace]

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

[mritd]

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

[codehz]

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

[jonathanchoo]

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

[passerbytiny]

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

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

[noqwerty]

直接全局用 commitizen

[baiyi]

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

[erwin985211]

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

[ThanksSirAlex]

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

[ckdxc]

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

[boris93]

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

[xz410236056]

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

[codehz]

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

[weiwenhao]

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 都认真写， 至于其他人怎么写我就不管了。

[clockwork1122]

@yolee599 我马一下

[pkoukk]

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

[SimleCp]

写清楚点方便你自己看.

[Sain]

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

[no1xsyzy]

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

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

[no1xsyzy]

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

[ypzhou]

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

[suotm]

111 就太离谱了！

[wolfie]

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

[www5070504]

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

[kafkaonsea]

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

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

[rekulas]

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

[hzz2]

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

[QHKZ]

我写这段代码的时候，只有上帝和我知道。现在，只有上帝知道了。
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 <[e-mail]>
Signed-off-by: Tetsuo Handa <[e-mail]>
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 <[e-mail]>
master
@torvalds
Tetsuo Handa authored and torvalds committed 13 hours ago
1 parent 0b53abf commit e04480920d1eec9c061841399aa6f35b6f987d8b

[echoechoin]

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

[chjieza]

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

[ErenJaeger]

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

type: title
blank line
body

[jaredyam]

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

我要开始详细说明了……

[hallDrawnel]

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

[Huelse]

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

[JerryCha]

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

[jiyinyiyong]

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

[ztcaoll222]

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

[molvqingtai]

你需要 commitlint

[crclz]

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

[villivateur]

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

[AmaQuinton]

写清楚一些,会省好多事

[matrix67]

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

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

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

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

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

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

[polyang]

@villivateur 哈哈，没必要吧

[cwek]

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

[NetCobra]

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

[Cu635]

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

[Zeeland4v]

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