保持Git历史整洁

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

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

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

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

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

1	`git rebase`

代替

1	`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，主要有两种办法处理：

在idea的提交框或者通过命令都可以进行，相当于改写最后一次提交，这样可以保证我们修改了多次，但是只有一条提交记录

直译为压缩多个commit
这两个有什么优缺点呢：

git commit –amend一个已经push的commit会很麻烦，之前我写的一篇文章关于不要push -f的里面用过这个命令。一旦push，同时被小伙伴拉到他本地，你在改写历史，就会造成你这里的树和远程仓库树结构不一致，最终还会生成一个merge commit，除非进行push -f，但是只是解决推送的问题，小伙伴那里估计就要骂人了。
个人认为git merge –squash是比较完美的方案，虽然繁琐了一点点。大概步骤如下：
建立一个临时分支→一顿操作搞事情→返回正式分支进行合并→正常提交。
1）建立临时分支

2）切换到临时分支进行搞事情

可以看到这四个提交可能是我们无意识的进行的提交，比如调试，改个配置文件啥的，这实际上没有什么特殊意义，下面我们就要请出来squash命令进行优化了。
3）切换到原分支
这里我切回master（尽量不要再master搞事情，这里仅供展示）

这个命令会把对应分支的文件，改动到当前分支工作区中，且处于未提交状态：

4）优雅的提交吧
写个高逼格的commit message吧，这样就把上面4个合并成了一个commit

以上就是我最近处理需求的一个小技巧，这样我可以正常提交，随时提交，而不用担心提交了一半，不能推送、commit message不知道咋写等问题。