使用 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 和签名，这个是算出来的）。