这是一个创建于 395 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近公司强制使用 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
hokori 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
jaylee4869 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