git 只commit不push 会有影响吗_如何保持Git历史整洁

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

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

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

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

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

这个标准的git-flow工作流开发模式分支图，分支多且各种merge，但是逻辑很清晰。另外像master分支这种，一般是不允许直接提交commit的，只能通过pull request的方式进行合并代码，也就必须生成相应的merge commit。

所以要定义下什么是不整洁的提交历史。

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

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

• feature分支下过多无用commit

这是我博客(https://wangqianying.com)的源代码项目中的一些commit历史(https://github.com/happut/fei/commits/master)你问我当时想啥呢，我也不知道。哈哈，反正就是脑子热，在跟travis较劲，不停地改、调试，最后终于通过了构建。这些commit是一直在改配置文件，提交的时候也懒得改提交信息了，就一直走的上一条提交记录，其实没啥大影响，但是总感觉怪怪的，出现在独立的调试的分支里还好，出现在master分支中，总感觉不那么清晰。

• feature下无用的merge commit

这类我暂时没找到图，大家可以理解下。一般我们有几个固定分支：master, develop等，我们开发新需求的时候会拉取一个新需求的分支，然后在上面进行开发，例如从 develop派生出一个 feature/new-xxx的分支，但是一般一个分支有多个人进行开发，多个人开发的时候如果没有进行及时的push/pull，自己在pull的同时就会生成一个merge commit，历史分支图就会出现一个分叉。（不是说不对，也挺好的，能看出自己和别人的一些工作）。

如何避免

针对上面两项问题，引出对应的避免办法。

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

• git commit --amend

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

但是，一个已经push的commit进行amend会很麻烦，之前我写的一篇文章关于不要push -f的里面用过这个命令。一旦push，同时而且已经被小伙伴拉到他本地，你在改写历史，就会造成远程仓库的树结构和他本地的树结构不一致，合并的时候会自动生成一个merge commit。而且由于本地和远程仓库不一样，也无法直接进行push操作，除非进行push -f，如果你执行了push -f，小伙伴那里估计就要骂人了。

• git merge <分支名> --squash

squash直译为压缩多个commit。

个人认为 git merge <分支名> --squash是比较完美的方案，虽然繁琐了一点点。大概步骤如下：
建立一个临时分支→一顿操作搞事情→返回正式分支进行合并→正常提交。
1）建立临时分支(派生自你的feature分支，且不推送到远程仓库)

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

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

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

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

以上就是我最近处理需求的一个小技巧。

这样我进行一个拿不准、或者只是调试功能、无意义的改动，都可以正常提交，随时提交，而不用担心提交了一半，不能推送、commit message不知道咋写等问题，确定功能没问题后，进行相应的修正，产生一条有意义的commit在feature分支上，这样可以减少大量的无用commit message历史，增加可读性。

针对第二种，减少feature分支下无用的merge commit，目前的可用的最优的办法就是代码不要直接就git pull，实际上git pull=git fetch+git merge。如果想保留树结构，要先git fetch，再git rebase。

总结

善用 git merge <分支名> --squash，不过还要提一句，git commit历史不是多就不好就不好，相对的多个commit如果message清晰，能更大的增加可读性，还是鼓励多提交，这样一旦回滚，能迅速地找到当时的那个commit。这里只是压缩一些无用的无营养的commit。