本文首发于 http://www.YoungZY.com/



关键字/keyword: rebase, fixup



最近在读《重构》，作者建议“小步快走”，即每完成一个“小”功能就提交（commit）一下。 这样会有一个小问题：提交记录中会有很多无意义的提交。

当然多个小提交本身不会造成什么问题或bug，但会显得繁琐无重点。VCS工具（如git）提供了一种合并提交的功能：rebase + fixup。

准备

当前有几个commit（尚未push）如下：“commit test 1”, “commit test 2”, “commit test 3”, “合并commit的测试示例”，如下图：

合并前的commit



注：为了方便说明，以每次的commit message代替commit本身。

开始合并

• 工具栏 – VCS – Git – Rebase



注意：这里的 “Onto” 必须选择远程的（remotes），即服务器端的，而不是你本地的。



• 点击 Rebase 按钮





这里的顺序是调整过的，通过左下角的三角。初始顺序是提交的顺序 1-2-3-4 。但是如果你把第一条的 Action 改为 fixup ，它会提示你错误。所以需要把最终你需要提交的那条放在第一个。

• 点击 Start Rebasing 

如果你是改的同一个文件，会有一些 Merge 操作。之后会看到成功的提示。

这时再去 Log 里看，commit 只剩一条了。





• PUSH

Push到服务器上（这里是GitHub）之后，commit 也是一条。





• DONE

演示完成。

其实在开发的过程中也可以使用这种方法：某个功能开发完成了一小部分，大致确定没问题后就可以commit。这样的话，如果做下一步实现时，发现原本的解法行不通，就可以直接对整个项目回滚，而不用在众多的文件中一个个地不停地“Ctrl+Z”了。再退一步讲，连上一个commit都是错的，那还是可以回滚的。只要还没push过，都好说。

个人也比较喜欢这种方式。完成一部分便commit。就像编辑过程中不停地“Ctrl+S”一样。

Squash VS Fixup

其实 squash 也可以完成同样的操作。而且从词义上讲，本就有“压缩”的意思，感觉比 fixup 更合适。

它们之间的区别：前者会将被压缩那条的commit message附加到前一条上面；而后者会直接忽略被压缩那条的message。

详细的可以参考文末链接。

参考

• squash 和 fixup 的区别

• IntelliJ IDEA | Edit project history by performing interactive rebase



阅读原文