使用 git 的时候，大家喜欢用很多小 commit 还是用很少的大 commit？

[gowl]

我自己喜欢用很多细小的 commit ，但我注意到一些天才型的工程师喜欢用大 commit：）

[yikyo]

一定是小的，代码有问题需要排查回滚定位，用 git 二分查哪次递交的问题，你用大 commit 就做不来

大 commit 合到主分支的这种情况不算

[zhenjiachen]

同意用 mr 后 squash 成为一个大的 commit ，使用 mr 的合并并且 squash ，squash 后还可以在 mr 中看到一个个小的 commit 。这样主分支很清爽，也能通过 commit 看到是哪个 mr 的提交

[billzhuang]

小步 commit ，merge 时 squash 。

一个 feature 一个 commit ，要不然就拆 feature 。

[IvanLi127]

@silentsky rebase 会这样就不合理啊，除非做的比较低层，性能要求不足以很好地让源代码工程化，不然不至于疯狂冲突

[charlie21]

有一些 commit 是做在 git repo 里，有一些 commit 是做在自己心里

如果是为了给别人看到，只在 “专门邀功请赏” 色彩的地方做 commit 。之前在自己心里的 commit 直接写在纯私人工作日志里了

-

哈哈。工作日志是啥？就是上一次能 1 小时解决问题这一次用 1 分钟能解决的原因和背后的秘密的所在 / 保存的地方

[julyclyde]

phabricator
就是会把多个 commit 合并为一个，再增加上它自己的附属信息，然后再合并给主分支

在小分支上的多个 commit 的历史其实就只能去网页（其实是另一个单独保存 review 的 repo ）上看了

[dengji85]

学到了，我一直头疼主分支提交记录太乱了了

[superliy]

我刚入行的时候带我的大姐姐说过，详细的 commit 能让领导知道你在做事

[yogogo]

我只要修改就提 commit ，生怕老板不知道我在做事

[wlfeng]

开发分支写完一个功能 commit 一次，累计一堆再提交，万一哪天代码丢了或者盘坏了哭都哭不出来；整体需求开发完成后再合并到生产分支；

[zhchyu999]

小 commit 快跑
另外谁后合并谁尴尬

[baiyi]

提交尽量保证原子性原则，也就是一次提交是尽可能少量且不可分割的整体。好处就是 code review 更加简单，代码更容易回滚，更易于追踪变化等等。——《 Pro Git 》
合入主干可以用 squash ，这样能够保证主干 commits 信息更加清晰，有利于项目整体性进度追踪。

[Liam1997]

我一般是一个新的 feature 新建一个分支，为了防止后续合并解决冲突麻烦，中途会暂时 commit 一次，然后 rebase 一下最新的主分支，再 reset 一下，最后一个 feature 一个大的 commit 提交。

如果是 bugfix 当然就是小 commit 了。

[nekoneko]

feature 分支多个小 commit, 合并前合成一个大 commit.
dev 分支和 master 分支随时提交小 commit

[xiaonizi]

自从上次看到运维统计月度 commit 量的截图后，我尽量分多次 commit😬

[RICKEYGONG]

下班前必 commit