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