这是一个创建于 781 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近公司强制使用 Commitlint ，而且要求必须 feat: fix: docs:等单词开头。
个人感觉挺浪费时间的。
大家觉得呢？
52 条回复 2023-08-22 12:35:59 +08:00
 | 1 molvqingtai 2023-08-21 14:51:00 +08:00  35 那么浪费了你多少时间？ |
 | 2 ufan0 2023-08-21 14:52:04 +08:00 不用，用也问题不大。 我们实话实说，如果觉得这个事情浪费时间没啥用处，纯粹做样子恶心人。 那比这个恶心人的事情多了去了，无需在意，反正也改变不了什么。 |
 | 3 DOOMS 2023-08-21 14:53:39 +08:00 不觉得浪费时间吧 |
 | 4 pansongya 2023-08-21 14:55:25 +08:00 aicommits |
 | 5 guanguans 2023-08-21 15:00:04 +08:00 1 |
 | 6 Alias4ck 2023-08-21 15:05:26 +08:00 1 我觉得统一规范挺好的啊 你为公司工作按照规范来为啥是浪费时间？ |
 | 7 crysislinux 2023-08-21 15:08:00 +08:00 我觉得 commit 的时候检查有点累赘。push 的时候检查一下最后一条就行了。我更倾向于 merge 的时候检查，但是 GitHub 不支持这种需求。 |
 | 8 laoona 2023-08-21 15:08:13 +08:00 习惯就好了。公司有规范就按规范的来，你觉得不合理，可以提出质疑。不过 commitlint 现在基本上都是标配了吧。 |
 | 9 ciki 2023-08-21 15:10:47 +08:00 挺好的，后续追踪提交会很有用 |
 | 10 frankyzf 2023-08-21 15:11:29 +08:00 浪费写这几个字母的时间可以省很多查找 commit 的时间，应该是很值吧 |
 | 11 Pastsong 2023-08-21 15:13:34 +08:00 @crysislinux 可以 PR lint ，最后的 commit 默认是用 PR 名 |
 | 12 dif 2023-08-21 15:19:43 +08:00 以前我也这么觉得，后来有一次要通过会议找提交记录，结果清一色的 fix bug ，然后我现在宁愿多花点时间把提交记录写清楚。 |
 | 13 xiaoxuan6 2023-08-21 15:20:57 +08:00 6 这样不浪费时间？[Imgur]( https://imgur.com/dLBzzL7) |
 | 14 shiny 2023-08-21 15:23:23 +08:00 2 浪费了你的时间，却节省了大家的时间 |
 | 15 RobinzzZ 2023-08-21 15:27:04 +08:00 等你查一个几年前的修改导致的 bug ，或者想找找自己的提交的时候，你看着 message 一堆数字就会骂自己 SB 了。 |
 | 16 pengtdyd 2023-08-21 15:35:41 +08:00 其实这个要看项目管理的本事，光使用 fix 这些没啥用，项目管理跟不上，最后会导致为了用而用，为了所谓的规范而规范，这样还不如全部写 1 更方便。 |
 | 17 crysislinux 2023-08-21 15:38:27 +08:00 @Pastsong 确实是，可以 GH 跑拦一下。 |
 | 18 Rache1 2023-08-21 15:56:47 +08:00 1 如果你能保证自己的 commit 信息始终是有意义的，倒是没必要，但是既然你都花时间去写 commit ，难道真的还差写那几个字符的时间吗？ 有些人就是不好好写 commit ，只是为了草草了事，后续找问题的时候，鬼知道为什么修改了  团队协作中，commit 信息很重要。哪怕就是自己的项目，像上面这种 commit ，过上一两个月，你真能想起来自己当初为啥要改吗？ |
 | 19 yhxx 2023-08-21 16:00:10 +08:00 要求必须 feat: fix: docs:等单词开头感觉没啥问题 但是有些复杂配置，大点的项目跑 lint 的过程有点久，这个时间有点不太能接受 |
 | 20 JxQg597 2023-08-21 16:03:22 +08:00 你觉得有问题，你可以提出你的想法给公司的项目管理。 有理有据的说出用 1 比用 feat:（功能修改 ）的优点是什么，并且也说出这样的缺点是什么。如果你都不能说服你自己，就没必要来这里找认同感来掩盖你的偷懒和编码逻辑的混乱。 反正我看接手屎山看到这些离谱的的东西，我肯定开喷。 |
 | 21 lx271896700133 OP @JxQg597 我做个人项目的时候，从来不用 Commitlint ，甚至很少认真写提交日志，这么多年也没遇到过什么问题。如果是公司项目，我可以把提交日志写详细一点，不过公司硬性规定的几个单词前缀，在我看来没啥用。所以来这里问问大家的看法。请不要直接把我定性为懒惰和逻辑混乱。谢谢 |
 | 22 zzz22333 2023-08-21 16:19:59 +08:00 @lx271896700133 前缀有利于做一些筛选，比如说发布 release note 的时候，就会用前缀做区分。 话说回来，加个前缀浪费了多少时间呢？ |
 | 23 TimPeake 2023-08-21 16:22:11 +08:00 工具里不是有插件吗。。。不会真有人手动敲这玩意儿吧 |
 | 24 swaggeek 2023-08-21 16:42:33 +08:00 @lx271896700133 协作做项目跟独狼做项目那是有区别的，假如你去查一个项目，要找个提交，发现时间线全是随便写的字母，你会怎么想。这种东西就是前期花点时间，方便后期维护和找 bug ，况且这也不用花多少时间啊。很难想象你这点时间都不花，能够花更多的时间在代码设计上。。。 |
 | 25 Al0rid4l 2023-08-21 16:48:03 +08:00 1 用 commitlint 肯定配 commitizen + cz-git 啊, 怎么还自己手敲的... |
 | 26 codeMore 2023-08-21 16:53:46 +08:00 自己分支随意，但是合并进入公共分支的时候，就需要规范一点了。这点能浪费多少时间？ |
| 27 JxQg597 2023-08-21 16:54:05 +08:00 @lx271896700133 #21 好的，不好意思。其实我本来也想提到公司项目和个人项目的。如果是公司项目你就按照公司要求的来，我觉得这样还挺好的，保证大家的协作的规范。 个人项目你爱咋样都可以的。 |
 | 28 shadowyue 2023-08-21 16:55:11 +08:00 看了上面的各种回复，很明显 Commitlint 就是为了保住当个基本的开发的下限 |
| 29 lx271896700133 OP @Al0rid4l 学习了 |
 | 30 suofeiya 2023-08-21 17:04:09 +08:00 就多打一个单词能浪费多少时间. |
 | 31 liuchuanfff 2023-08-21 17:12:10 +08:00 1 程序员门槛还是太低了，commit 规范都要吐槽吗 |
 | 32 iLtc 2023-08-21 17:14:52 +08:00 我们的项目会通过 `semantic-release` 来更新版本号。所以会有 `fix` 修订号+1 、`feat` 次版本号+1 、`break` 主版本号+1 这样的规则。 |
 | 33 kxaccelerise 2023-08-21 17:19:54 +08:00 这玩意自己写一个命令行工具来辅助快捷输入也就几行，然后随便定义几个 alias shell 命令就完事了。之后不就一秒钟的事 |
 | 34 msaionyc 2023-08-21 17:30:23 +08:00 手动敲也就两三秒吧。。。 |
 | 35 clf 2023-08-21 17:32:18 +08:00 配合 gitlab 等使用可以在 fix 后有 issue 啥的自动关闭（虽然我觉得有点离谱，验证都不用验证了。 |
 | 36 nothingistrue 2023-08-21 17:39:03 +08:00 如果你觉得 feat: fix: docs: 这么简单的玩意还浪费时间，那你就真得是正在贡献屎山。如果你觉得 feat: fix: docs: 只在提交的时候有用，即为了前缀而前缀，那你们整个团队都在贡献屎山，在此前提下再去认真写前缀，确实是浪费时间。 @lx271896700133 #21 @swaggeek #24 个人项目也要好好写 commit message 的。commit message ，是涵盖查询标记、简单笔记、历史溯源等多项好处的，不用是傻瓜。 |
 | 37 Huelse 2023-08-21 17:42:53 +08:00 1 我选择最后 Squash commits |
 | 38 c3de3f21 2023-08-21 17:44:42 +08:00 commitlint 加 changelog 插件可以快速生成版本日志 |
 | 39 zhangyq008 2023-08-21 17:47:07 +08:00 @xiaoxuan6 #13 哈哈哈，笑死 |
 | 40 declandragon 2023-08-21 17:48:36 +08:00 个人习惯是把 commit msg 写清晰，一个事情 commit 一次，不把多个事情混在一起。 公司也用 commitlint ，我觉得这样很好，用规则是做一些要求，节省管理成本。 |
 | 42 jsq2627 2023-08-21 18:40:44 +08:00 格式无所谓，关键是要花时间写内容 |
 | 43 unco020511 2023-08-21 20:20:35 +08:00 自己的分支都无所谓的,怎么玩都行,但是合主干的那个 squash commits 就必须照团队规范了 |
 | 44 lavvrence 2023-08-21 20:27:19 +08:00 支持公司决策，从软件工程角度，这里必须强制执行。 |
 | 45 tairan2006 2023-08-21 20:38:08 +08:00 公司是对的 |
 | 46 dayeye2006199 2023-08-22 00:27:21 +08:00 还有强制 squash commit 的，你是没看见 |
| 47 lx271896700133 OP @Huelse 这个好 |
 | 48 Imindzzz 2023-08-22 09:09:59 +08:00 via Android 把你们平时的 commit message 贴出来看看呢 |
 | 49 1018ji 2023-08-22 09:27:36 +08:00 熟悉了浪费啥时间，就是正常写 commit |
 | 50 govizlora 2023-08-22 10:17:33 +08:00 via iPhone @dayeye2006199 squash 并不会浪费时间吧 |
 | 51 Jaosn 2023-08-22 12:28:27 +08:00 加个单词就能浪费时间了啊 |
 | 52 momo24672 2023-08-22 12:35:59 +08:00 我觉得强制 commitlint 完全没有意义，我日常提 PR PR title: ticketNum: feature description or Bugfix: xxx Comments: follow https://keepachangelog.com/en/1.0.0/ 最后 squash commit |
Select Language