@
dcsuibian #19
这两种观点并不是完全冲突的。
保留历史的细节程度和历史的尺度有关。比如说你遇到了生产事故,需要写事故处理记录,你当然要把每一分每一秒每一次事件都记录下来。但如果你是在写上下五千年的史书,那会有人关心你某一天下午 2 点的时候打翻了一杯水吗。
我司在开发的比较大的项目,尺度基本是上下十年,一个工程师一个月交两个功能,一个 team 下 50 个人一个月就是 100 个功能,一年 1200 个,十年 12000 个,假如平均实现一个功能有 10 个提交,那就是 12 万个提交,你光是要查两三个月前某个提交的 bug 就得翻不知道多少页才能找到,就非常不方便。这还是 master 分支,你要再加上 release 分支测试分支就更多了。所以我们要求所有合并到主线的提交都是 squash merge 。开发分支提 PR 的时候随便你多少个提交,最后全合一起。
如果是小项目,比如说 one man 项目或者一个 team 里两三个人协作,那可以把提交做得细一点,合并 feature 分支的时候用 merge commit 就没问题。
记录实际发生过什么这个也是有粒度的。严格来讲,每一次输入删除都是一次更改,但你肯定不会觉得每打一个单词都要提交吧。那么到底打多少个单词才需要提交一次呢,删了多少代码才需要提交一次呢。这个粒度把控,不同的人也有不同的观点的。