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

[netabare]

大概是从四年级还是五年级做自己的项目开始，感觉好像就隐隐约约有倾向想要在 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 普遍一句话带过。

[roundRobin]

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

[netabare]

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

[roundRobin]

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

[arischow]

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

[wu67]

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

[Contextualist]

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

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

[ytmsdy]

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

[yKXSkKoR8I1RcxaS]

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

[tolbkni]

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

[GeruzoniAnsasu]

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


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

[xubingok]

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

[Scarb]

之前看到 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]

commit 写表象，注释写细致

[tyrantZhao]

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

[janus77]

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

[linzhe141]

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

[yb2313]

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

[intouchables]

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

[bigfei]

直接 copilot 生成 commit msg 就可以了

[Daniel17]

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