发现自己的 commit 标题和内容越来越长了

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 135 天前的主题，其中的信息可能已经有所发展或是发生改变。

大概是从四年级还是五年级做自己的项目开始，感觉好像就隐隐约约有倾向想要在 commit 里面写越来越多东西。一开始只是写比如从哪个 Stackoverflow 讨论串找到的参考资料，后来到一些算法或者设计上的东西，然后发现自己的 commit 标题越来越长，感觉长过头了就写进了 message 里面，然后就在 message 里面写 markdown 了。

上班后感觉好像这个倾向又被强化了，一方面摸鱼写的代码的 commit 很容易一个 commit 里面覆盖多个内容，而不是像写自己的项目那样细粒度到一两个文件，另一方面又总是担心意图没解释清楚别人难以理解自己的代码。

所以 commit 有时候就会长这样：

```markdown

[Core] (fix) Sorting algorithm, XXX Page, YYY Service

- Designed an algorithm to sort a certain dataset according to some requirements and constraints
- Included this algorithm into XXX page
- Extracted several methods to YYY service
- Removed deprecated codes
- Added test suite for subjects mentioned above

The algorithm scans the incoming dataset, which should conform to ..., at a first pass, it will ...

Some code has been refactored and reformatted.
```

不过也不总是这么长就是，如果 commit 改变的东西不多的话，那倒是经常一两个 bullet 就完了。

另外也感觉发 PR 的时候好像我总喜欢写得像 GitHub 的 readme 一样。

不过也听说是不是说长 commit 是新手的普遍操作，senior 的 commit 普遍一句话带过。

31 条回复 • 2024-07-21 15:08:16 +08:00

roundRobin

135 天前

这些应该写在 merge request 的 description 里面，而不是 commit message

netabare

135 天前

@roundRobin 对一个 PR 来说，这个 algorithm 可能只是其中一小部分，issue 里面提到的东西经常需要改蛮多东西的，而且产品那边也可能也会反复需求。

roundRobin

135 天前

@netabare 那这种情况一个 issue 应该分成多个 PR 来提交，每个做其中一部分功能，PR 的可读性，单元测试的可靠性都能增加，然后一起做个 e2e testing 。我 review 的时候超过一页的 pr 都是直接 decline 让他 split 之后再提交

arischow

135 天前

看组织/团队或者项目要求，各有优缺

wu67

135 天前

我直接把 commit message 当月报来写. 到交月报的时候, 直接 git log 格式化一下就完事

Contextualist

135 天前

还是得拆分
commit message 长是表象，commit 过大或许才是根本原因。
> 总是担心意图没解释清楚别人难以理解自己的代码。
类似的，如果你也倾向于写大段的注释，不妨停下来想想看实现是不是可以被拆成多个函数/类

不用总想着一次写好一个完整的 commit
写一个片段就可以做一个临时的 commit ，然后在 push 前把这些临时的 commits 重新排列与合并成最终的 commits
善用 git rebase -i

ytmsdy

135 天前

不是挺好的么，总比 fix bug 强！

yKXSkKoR8I1RcxaS

135 天前

@ytmsdy 1111111111 ，Update ，修改，回家再搞

tolbkni

135 天前

你说的这些内容以前都是放在代码里作为注释块的

GeruzoniAnsasu

135 天前

> 发 PR 的时候好像我总喜欢写得像 GitHub 的 readme 一样
是对的

> 长 commit 是新手的普遍操作，senior 的 commit 普遍一句话带过
可能是因为你没能很好地贯彻 1 commit 只做一件事的原则

xubingok

135 天前

1.只写你做了什么即可,不用写做这个的原因和具体方式.
2.示例 commit 明显可以拆成几个,典型的"删除过期代码".

Scarb

135 天前

之前看到 netty 的三段式 commit message ，觉得挺好，可以参考一下。举个例子
```
Aggressively remove PoolThreadCache references from its finalizer object

Motivation:
If a cache's FastThreadLocalThread owner win the race to remove the cache, due to debugging
capabilities, it's finalizer will still retain a strong reference to it, causing few classes to leak (and eventually, their ClassLoader).
Despite we cannot avoid finalizers to wait the finalization pass, we can reduce the memory footprint of "leaked" instances before the finalization happen.

Modification:
non-debug early cache removal can remove the cache strong reference within FreeOnFinalize, making it an emtpy shell, eligible for GC.

Result:
Smaller memory footprint while waiting finalization to happen
```

guanzhangzhang

135 天前

commit 写表象，注释写细致

tyrantZhao

135 天前

这个多半是在一个 commit 里做了太多事了，不太合适。

janus77

135 天前

问一个问题，你大段覆盖别人的代码的时候，会看别人之前的 commit msg 吗？会担心看不懂而影响你的覆盖工作吗？

linzhe141

135 天前

@tyrantZhao 不是自己项目，真不想弄那么细

yb2313

135 天前

@wu67 还有日报, 周报, OKR, 统统交给 ai

intouchables

135 天前

https://github.com/SerenityOS/serenity/pull/18224/commits/b6456a8040d323823a59243dfa99ee256ca48df6

bigfei

135 天前

直接 copilot 生成 commit msg 就可以了

Daniel17

135 天前

挺好的，我同事的 commit message 都是 update ，update

echoless

135 天前

有人看 commit message?

https://github.com/swuecho/chat/blob/master/scripts/auto_commit.py

shaozelin030405

135 天前

update ，fix ，fix: 调整

TeslaM3

134 天前

挺奇葩的，如今 IDEA 这么丰富的现状还使用命令。

feiyan35488

134 天前

业务需求和设计思路可以写到 mr 的 message 里，
算法的文档可以写到代码注释里

feiyan35488

134 天前

@TeslaM3 命令行效率高，与 idea 无关，可以避免脱离 idea 不会使用 git 的情况，比如 linux 上，或换 idea 的情况

woshihgs

134 天前

牛四年级就开始做项目了

1rv013c6aiWPGt24

134 天前 via Android

四五年级…牛逼啊

RockShake

134 天前

你的内容适合放在 Pull Request 里面，Commit 的规范可以参考 Conversional Commit ，那个说的挺清楚的

artiga033

134 天前 via Android

commit 我一般是保证简洁易读，甚至有时为了压缩长度在保证可读性的前提下破坏自然语言语法（比如省略一些虚词介词量词）

chengxy

134 天前

@Seria #8 暂存

netabare

132 天前

@UncleCAT4 是指大四大五啦，法国的大学学制是五年的。

@roundRobin 主要也是看团队里面并没有把 PR 细化到这个地步，一般一个 issue 就是一个 PR ，如果大家的 commit 和 PR 都很细的话我肯定是跟着他们做的。GitHub 上的个人项目倒是不会做那么细就是……

@Contextualist 好建议，我倒是还没太熟悉 rebase 的用法，感谢提醒。

@tolbkni 注释我感觉问题在于后面改来改去的很容易就会丢掉上下文……

@GeruzoniAnsasu 示例这个确实不太好，不过一方面也有看团队里一个 PR 也就几个 commit ，我自然会倾向于避免上来就推几十个 commit 的巨型 PR ，所以也会有想要把 B 「虽然是不同的事情但在功能上相互联系的几件事组合在一起」的倾向，尤其是发了两次包含连续四五个 Refactor 的 PR 之后。

@Scarb 这个模版倒是不错，有时候我感觉我也有点像在往这方面靠。

@janus77 会的，会先看 git blame 找出 commit 的历史记录，问题是一般来说别人都是简单的一句话甚至没有提到他的代码意图，所以我才感觉如果有个 commit message 会清晰很多。