最近我无意中注意到同事代码时 commit message 写的是“1”、“111”、“。。。。”这种无意义的 message,就是下面这种:
进而联想到,我们在开发时,commit message 是不是写的详细一点比较好?
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
|
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
|
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 是什么鬼
|
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 @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 49 天前
https://github.com/undertone0809/gcop 可以看看这个项目,用 ai 更加轻松地撰写优质的 git commit 。
|