Git commits历史是如何做到如此清爽的?

今天在看vue源码时随手看了一下commit历史,然后就被震惊了。请问这是怎么做到的?怎样的git实践才能做到这么清爽?
关注者
1021
被浏览
124784

27 个回答

多用 rebase

---

我真是服了贵乎了,楼下居然有人能从 commit 风格看出我爱慕虚荣,哈哈哈哈,只能说这葡萄是很甜了

我 rebase 纯粹是因为我不喜欢 git log --graph 的时候一堆 branch 扰乱视线。另外,难道你不知道 rebase 不一定要 squash 的?

Vue作者已经放出了权威答案,我也在这补充一下自己平时的git workflow。在开发一个feature或者修个bug的时候,一般都会在最终要merge进的分支上开个新的分支,所有的工作都commit到这个新的分支上。feature写完或者bug修完,在要merge之前,rebase新分支到最后要merge的分支上,这相当于把你在新分支上的所有新commit依次cherry pick到要merge的分支的最新commit后面,这样后续的merge就一定会是一个非常爽的fast forward。而且在rebase的同时可以进行squash,把逻辑上相似的commit都塞到一个commit里面,然后给他一个描述性比较强的commit message。这套操作下来之后commit历史会非常清晰一目了然,看某些同事的项目的commit历史里面各种save, save work, fix bug, fix bug again的确是一种煎熬,好的commit应该反映出一个项目是怎么一步步开发下来的,是软件开发的航海日志,黑匣子,任何码农都应该建立良好的commit习惯。

Linus曾经在Linux的某个pr下面讨论了好的commit应该长啥样,非常有启发: Add support for AR5BBU22 [0489:e03c] by WNeZRoS · Pull Request #17 · torvalds/linux