合并commit的必要性

开发的过程中，我们会提交很多次代码，生成很多commit，比如修改了a文件，又修改了b文件，然后又把a文件改回之前的版本等，commit history中会有很多的无价值的commit，如果把这些commit直接合到master，会导致master的commit history不清晰，有太多的细节和无意义的commit。

如果push或合并分支之前，有意识地把commit合并一下，只留下一个或几个有意义的commit，那么再查看commit history的时候，会清晰很多，回滚的时候也更容易定位commit。

##如何合并commit

合并多个commit可以使用 git rebase 这个命令。分为两步，

第一步，确定合并范围

在项目根目录，启动命令行，输入 git rebase -i，从当前commit开始合并，指定一个要合并到的commit，通过HEAD^^的方式（^的数量就是commit的数量），或者简写成HEAD~x，还可以指定要合并到的commit的前一个commit的id，两者之间就是合并的范围。

第二步，删除、保留、合并commit

确定了范围之后就开始处理了，输入git rebase -i以后会进入 合并commit的界面，

如图列出的就是要处理的commit，每行代表一个，具体的操作如下：

删除某一行代表删掉这个commit， 使用列出的命令代表保留该commit， pick是单独保留这个commit， reword是单独保留这个commit，但是重新编辑commit message， squash代表和前一个commit合并，commit message保留， fixup代表和前一个commit合并，commit message丢弃。 常用的就这四个。

合并的过程中如果遇到冲突，解决后需要git add ，然后 git rebase --continue，如果想中止，使用 git rebase --abort。

处理完commit，解决完冲突，合并就结束了，你会发现commit history整洁了很多。

总结

合并commit是保持commit history整洁的必要操作。

可以在push或者合并分支之前使用git rebase -i 进行合并，合并范围的确定需要指定一个边界commit，使用HEAD^^ 或者HEAD~x或者commitId来指定。

确定范围之后合并的方式有很多，可以保留或者删除，保留的话可以使用pick、reword、squash、fixup等命令来合并到前一个或者单独保留。遇到冲突需要解决冲突之后continue。

就这简单的两步，使用git rebase -i 来管理的commmit history，使之更加整洁。