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

[gowl]

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

[wangkun025]

也许，他们是合并过的 commit

[ql562482472]

squash ！

[dzdh]

我习惯切个新分支，在这个分支上很多小 commit ，然后切成一个大 commit 重新切个分支然后在 merge 到主干分支。

[gowl]

追一个问题：如果是自己的项目，有必要以丢失信息为代价去 squash 么？

[gowl]

@dzdh 你会保留所有的“试验性”分支么？

[silentsky]

我喜欢大 commit ，一般都是一个需求一个 commit

[renmu]

我一般都是下班前一个 commit （笑

[silentsky]

搞那么多 commit ，冲突合并都费劲

[zjp]

开发分支完成一版就提交，还会有一些小修复的提交
合并主干时用 squash ，基本一个需求一个提交

[typing]

随心所欲 commit 。我一般把 commit 当“保存”用。

但 PR 之前：fixup 所有临时 commit ，reset ，add -p ，以基本逻辑为单位 commit ，写正经的 commit message

[biabia123456]

@typing #10 你可以试试 rebase 没必要 reset 万一操作失误就尴尬了

[lslqtz]

分支上小 commit, 最后整合成大 commit 合并到主线

[darkengine]

@silentsky 大 commit 处理冲突才是噩梦

[IvanLi127]

用小的，当然也不会太小，大概一个功能点一个。
前段时间喜欢把几个合成一组组比较独立的功能块，不过现在都 mr 到主干，也懒得再合了。。
我感觉人不是很多的情况下细点就细点。大的 commit ，回撤还麻烦

[IvanLi127]

@silentsky 反对，如果 commit 多会导致合并时一直冲突，那是项目设计有问题，任务分配也有问题，技术和非技术上都有问题才会这样。

[silentsky]

@IvanLi127 我指的是 rebase

[hst001]

大小都有，看情况，原则是如果要对 commit 执行 git revert 时尽量安全，或者影响尽可能少

[hackpro]

@typing #10 问个弱智的问题
已经 commit 的 lig history 还能修改吗？

[msg7086]

「有必要以丢失信息为代价去 squash 么」

丢失信息要看丢失的是有效信息还是无效信息。
比如你做一个网页表单，每加一个文本框就提交一次，一个页面 20 个框交了 20 个 commit ，这就是无效信息。这种 squash 了一点都不心疼。
但是如果你做一个功能，要改数据库结构要改页面，那你数据库结构交一次，页面交一次，就很合适。

[msg7086]

@hackpro Git 你可以当作一个数据库，里面任何一个东西都可以修改（除了 hash 和签名，这个是算出来的）。

[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 快跑
另外谁后合并谁尴尬

[FinnBai]

提交尽量保证原子性原则，也就是一次提交是尽可能少量且不可分割的整体。好处就是 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