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

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

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

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

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

git cz

你这个同事有点离谱

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

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

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

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

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

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

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

直接全局用 commitizen

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

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

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

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

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

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

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

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