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

message

commit

代码

git

73 条回复 • 2024-11-03 23:16:22 +08:00

1

AoEiuV020

2021-08-06 10:00:44 +08:00

1

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

2

Tianao

2021-08-06 10:01:43 +08:00

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

3

zinete

2021-08-06 10:05:14 +08:00

git hooks 整个代码提交规范

4

Morriaty

2021-08-06 10:06:18 +08:00

2

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

5

Kusoku

2021-08-06 10:06:45 +08:00

1

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

6

Shook

2021-08-06 10:07:21 +08:00

1

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

7

huangmingyou

2021-08-06 10:07:47 +08:00

1

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

8

q2551430130

2021-08-06 10:08:10 +08:00

当然

9

deplivesb

2021-08-06 10:11:35 +08:00

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

10

zhangchongjie

2021-08-06 10:13:41 +08:00

1

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

11

yolee599

2021-08-06 10:18:18 +08:00

18

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

12

polyang

OP

2021-08-06 10:21:00 +08:00

@yolee599 感谢，我去看看

13

ch2

2021-08-06 10:26:19 +08:00

一句话说清楚

14

chengxynds

2021-08-06 10:38:47 +08:00

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

15

xwayway

2021-08-06 10:42:30 +08:00

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

16

gowk

2021-08-06 10:47:01 +08:00

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

17

pengtdyd

2021-08-06 10:53:54 +08:00

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

18

whorusq

2021-08-06 11:03:25 +08:00

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

19

0312birdzhang

2021-08-06 11:28:13 +08:00

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

20

violetlai

2021-08-06 11:45:44 +08:00

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

21

jdhao

2021-08-06 11:49:54 +08:00 via Android

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

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

22

auh

2021-08-06 11:56:22 +08:00

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

23

locoz

2021-08-06 12:07:59 +08:00 via Android

1

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

24

zenwong

2021-08-06 12:54:14 +08:00

git cz

25

maninfog

2021-08-06 12:55:36 +08:00 via iPhone

1

你这个同事有点离谱

26

ysicing

2021-08-06 13:03:06 +08:00

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

27

monospace

2021-08-06 13:03:36 +08:00

1

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

28

mritd

2021-08-06 13:06:16 +08:00

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

29

codehz

2021-08-06 13:07:29 +08:00

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

30

jonathanchoo

2021-08-06 13:53:34 +08:00

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

31

passerbytiny

2021-08-06 14:04:57 +08:00 via Android

1

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

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

32

noqwerty

2021-08-06 14:10:39 +08:00 via Android

直接全局用 commitizen

33

baiyi

2021-08-06 14:13:47 +08:00

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

34

erwin985211

2021-08-06 14:14:39 +08:00

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

35

ThanksSirAlex

2021-08-06 14:27:03 +08:00

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

36

ckdxc

2021-08-06 14:28:13 +08:00

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

37

boris93

2021-08-06 14:31:07 +08:00 via iPhone

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

38

xz410236056

2021-08-06 14:33:06 +08:00

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

39

codehz

2021-08-06 14:34:56 +08:00

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

40

weiwenhao

2021-08-06 14:41:31 +08:00

1

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

41

clockwork1122

2021-08-06 14:49:48 +08:00

@yolee599 我马一下

42

pkoukk

2021-08-06 14:55:06 +08:00

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

43

SimleCp

2021-08-06 15:02:15 +08:00

写清楚点方便你自己看.

44

Sain

2021-08-06 15:23:36 +08:00

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

45

no1xsyzy

2021-08-06 15:31:16 +08:00

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

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

46

no1xsyzy

2021-08-06 15:33:15 +08:00

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

47

ypzhou

2021-08-06 15:37:44 +08:00

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

48

suotm

2021-08-06 15:38:31 +08:00

111 就太离谱了！

49

wolfie

2021-08-06 15:40:57 +08:00

1

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

50

www5070504

2021-08-06 16:00:40 +08:00

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

51

kafkaonsea

2021-08-06 16:03:56 +08:00

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

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

52

rekulas

2021-08-06 16:08:47 +08:00

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

53

hzz2

2021-08-06 16:25:36 +08:00

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

54

QHKZ

2021-08-06 16:42:16 +08:00

1

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

55

echoechoin

2021-08-06 17:00:46 +08:00

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

56

chjieza

2021-08-06 17:17:13 +08:00

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

57

ErenJaeger

2021-08-06 18:18:03 +08:00

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

type: title
blank line
body

58

jaredyam

2021-08-06 20:46:16 +08:00

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

我要开始详细说明了……

59

hallDrawnel

2021-08-06 21:37:43 +08:00

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

60

Huelse

2021-08-06 21:51:17 +08:00

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

61

JerryCha

2021-08-06 22:40:17 +08:00

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

62

jiyinyiyong

2021-08-06 23:04:59 +08:00

1

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

63

ztcaoll222

2021-08-07 01:19:14 +08:00

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

64

molvqingtai

2021-08-07 02:43:52 +08:00 via Android

你需要 commitlint

65

crclz

2021-08-07 09:35:41 +08:00

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

66

villivateur

2021-08-07 09:49:31 +08:00 via Android

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

67

AmaQuinton

2021-08-07 11:26:54 +08:00

写清楚一些,会省好多事

68

matrix67

2021-08-07 14:15:11 +08:00

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

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

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

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

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

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

69

polyang

OP

2021-08-07 18:53:53 +08:00

@villivateur 哈哈，没必要吧

70

cwek

2021-08-07 19:09:28 +08:00

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

71

NetCobra

2021-08-08 03:58:35 +08:00

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

72

Cu635

2021-08-16 15:55:51 +08:00

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

73

Zeeland4v

26 天前

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