两处修改需要分开提交吗？

[aqtata]

一处功能性修改，比如 bug （ 1 行代码）

一处配置文件修改（ 1 行代码）

两处修改是不相干的

要分开提交吗？

背后的问题是大家提交习惯是按照进度一次提交（有点备份的意思），还是按照功能细分提交（日志会很多）？

[cwliang]

分开，fix bug 和 update config 本来就是不相干的东西，掺一起的话，commit msg 怎么写？后面怎么追溯？
rebase 到一次的场景：对于 fix bug 有多次提交，可以合一起。或者对于 update config 有多次提交合一起

[unco020511]

看你们的工作模式了,我们这里功能分支 mr 到主干基本都是要求 squash 的,所以如果你这两个改动本来就是一个需求产生的,那对于主干来说是无所谓的.

[intmax2147483647]

@leokun
理论上如评论区：分开提交！这样更改内容清晰，好回退
实际上：老夫管你这么多，卡卡卡一把梭

[Vindroid]

分开，合一起 commit 不好写，其次能混个提交量

[ddczl]

分开

[abelmakihara]

自己预想一下会不会 release 的时候不一起发
如果真的是会一起升级的或者小项目无所谓的就一起 commit 呗
如果是比较严格的功能 那肯定是要分开的

[yuchen198]

如果是小公司，只有自己开发的话无所谓，时间紧急的情况下，十几个文件一次 commit 也不是不行...时间充足的话，还是分开吧，尤其是配置文件和基础库，单独 commit 还是挺好的

[vikaptain]

你问我的话就是分开提交。
你让我干的话就是一起提交。

[jackOff]

分开提交，否则出问题时你就等着在一个提交里屎里淘金吧

[realpg]

如果项目只有我自己 改个缩进我都 commit
如果项目是协同

那么 除非紧急运维 bugfix 什么都开分支 而且开多个

dev 的分支按功能提交
dev+name 的 改个缩进都提交

[dfkjgklfdjg]

按照好管理的角度来说分开提交。但是是不是所有的都要分开提交按具体情况，是不是相关联的修改，或者团队是否有 PR 、MR 要 squash 的规则。
但实际上就算要 squash 一个分支上面的 commit 也都是相关功能的修改，不会把很多不相关的功能调整串在一个分支上面。。

[pigfloyd]

一直同步提交

[Oilybear]

按照常理来说就是分开提交

[flytsuki]

别人的话最好分开提交,我方便看.我自己的话可能 n 多改动一起提交

[runlongyao2]

可以不分，但是要写清楚，修改文件和需求的对应关系

[crysislinux]

就两行，分开是不可能分开的，这辈子都不可能分开。

[zhaol]

我知道分开提交是对, 但是现实我懒得搞, 直接一起提交了

[gaocc]

看大部分都是提分开提交。
实际情况，大伙还是小厂多吧，一个项目就一个开发，甚至一个开发维护多个项目，来回都一个人。
这种情况分开和一起提交，意义不大。后期换人也不会关心这种提交记录。

假如大厂，多人维护一个产品，有分开的意义。但前提很多，比如这个功能没有其他人同步开发，不然混杂开发，即使考虑回退，多一个 commit 也太大意义。

[siteshen]

@prosgtsr 我是一个功能提交一次，但数量正好相反，我的 commit 是最少的（即使需要 review ，我也会自己 rebase ）。

有些需要多次发布后才能调试，我甚至还可能在调试完毕后 rebase 成一个 commit ，和同事确认后 push -f 。

ps: 后端开发，代码管理员权限

[yaocai321]

理论上和现实还是很大区别的
上面给建议的，估计也没多少能遵循这个原则