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