利用Sourcetree交互式变基优化Git本地提交历史

1. 为什么你需要整理Git提交历史？

不知道你有没有过这样的经历：花了一周时间开发一个新功能，每天下班前都习惯性地 git commit -m "WIP" 保存一下进度。一周下来，本地仓库里堆了十几个提交记录，什么“修复了一个小bug”、“又改了点样式”、“临时保存一下”。等到功能终于做完，准备推送到远程仓库时，看着这一长串杂乱无章的提交历史，自己都觉得不好意思。更头疼的是，如果你的团队有代码审查（Code Review）文化，这样的提交历史会让你的同事看得一头雾水，根本搞不清楚你每一步到底做了什么，为什么要这么做。

这其实就是我们日常开发中非常典型的一个场景。现代软件开发，尤其是敏捷开发模式下，我们经常需要在多个任务间快速切换。可能你正在写用户登录模块，突然线上报了一个紧急的支付bug，你得马上切到热修复分支去处理。处理完回来，原来的思路可能都断了，为了“保住”当前的修改，很多人（包括我）的第一反应就是先提交到本地分支再说。久而久之，本地分支上就留下了一堆“半成品”提交。这些提交单独看都有意义，但合在一起，却破坏了提交历史的原子性和可读性。原子性指的是一个提交应该只做一件事，并且这件事是完整的；可读性指的是别人（或者未来的你）通过阅读提交信息，就能清晰地理解代码的演进脉络。

提交历史混乱带来的问题远不止“不好看”这么简单。首先，它会让 git bisect（一个用于定位引入bug的提交的神器）变得几乎无法使用。想象一下，你要在几十个“WIP”提交里定位一个功能回归点，无异于大海捞针。其次，在需要回滚（revert）某个特定功能时，你不得不去手动挑选哪些提交属于这个功能，操作复杂且容易出错。最后，也是最重要的，混乱的历史不利于团队协作和知识传承。清晰的提交历史本身就是一份宝贵的项目文档，它记录了“我们为什么这样写代码”。

所以，在将本地工作推送到远程共享仓库之前，花点时间整理一下提交历史，是一项非常值得的、也是专业开发者必备的“家务活”。而 交互式变基（Interactive Rebase），正是做这件事最强大的工具。今天，我就结合我最常用的Git图形化客户端——Sourcetree，来手把手教你如何用它的交互式变基功能，把一堆琐碎提交“美化”成一条清晰、整洁的记录。

2. 认识我们的工具：Sourcetree与交互式变基

在深入操作之前，我们得先搞清楚两件事：Sourcetree是什么，以及交互式变基到底在干什么。我知道很多朋友习惯用命令行操作Git，觉得更酷、更高效。我最初也是命令行党，但后来发现，在可视化历史记录和进行一些复杂历史操作时，像Sourcetree这样的图形化工具能提供无与伦比的直观性。它能让你“看见”你的分支和提交，这对于理解变基这种会改变历史记录的操作尤为重要，能大大降低操作失误的恐惧感。

Sourcetree 是Atlassian公司出品的一款免费Git图形化客户端，支持Windows和macOS。它的界面非常清晰，中间是提交历史图谱，左边是分支和标签列表，下面可以查看文件变更。我们今天核心要用的功能，就藏在对提交记录的右键菜单里。

那么，交互式变基 又是什么呢？你可以把它想象成一次对提交历史的“剪辑”或“重组”。普通的 git rebase 是把当前分支的提交“挪动”到另一个分支