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

2021-08-06 09:58:45 +08:00
 polyang

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

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

7489 次点击
所在节点    程序员
73 条回复
clockwork1122
2021-08-06 14:49:48 +08:00
@yolee599 我马一下
pkoukk
2021-08-06 14:55:06 +08:00
自己开发的时候瞎写,merge 进 master 之前 suqash,然后才会好好写。
commit 就是个 crtl+s,不能每次都写一大段吧
SimleCp
2021-08-06 15:02:15 +08:00
写清楚点方便你自己看.
Sain
2021-08-06 15:23:36 +08:00
一个功能一次 commit,merge 之前 suqash 写
no1xsyzy
2021-08-06 15:31:16 +08:00
{feat,fix,refactor,style}(模块): xxx
实在想写不说不爽的时候再空一行添加更多文字
如果在一个 commit 内存在多种更改,则「首行」的定义可以宽限到多行。

@passerbytiny JB 家的约定是首行 120 字(
no1xsyzy
2021-08-06 15:33:15 +08:00
不过我考虑了一下,commit msg 应当服务于 rebase -i 和 cherry pick,可以直接看出到底干了啥。
ypzhou
2021-08-06 15:37:44 +08:00
你去看看 github 看看排名前几的提交不就知道了
suotm
2021-08-06 15:38:31 +08:00
111 就太离谱了!
wolfie
2021-08-06 15:40:57 +08:00
之前有同事 自己开发一个项目时候 就这么提交。
后来改代码,经常跨模块改串了,后来回滚都不知道怎么回滚。
bug 指数级增长。
www5070504
2021-08-06 16:00:40 +08:00
这种不好好写 commit 信息的 早晚有一天恶心到自己或者恶心到别人
kafkaonsea
2021-08-06 16:03:56 +08:00
小公司只能靠自觉共识约束了

大公司可以搞 CI 流水线,不符合格式规范的 git commit,流水线失败,不允许合入 master
rekulas
2021-08-06 16:08:47 +08:00
之前在外企呆过,都是规范格式,描述有误被打回 pr 的大有人在,现在养成了习惯尽可能一句话描述清楚改动
养成这习惯很有好处,有一次调试一个 bug 追踪到了 4 年前,根据详细的 commit 描述 1 小时就定位到了,如果 msg 乱写我估计 1 天都未必能找到
hzz2
2021-08-06 16:25:36 +08:00
leader 管起来 制定规范 https://segmentfault.com/a/1190000009048911
QHKZ
2021-08-06 16:42:16 +08:00
我写这段代码的时候,只有上帝和我知道。现在,只有上帝知道了。
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 <syzbot+a5df189917e79d5e59c9@syzkaller.appspotmail.com>
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 <luiz.von.dentz@intel.com>
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
echoechoin
2021-08-06 17:00:46 +08:00
我们公司是 添加一个 hook 限制一下字数
chjieza
2021-08-06 17:17:13 +08:00
上 husky,在 git 钩子加验证就完了,对应 jira 的 feat 或者 fix
ErenJaeger
2021-08-06 18:18:03 +08:00
卧槽,写这 111 不得被打一顿?
我看约定俗成的规范是

type: title
blank line
body
jaredyam
2021-08-06 20:46:16 +08:00
和写 docstring 差不多。最好先用较少的字符进行内容梗概,也即比较短的一行。如果觉得有需要详细说明的地方,隔一行,再另起一行,详细说明。如:
------------------------------
这是常见的 commit 写法

我要开始详细说明了……
hallDrawnel
2021-08-06 21:37:43 +08:00
1111 这不得打一顿?后面的人看了全不知道你干了啥呀。我们对 mater 的所有合并都会发通知到开发群里,群里所有人都能看见你在 commit message 上写了啥。commit message 要求用 commitizen 。
Huelse
2021-08-06 21:51:17 +08:00
你同事这个过分了,好歹说一下干了啥,中文写都可以

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/794004

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX