保持Git历史整洁

很久没整理学习的内容了，今天正好一直在用一段命令，就想着拿出来写一篇博客。

Q: 什么样的git历史算整洁的？

A: 首先，这个问题就是一个很主观的问题。

有的人认为git历史整洁的话应该减少merge commit，整体看着是线性的，且没有多余的commit。

要保持这种结构，最常见的方式就是使用：

git rebase

代替

git merge

但是这种会丢失一些信息，比如不知道当前是从哪里派生出来的，不便于排查问题等等，而且merge commit多不一定就是乱，比如下面这个算不整洁吗？

这个标准的git-flow工作流开发模式分支图，分支多且各种merge，但是逻辑很清晰。

另外像master分支这种，一般是不允许直接提交commit的，只能通过pull request的方式进行合并代码。

如何定义不整洁的提交历史呢？

我们可以看一些著名的开源项目的提交历史和自己的项目进行比较，从我个人角度分析有两种情况：

• 过多无用commit 这是我博客的源代码项目中的一些commit历史(https://github.com/happut/fei/commits/master)你问我当时想啥呢，我也不知道。哈哈，反正就是脑子热，在跟travis较劲，不停地改、调试，最后终于通过了构建。 这些commit其实没啥大影响，但是总感觉怪怪的，出现在调试的分支里还好，出现在master分支中，总感觉不那么清晰。
• 无用的merge commit 这类我暂时没找到图，大家可以理解下。一般我们有几个固定分支：master,develop等，我们开发新需求的时候会拉取一个新需求的分支，然后在上面进行开发，例如从develop派生出一个feature/new-xxx的分支，但是一般一个分支有多个人进行开发，多个人开发的时候如果没有进行及时的push/pull，自己在pull的同时就会生成一个merge commit，历史分支图就会出现一个分叉。（不是说不对，也挺好的，能看出自己和别人的一些工作）

如何避免

针对第一种，过多无用的commit，主要有两种办法处理：

• git commit --amend 在idea的提交框或者通过命令都可以进行，相当于改写最后一次提交，这样可以保证我们修改了多次，但是只有一条提交记录
• git merge --squash 直译为压缩多个commit 这两个有什么优缺点呢：

1. git commit --amend一个已经push的commit会很麻烦，之前我写的一篇文章关于不要push -f的里面用过这个命令。一旦push，同时被小伙伴拉到他本地，你在改写历史，就会造成你这里的树和远程仓库树结构不一致，最终还会生成一个merge commit，除非进行push -f，但是只是解决推送的问题，小伙伴那里估计就要骂人了。
2. 个人认为git merge --squash是比较完美的方案，虽然繁琐了一点点。大概步骤如下： 建立一个临时分支→一顿操作搞事情→返回正式分支进行合并→正常提交。 1）建立临时分支 2）切换到临时分支进行搞事情 可以看到这四个提交可能是我们无意识的进行的提交，比如调试，改个配置文件啥的，这实际上没有什么特殊意义，下面我们就要请出来squash命令进行优化了。 3）切换到原分支 这里我切回master（尽量不要再master搞事情，这里仅供展示） 这个命令会把对应分支的文件，改动到当前分支工作区中，且处于未提交状态： 4）优雅的提交吧 写个高逼格的commit message吧，这样就把上面4个合并成了一个commit      以上就是我最近处理需求的一个小技巧，这样我可以正常提交，随时提交，而不用担心提交了一半，不能推送、commit message不知道咋写等问题。

第二种，目前的可用的最优的办法就是代码不要直接就git pull，实际上git pull= git fetch+ git merge。所以要先git fetch，再git rebase。

总结

善用git merge --squash，不过还要提一句，git commit历史不是说上面的就不好，相对的多个commit如果message清晰，还是鼓励多提交，这样一旦回滚，能迅速地找到当时的那个commit。这里只是压缩一些无用的无营养的commit。