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

polyang · 2021-08-06T01:58:45Z

最近我无意中注意到同事代码时 commit message 写的是“1”、“111”、“。。。。”这种无意义的 message，就是下面这种：进而联想到，我们在开发时，commit message 是不是写的详细一点比较好？

message

commit

代码

git

73 replies • 2024-11-03 23:16:22 +08:00

AoEiuV020

Aug 6, 2021

1

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

Tianao

Aug 6, 2021

2

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

zinete

Aug 6, 2021

3

git hooks 整个代码提交规范

Morriaty

Aug 6, 2021

2

4

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

Kusoku

Aug 6, 2021

1

5

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

Shook

Aug 6, 2021

1

6

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

huangmingyou

Aug 6, 2021

1

7

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

rowan6

Aug 6, 2021

8

当然

deplivesb

Aug 6, 2021

9

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

nullref

Aug 6, 2021

1

10

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

yolee599

Aug 6, 2021

18

11

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

polyang

OP

Aug 6, 2021

12

@yolee599 感谢，我去看看

ch2

Aug 6, 2021

13

一句话说清楚

chengxynds

Aug 6, 2021

14

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

xwayway

Aug 6, 2021

15

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

gowk

Aug 6, 2021

16

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

pengtdyd

Aug 6, 2021

17

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

whorusq

Aug 6, 2021

18

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

1daydayde

Aug 6, 2021

19

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

rebel28

Aug 6, 2021

20

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

jdhao

Aug 6, 2021 via Android

21

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

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

auh

Aug 6, 2021

22

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

locoz

Aug 6, 2021 via Android

1

23

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

zenwong

Aug 6, 2021

24

git cz

maninfog

Aug 6, 2021 via iPhone

1

25

你这个同事有点离谱

ysicing

Aug 6, 2021

26

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

monospace

Aug 6, 2021

1

27

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

mritd

Aug 6, 2021

28

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

codehz

Aug 6, 2021

29

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

jonathanchoo

Aug 6, 2021

30

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

passerbytiny

Aug 6, 2021 via Android

1

31

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

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

noqwerty

Aug 6, 2021 via Android

32

直接全局用 commitizen

FinnBai

Aug 6, 2021

33

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

erwin985211

Aug 6, 2021

34

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

ThanksSirAlex

Aug 6, 2021

35

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

ckdxc

Aug 6, 2021

36

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

boris93

Aug 6, 2021 via iPhone

37

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

xz410236056

Aug 6, 2021

38

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

codehz

Aug 6, 2021

39

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

weiwenhao

Aug 6, 2021

1

40

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

Aug 6, 2021

41

@yolee599 我马一下

pkoukk

Aug 6, 2021

42

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

PinkStarrySky

Aug 6, 2021

43

写清楚点方便你自己看.

Sain

Aug 6, 2021

44

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

no1xsyzy

Aug 6, 2021

45

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

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

no1xsyzy

Aug 6, 2021

46

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

iiqiu

Aug 6, 2021

47

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

suotm

Aug 6, 2021

48

111 就太离谱了！

wolfie

Aug 6, 2021

1

49

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

www5070504

Aug 6, 2021

50

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

kafkaonsea

Aug 6, 2021

51

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

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

rekulas

Aug 6, 2021

52

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

hzz2

Aug 6, 2021

53

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

QHKZ

Aug 6, 2021

1

54

我写这段代码的时候，只有上帝和我知道。现在，只有上帝知道了。
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

echoechoin

Aug 6, 2021

55

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

chjieza

Aug 6, 2021

56

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

ErenJaeger

Aug 6, 2021

57

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

type: title
blank line
body

jaredyam

Aug 6, 2021

58

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

我要开始详细说明了……

hallDrawnel

Aug 6, 2021

59

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

Huelse

Aug 6, 2021

60

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

JerryCha

Aug 6, 2021

61

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

jiyinyiyong

Aug 6, 2021

1

62

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

ztcaoll222

Aug 7, 2021

63

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

molvqingtai

Aug 7, 2021 via Android

64

你需要 commitlint

crclz

Aug 7, 2021

65

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

DawnMoon

Aug 7, 2021 via Android

66

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

AmaQuinton

Aug 7, 2021

67

写清楚一些,会省好多事

matrix67

Aug 7, 2021

68

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

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

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

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

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

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

polyang

OP

Aug 7, 2021

69

@villivateur 哈哈，没必要吧

cwek

Aug 7, 2021

70

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

NetCobra

Aug 8, 2021

71

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

Cu635

Aug 16, 2021

72

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

Zeeland4v

Nov 3, 2024

73

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