1

3

分开，revert 的时候方便，commit msg 也比较清晰

2

1

小公司，会发现大部分人确实都是这 2 种习惯其中之一。
我更倾向于分开提交，尤其是修改的类型已经不一样的。
尤其是修复的，如果有多分支，修复的提交更应该是单独一个 commit 。

3

1

要。如果发现修改有误，要撤回某个修改的话，混在一起会很麻烦

4

1

分开提交，理由同 #1

5

1

分开，我甚至会开发完一个功能 commit 一次，同事说我是他见过 commit 最多的人….
如果公司有要求的话我会在 push 之前先把 commit rebase 成一个，没有要求的话我就直接 push

6

1

哪怕是同一个文件的两行代码，只要是不同功能，最好分两次，不过实际上很多 code style ，或是无关紧要的随手修改，我都懒得多提交

7

1

一般一个功能的修改作为一次提交，如果不属于一个功能的最好分两次提交。。

8

1

分开提交，方便 review, 也方便以后追溯

9

2

分开最好，但是并不是所有人都愿意这么麻烦，甚至 commit msg 都不想写，比我我现在这家公司的项目，日志里大量的“无”、“bug 修改”、“修改”。

10

1

个人倾向于“小步快跑”，一堆功能塞进一个 commit ，之后万一要撤回重新修改的话，没那么多麻烦事儿

11

1

正常是分开提交。
但实际实践中都是懒得，一股脑提交然后 commit message 写上「一大波代码优化」，完事。

12

1

看你自己. 建议分开.

13

定了，分开多次提交

14

1

人都是会犯错的，不相关的就不要 rebase 成一个 commit ，如果是单独一个功能，开发的时候可以多个 commit 到自己分支上再 rebase 成一个写清楚 commit 信息，推送后再提 merge 。
这样后续有问题回退也简单，即使我请假了，别人也能 revert ，而不是打电话喊我回退哪些

15

必须分开啊，不过道理都懂，实际做的时候随机应变（狗头

16

有多少人真的分两次提交的

17

惭愧, 我甚至有 code sync 这种 comment 的提交

18

分开，反正又 copilot 去写 msg

19

commit 分开
pr 合一起

20

应该分开提交。但实际上就像写文档一样，不喜欢别人不分开提交，不喜欢自己分开提交

21

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

22

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

24

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

25

分开

26

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

27

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

28

17

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

29

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

30

31

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

33

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

34

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

35

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

36

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

37

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

38

39

40

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

41

强迫症一般分开:
一个 commit 是 [fix] 前缀,
一个 commit 是[chore] 前缀

42

分开提交，方便 revert ，cherrypick 等操作

44

分开，方便 pick

47

commit 太多 rebae 处理冲突时麻烦（ merge 没有问题）

48

如果贵公司的 KPI 会参考 commit 数量...

49

对外教育：原子性提交要分开
对内实战：一股脑提交多省事

50

@siteshen 我也是, 这样 git log 看上去, 更加规整

51

你就看我的 gitlab 活动面板颜色深不深就完事儿了

52

颗粒度不需要太细，如果是常规开发过程中的就一起提交，commit 信息哪个重要写哪个或者写两个一起
如果是线上问题修复就不要搭车提交，分开提交比较好 ，如果有 bug 单号 在 commit 中加上 方便追踪。

53

除非敏捷开发阶段每天动一堆文件, 否则我是建议分开提交, 回滚都不是重点, 主要很久以后回忆起来, 预览改动方便一次性了解改动地方, 不然一堆文件在一块短时间你真不一定能分出来当时改动了哪些问题

54

分开
你顺便还可以 code review 一次，自己给自己 review 也是很有帮助的

55

都行的，详细一点更好，可以 merge master 的时候合并下 commit

56

改动都比较小的话， 一起提交就行了，message 就写“fix: A & B”

57

58

一次提交，两行 commit 。

59

说是这么说，可真操作起来你们连 commit 内容都懒得写

62

两行还分，两行我不提交只暂存
一行一日志那就是没有日志，你分几百个 commit 谁会去看啊？

63

分开提交都说方便 revert ，实际情况是反向改一下搞定

64

我想问在座的有一年能有几次 revert

65

多一个 commit 毫无成本可言，当然是分开提交

66


67

68

1

理论：最好是分开 commit ，message 标注清楚修改内容，最好是带上项目管理工具需求/缺陷等相关编号以便复盘
现实：一把梭哈，message：一些修改