老哥们，提交代码，用 Commitlint 吗？

[lx271896700133]

最近公司强制使用 Commitlint ，而且要求必须 feat: fix: docs:等单词开头。

个人感觉挺浪费时间的。

大家觉得呢？

[molvqingtai]

那么浪费了你多少时间？

[ufan0]

不用，用也问题不大。

我们实话实说，如果觉得这个事情浪费时间没啥用处，纯粹做样子恶心人。

那比这个恶心人的事情多了去了，无需在意，反正也改变不了什么。

[hokori]

不觉得浪费时间吧

[pansongya]

aicommits

[guanguans]

贴个自己的，可能用的上

https://github.com/guanguans/ai-commit

[Alias4ck]

我觉得统一规范挺好的啊 你为公司工作按照规范来为啥是浪费时间？

[crysislinux]

我觉得 commit 的时候检查有点累赘。push 的时候检查一下最后一条就行了。我更倾向于 merge 的时候检查，但是 GitHub 不支持这种需求。

[laoona]

习惯就好了。公司有规范就按规范的来，你觉得不合理，可以提出质疑。不过 commitlint 现在基本上都是标配了吧。

[ciki]

挺好的，后续追踪提交会很有用

[frankyzf]

浪费写这几个字母的时间可以省很多查找 commit 的时间，应该是很值吧

[Pastsong]

@crysislinux 可以 PR lint ，最后的 commit 默认是用 PR 名

[dif]

以前我也这么觉得，后来有一次要通过会议找提交记录，结果清一色的 fix bug ，然后我现在宁愿多花点时间把提交记录写清楚。

[xiaoxuan6]

这样不浪费时间？[Imgur]( https://imgur.com/dLBzzL7)

[shiny]

浪费了你的时间，却节省了大家的时间

[RobinzzZ]

等你查一个几年前的修改导致的 bug ，或者想找找自己的提交的时候，你看着 message 一堆数字就会骂自己 SB 了。

[pengtdyd]

其实这个要看项目管理的本事，光使用 fix 这些没啥用，项目管理跟不上，最后会导致为了用而用，为了所谓的规范而规范，这样还不如全部写 1 更方便。

[crysislinux]

@Pastsong 确实是，可以 GH 跑拦一下。

[Rache1]

如果你能保证自己的 commit 信息始终是有意义的，倒是没必要，但是既然你都花时间去写 commit ，难道真的还差写那几个字符的时间吗？

有些人就是不好好写 commit ，只是为了草草了事，后续找问题的时候，鬼知道为什么修改了


团队协作中，commit 信息很重要。哪怕就是自己的项目，像上面这种 commit ，过上一两个月，你真能想起来自己当初为啥要改吗？

[yhxx]

要求必须 feat: fix: docs:等单词开头感觉没啥问题
但是有些复杂配置，大点的项目跑 lint 的过程有点久，这个时间有点不太能接受

[JxQg597]

你觉得有问题，你可以提出你的想法给公司的项目管理。
有理有据的说出用 1 比用 feat:（功能修改 ）的优点是什么，并且也说出这样的缺点是什么。如果你都不能说服你自己，就没必要来这里找认同感来掩盖你的偷懒和编码逻辑的混乱。

反正我看接手屎山看到这些离谱的的东西，我肯定开喷。

[lx271896700133]

@JxQg597 我做个人项目的时候，从来不用 Commitlint ，甚至很少认真写提交日志，这么多年也没遇到过什么问题。如果是公司项目，我可以把提交日志写详细一点，不过公司硬性规定的几个单词前缀，在我看来没啥用。所以来这里问问大家的看法。请不要直接把我定性为懒惰和逻辑混乱。谢谢

[zzz22333]

@lx271896700133 前缀有利于做一些筛选，比如说发布 release note 的时候，就会用前缀做区分。 话说回来，加个前缀浪费了多少时间呢？

[TimPeake]

工具里不是有插件吗。。。不会真有人手动敲这玩意儿吧

[swaggeek]

@lx271896700133 协作做项目跟独狼做项目那是有区别的，假如你去查一个项目，要找个提交，发现时间线全是随便写的字母，你会怎么想。这种东西就是前期花点时间，方便后期维护和找 bug ，况且这也不用花多少时间啊。很难想象你这点时间都不花，能够花更多的时间在代码设计上。。。

[Al0rid4l]

用 commitlint 肯定配 commitizen + cz-git 啊, 怎么还自己手敲的...

[codeMore]

自己分支随意，但是合并进入公共分支的时候，就需要规范一点了。这点能浪费多少时间？

[JxQg597]

@lx271896700133 #21 好的，不好意思。其实我本来也想提到公司项目和个人项目的。如果是公司项目你就按照公司要求的来，我觉得这样还挺好的，保证大家的协作的规范。
个人项目你爱咋样都可以的。

[shadowyue]

看了上面的各种回复，很明显 Commitlint 就是为了保住当个基本的开发的下限

[lx271896700133]

@Al0rid4l 学习了

[suofeiya]

就多打一个单词能浪费多少时间.

[liuchuanfff]

程序员门槛还是太低了，commit 规范都要吐槽吗

[iLtc]

我们的项目会通过 `semantic-release` 来更新版本号。所以会有 `fix` 修订号+1 、`feat` 次版本号+1 、`break` 主版本号+1 这样的规则。

[kxaccelerise]

这玩意自己写一个命令行工具来辅助快捷输入也就几行，然后随便定义几个 alias shell 命令就完事了。之后不就一秒钟的事

[msaionyc]

手动敲也就两三秒吧。。。

[clf]

配合 gitlab 等使用可以在 fix 后有 issue 啥的自动关闭（虽然我觉得有点离谱，验证都不用验证了。

[nothingistrue]

如果你觉得 feat: fix: docs: 这么简单的玩意还浪费时间，那你就真得是正在贡献屎山。如果你觉得 feat: fix: docs: 只在提交的时候有用，即为了前缀而前缀，那你们整个团队都在贡献屎山，在此前提下再去认真写前缀，确实是浪费时间。

@lx271896700133 #21
@swaggeek #24
个人项目也要好好写 commit message 的。commit message ，是涵盖查询标记、简单笔记、历史溯源等多项好处的，不用是傻瓜。

[Huelse]

我选择最后 Squash commits

[c3de3f21]

commitlint 加 changelog 插件可以快速生成版本日志

[zhangyq008]

@xiaoxuan6 #13 哈哈哈，笑死

[declandragon]

个人习惯是把 commit msg 写清晰，一个事情 commit 一次，不把多个事情混在一起。
公司也用 commitlint ，我觉得这样很好，用规则是做一些要求，节省管理成本。

[picone]

@pansongya 这个貌似只是解决了 commit message 的问题？和是否 lint 无关

[jsq2627]

格式无所谓，关键是要花时间写内容

[unco020511]

自己的分支都无所谓的,怎么玩都行,但是合主干的那个 squash commits 就必须按照团队规范了

[jaylee4869]

支持公司决策，从软件工程角度，这里必须强制执行。

[tairan2006]

公司是对的

[dayeye2006199]

还有强制 squash commit 的，你是没看见

[lx271896700133]

@Huelse 这个好

[Imindzzz]

把你们平时的 commit message 贴出来看看呢

[1018ji]

熟悉了浪费啥时间，就是正常写 commit

[govizlora]

@dayeye2006199 squash 并不会浪费时间吧

[Jaosn]

加个单词就能浪费时间了啊

[momo24672]

我觉得强制 commitlint 完全没有意义，我日常提 PR

PR title: ticketNum: feature description or Bugfix: xxx
Comments: follow https://keepachangelog.com/en/1.0.0/

最后 squash commit