这是一个创建于 209 天前的主题，其中的信息可能已经有所发展或是发生改变。
一处功能性修改，比如 bug （ 1 行代码）
一处配置文件修改（ 1 行代码）
两处修改是不相干的
要分开提交吗？
背后的问题是大家提交习惯是按照进度一次提交（有点备份的意思），还是按照功能细分提交（日志会很多）？
 |
1
A1exL 2025 年 6 月 16 日  3
分开，revert 的时候方便，commit msg 也比较清晰
|
 |
2
GGPlayer 2025 年 6 月 16 日 1
小公司，会发现大部分人确实都是这 2 种习惯其中之一。
我更倾向于分开提交，尤其是修改的类型已经不一样的。 尤其是修复的，如果有多分支，修复的提交更应该是单独一个 commit 。 |
 |
3
asd7160 2025 年 6 月 16 日 via iPhone 1
要。如果发现修改有误，要撤回某个修改的话，混在一起会很麻烦
|
 |
4
z1645444 2025 年 6 月 16 日 1
分开提交，理由同 #1
|
 |
5
prosgtsr 2025 年 6 月 16 日 via iPhone 1
分开，我甚至会开发完一个功能 commit 一次，同事说我是他见过 commit 最多的人….
如果公司有要求的话我会在 push 之前先把 commit rebase 成一个，没有要求的话我就直接 push |
 |
6
hwdq0012 2025 年 6 月 16 日 1
哪怕是同一个文件的两行代码，只要是不同功能，最好分两次，不过实际上很多 code style ，或是无关紧要的随手修改，我都懒得多提交
|
 |
7
xzchsia 2025 年 6 月 16 日 1
一般一个功能的修改作为一次提交，如果不属于一个功能的最好分两次提交。。
|
 |
8
540852101 2025 年 6 月 16 日 1
分开提交，方便 review, 也方便以后追溯
|
 |
9
peasant 2025 年 6 月 16 日 2
分开最好，但是并不是所有人都愿意这么麻烦，甚至 commit msg 都不想写，比我我现在这家公司的项目，日志里大量的“无”、“bug 修改”、“修改”。
|
 |
10
davin 2025 年 6 月 16 日 1
个人倾向于“小步快跑”，一堆功能塞进一个 commit ，之后万一要撤回重新修改的话，没那么多麻烦事儿
|
 |
11
FringJX 2025 年 6 月 16 日 1
正常是分开提交。
但实际实践中都是懒得，一股脑提交然后 commit message 写上「一大波代码优化」，完事。 |
 |
12
Foxalone 2025 年 6 月 16 日 1
看你自己. 建议分开.
|
 |
13
aqtata OP 定了，分开多次提交
|
 |
14
guanzhangzhang 2025 年 6 月 16 日 1
人都是会犯错的，不相关的就不要 rebase 成一个 commit ，如果是单独一个功能，开发的时候可以多个 commit 到自己分支上再 rebase 成一个写清楚 commit 信息，推送后再提 merge 。
这样后续有问题回退也简单，即使我请假了，别人也能 revert ，而不是打电话喊我回退哪些 |
 |
15
luckyjack 2025 年 6 月 16 日
必须分开啊，不过道理都懂，实际做的时候随机应变（狗头
|
 |
16
leokun 2025 年 6 月 16 日
有多少人真的分两次提交的
|
 |
17
COOOOOOde 2025 年 6 月 16 日
惭愧, 我甚至有 code sync 这种 comment 的提交
 |
 |
18
Rat3 2025 年 6 月 16 日
分开，反正又 copilot 去写 msg
|
 |
19
MonikaCeng 2025 年 6 月 16 日 via iPhone
commit 分开
pr 合一起 |
 |
20
xfn 2025 年 6 月 16 日
应该分开提交。但实际上就像写文档一样，不喜欢别人不分开提交，不喜欢自己分开提交
|
 |
21
cwliang 2025 年 6 月 16 日
分开，fix bug 和 update config 本来就是不相干的东西，掺一起的话，commit msg 怎么写？后面怎么追溯？
rebase 到一次的场景：对于 fix bug 有多次提交，可以合一起。或者对于 update config 有多次提交合一起 |
 |
22
unco020511 2025 年 6 月 16 日
看你们的工作模式了,我们这里功能分支 mr 到主干基本都是要求 squash 的,所以如果你这两个改动本来就是一个需求产生的,那对于主干来说是无所谓的.
|
 |
23
intmax2147483647 2025 年 6 月 16 日
|
 |
24
Vindroid 2025 年 6 月 16 日
分开，合一起 commit 不好写，其次能混个提交量
|
 |
25
ddczl 2025 年 6 月 16 日
分开
|
 |
26
abelmakihara 2025 年 6 月 16 日
自己预想一下会不会 release 的时候不一起发
如果真的是会一起升级的或者小项目无所谓的就一起 commit 呗 如果是比较严格的功能 那肯定是要分开的 |
 |
27
yuchen198 2025 年 6 月 16 日
如果是小公司，只有自己开发的话无所谓，时间紧急的情况下，十几个文件一次 commit 也不是不行...时间充足的话，还是分开吧，尤其是配置文件和基础库，单独 commit 还是挺好的
|
 |
28
vikaptain 2025 年 6 月 16 日 17
你问我的话就是分开提交。
你让我干的话就是一起提交。 |
 |
29
jackOff 2025 年 6 月 16 日
分开提交，否则出问题时你就等着在一个提交里屎里淘金吧
|
 |
30
realpg PRO 如果项目只有我自己 改个缩进我都 commit
如果项目是协同 那么 除非紧急运维 bugfix 什么都开分支 而且开多个 dev 的分支按功能提交 dev+name 的 改个缩进都提交 |
 |
31
94 2025 年 6 月 16 日
按照好管理的角度来说分开提交。但是是不是所有的都要分开提交按具体情况，是不是相关联的修改，或者团队是否有 PR 、MR 要 squash 的规则。
但实际上就算要 squash 一个分支上面的 commit 也都是相关功能的修改，不会把很多不相关的功能调整串在一个分支上面。。 |
 |
32
pigfloyd 2025 年 6 月 16 日
一直同步提交
|
 |
33
Oilybear 2025 年 6 月 16 日
按照常理来说就是分开提交
|
 |
34
flytsuki 2025 年 6 月 16 日
别人的话最好分开提交,我方便看.我自己的话可能 n 多改动一起提交
 |
 |
35
runlongyao2 2025 年 6 月 16 日
可以不分，但是要写清楚，修改文件和需求的对应关系
|
 |
36
crysislinux 2025 年 6 月 16 日 via Android
就两行，分开是不可能分开的，这辈子都不可能分开。
|
 |
37
zhaol 2025 年 6 月 16 日
我知道分开提交是对, 但是现实我懒得搞, 直接一起提交了
|
 |
38
gaocc 2025 年 6 月 16 日
看大部分都是提分开提交。
实际情况，大伙还是小厂多吧，一个项目就一个开发，甚至一个开发维护多个项目，来回都一个人。 这种情况分开和一起提交，意义不大。后期换人也不会关心这种提交记录。 假如大厂，多人维护一个产品，有分开的意义。但前提很多，比如这个功能没有其他人同步开发，不然混杂开发，即使考虑回退，多一个 commit 也太大意义。 |
 |
39
siteshen 2025 年 6 月 16 日
@prosgtsr 我是一个功能提交一次，但数量正好相反，我的 commit 是最少的（即使需要 review ，我也会自己 rebase ）。
有些需要多次发布后才能调试，我甚至还可能在调试完毕后 rebase 成一个 commit ，和同事确认后 push -f 。 ps: 后端开发，代码管理员权限 |
 |
40
ClaudeCode 2025 年 6 月 16 日
理论上和现实还是很大区别的
上面给建议的，估计也没多少能遵循这个原则 |
 |
41
NotAfraidLP 2025 年 6 月 16 日
强迫症一般分开:
一个 commit 是 [fix] 前缀, 一个 commit 是[chore] 前缀 |
 |
42
litchinn 2025 年 6 月 16 日
分开提交，方便 revert ，cherrypick 等操作
|
 |
43
catamaran 2025 年 6 月 16 日
@NotAfraidLP 又学了一个单词
|
 |
44
jydeng 2025 年 6 月 16 日
分开，方便 pick
|
 |
45
GuluMashimaro 2025 年 6 月 16 日
有责任心就分开，随便整的话随便都可以。
 |
 |
46
tonytonychopper 2025 年 6 月 16 日
按照功能来分，revert 或者 cherry pick 都很方便
|
 |
47
CoderChan 2025 年 6 月 16 日
commit 太多 rebae 处理冲突时麻烦（ merge 没有问题）
|
 |
48
lucifer9 2025 年 6 月 16 日
如果贵公司的 KPI 会参考 commit 数量...
|
 |
49
iOCZS 2025 年 6 月 16 日
对外教育：原子性提交要分开
对内实战：一股脑提交多省事 |
 |
51
TimPeake 2025 年 6 月 16 日
你就看我的 gitlab 活动面板颜色深不深就完事儿了
 |
 |
52
jiangzm 2025 年 6 月 16 日
颗粒度不需要太细，如果是常规开发过程中的就一起提交，commit 信息哪个重要写哪个或者写两个一起
如果是线上问题修复就不要搭车提交，分开提交比较好 ，如果有 bug 单号 在 commit 中加上 方便追踪。 |
 |
53
cvooc 2025 年 6 月 16 日
除非敏捷开发阶段每天动一堆文件, 否则我是建议分开提交, 回滚都不是重点, 主要很久以后回忆起来, 预览改动方便一次性了解改动地方, 不然一堆文件在一块短时间你真不一定能分出来当时改动了哪些问题
|
 |
54
shiny PRO 分开
你顺便还可以 code review 一次，自己给自己 review 也是很有帮助的 |
 |
55
veightz 2025 年 6 月 16 日 via Android
都行的，详细一点更好，可以 merge master 的时候合并下 commit
|
 |
56
HENQIGUAI 2025 年 6 月 16 日
改动都比较小的话， 一起提交就行了，message 就写“fix: A & B”
|
 |
57
Jessun 2025 年 6 月 16 日
能分为什么不分？
合着在一起提交唯一的优点就是：省那一两分钟时间？ 分开的优势：commit 历史清晰，便于 revert 。 |
 |
58
wolfie 2025 年 6 月 16 日
一次提交，两行 commit 。
|
 |
59
MIUIOS 2025 年 6 月 16 日
说是这么说，可真操作起来你们连 commit 内容都懒得写
 |
 |
61
kingsword09 2025 年 6 月 16 日
分开好点，楼上大佬们说的理由
|
 |
62
wangtian2020 2025 年 6 月 17 日
两行还分，两行我不提交只暂存
一行一日志那就是没有日志，你分几百个 commit 谁会去看啊？ |
 |
63
RJH 2025 年 6 月 17 日
分开提交都说方便 revert ，实际情况是反向改一下搞定
|
 |
64
CathayChen 2025 年 6 月 17 日
我想问在座的有一年能有几次 revert
|
 |
65
YYYeung 2025 年 6 月 17 日
多一个 commit 毫无成本可言，当然是分开提交
|
 |
66
PeiXyJ 2025 年 6 月 18 日
 ) |
 |
67
encounter2017 2025 年 6 月 18 日
@CathayChen 25 次，咋了
$ git log --oneline | Select-String -Pattern "revert|Revert" | Measure-Object | Select-Object -ExpandProperty Count 25 |
 |
68
wymisgod 2025 年 6 月 18 日 1
理论：最好是分开 commit ，message 标注清楚修改内容，最好是带上项目管理工具需求/缺陷等相关编号以便复盘
现实：一把梭哈，message：一些修改 |
Select Language