1 基本概念
1.1 定义
变基是一种用于整理版本历史的操作，常见于 Git 等分布式版本控制系统。它的核心做法，是将一系列已有提交移动到新的基底之上，使这些提交看起来像是在另一个起点之后依次产生。通过这种方式，提交记录可以被重新组织，从而获得更整齐的历史结构。
1.2 术语与背景
理解变基，通常需要先掌握几个基础概念。它们构成了提交历史、分支演化以及历史重写的基本框架，也是变基能够正常工作的前提。
1.2.1 提交
提交是版本控制中的一个记录单元，保存了某一时刻项目文件的状态以及相关说明。多个提交按时间和关系连接起来，便形成可追踪的开发历史。变基的对象通常就是这些提交。
1.2.2 基底
基底指某组提交所依附的起点，也可以理解为后续修改建立在其上的参考位置。变基时，系统会把原本基于旧基底的提交，重新放到新的基底之后，以建立新的历史链条。
1.2.3 分支
分支是指从某个提交节点出发形成的独立开发线路。它允许不同任务并行推进。变基经常用于调整分支与主线之间的关系，使分支内容更平滑地接入目标分支。
1.3 变基的核心目标
变基的主要目标通常包括三类：其一是让历史更线性，便于阅读和追踪；其二是重新排列或整理提交，使每个提交更具独立意义；其三是在不改变最终代码结果的前提下，优化提交序列，提升维护与审查效率。
2 工作原理
2.1 提交重放机制
变基的本质，是把一组提交的改动逐个“重放”到新的起点上。系统会先找到原分支与目标基底之间的差异，然后按顺序复制这些变更，在新的位置重新生成提交。由于每个新提交都基于新的父提交，因此历史链条会被重新构建。
2.2 历史改写
因为重放过程中生成的是新的提交对象，变基会改变提交哈希，并重写原有的历史结构。原先那条分支上的提交并不会原地移动，而是被替换成一组新的提交记录。也正因为如此，变基属于会影响历史的操作，而不是单纯追加记录。
2.3 与合并的区别
变基和合并都能把不同开发线路的内容整合到一起，但两者处理历史的方式不同。合并倾向于保留分支分叉与汇合的痕迹，而变基更强调重写路径，使历史看起来连续、简洁。
2.3.1 线性历史
使用变基后，提交记录通常呈现为一条连续直线，看上去像是所有更改都按顺序完成。这种结构便于回溯问题，也更容易在代码审查时逐个理解修改内容。
2.3.2 合并提交
合并常会生成一个专门的合并提交，用来记录多个分支的汇合点。这个提交能够保留分支关系，但也会让历史分叉更明显。相较之下，变基通常不会保留这种额外节点。
3 常见类型
3.1 交互式变基
交互式变基允许用户在重放提交之前，对提交序列进行编辑。它常用于整理本地历史，是变基功能中最灵活的一类。
3.1.1 修改提交顺序
在交互式模式下，用户可以调整提交排列顺序，使相关修改更集中，逻辑更清楚。比如先补基础改动，再放置依赖于这些改动的后续提交。
3.1.2 拆分提交
有时一个提交包含了多个不相关的修改，交互式变基可以将其拆分为若干更小的提交。这样做有助于提高每个提交的可读性，也便于后续审查与回溯。
3.1.3 合并多个提交
交互式变基也支持将若干连续提交合并为一个提交，减少历史噪音。对于频繁的修补性提交或反复调整的中间结果，这种整理方式尤其常见。
3.2 变基到远程分支
这种用法是将当前分支基于远程跟踪分支的最新状态进行变基。它常出现在本地开发分支需要跟进主线更新时，目的是把本地改动放到远程分支最新提交之后。
3.3 变基到指定提交
变基也可以直接指定某个提交作为新基底，将当前分支上的若干提交整体迁移到该位置之后。此类操作常用于重构分支起点，或整理一段较长开发过程中产生的历史。
4 典型使用场景
4.1 清理本地提交历史
开发者在本地工作时，经常会产生调试性提交、临时修补提交或重复尝试的记录。提交前使用变基整理这些内容，可以让最终历史更紧凑，也更符合正式提交的要求。
4.2 同步主分支更新
当主分支持续推进，而功能分支仍在开发中时，变基可将功能分支重新建立在主分支最新提交之上。这样可以减少后续集成时的差异，使功能分支更接近最终合入状态。
4.3 为代码审查整理提交
在提交审查前，开发者常会把零散提交整理成更清晰的逻辑单元。经过变基后，审查者可以按顺序查看每一步变化，减少在大量临时记录中寻找真正改动的成本。
4.4 整合功能分支改动
当一个功能分支包含多阶段开发结果时，变基可以帮助将这些结果按合理顺序串联起来。对于需要保留开发脉络但又希望历史简洁的场景，这种方式很实用。
5 常用命令与参数
5.1 基本命令格式
在 Git 中，变基通常以 rebase 命令完成。基本形式一般是指定目标基底，再让当前分支的提交重新附着其上。实际语法会因场景不同而变化，但核心思路始终是“重新放置提交”。
5.2 常见选项
变基命令通常配合若干参数使用，用来控制交互方式、指定基底或处理冲突过程。
5.2.1 --interactive
--interactive 表示交互式变基。它会在执行前打开编辑界面，让用户决定提交的保留、排序、拆分或合并方式，适合精细整理历史。
5.2.2 --onto
--onto 用于指定新的基底。它可以把某一段提交从原位置转移到另一个起点之后，是变基中很常用的定向操作参数。
5.2.3 --continue
当变基过程中出现冲突并被手动解决后，--continue 用于继续后续重放流程。它表示当前冲突已经处理完毕，可以进入下一步。
5.2.4 --abort
--abort 用于中止变基并恢复到操作前状态。若发现整理结果不符合预期，或冲突处理过于复杂，这个选项可以快速撤销本次变基尝试。
5.3 常见工作流示例
常见工作流包括：先在本地开发功能，再通过交互式变基清理提交；或者在合并前，将功能分支变基到主分支最新版本，确保历史整齐且冲突更早暴露。对于多人协作项目，通常会在推送前完成这些整理步骤。
6 风险与注意事项
6.1 冲突处理
变基在重放提交时可能遇到冲突，尤其是当新基底与原分支修改了相同文件区域时。冲突解决后，往往需要继续执行后续步骤，因此整个过程比普通追加提交更需要耐心。
6.2 提交哈希变化
由于变基会生成新的提交对象，原提交的哈希值会随之改变。这意味着原先引用这些提交的链接、记录或讨论内容，可能需要更新。对于依赖具体哈希的场景，这一点尤为重要。
6.3 协作中的使用规范
在多人协作中，已经共享给他人的分支通常不宜随意变基。因为历史被改写后，其他成员若基于旧版本继续开发，可能会出现同步困难。一般来说，变基更适合本地尚未广泛发布的提交整理。
6.4 强制推送的影响
如果变基后的分支已经与远端历史不一致，往往需要强制推送才能覆盖旧记录。此类操作会改变远程分支的历史视图，若使用不当，可能给协作者带来额外处理成本，因此需要谨慎确认时机与范围。
7 相关概念
7.1 合并
合并是把两个分支的改动结合到一起的常见方式，通常保留分支汇合痕迹。它与变基相对，强调记录分支关系，而不是重写历史线索。
7.2 挑拣提交
挑拣提交是指把某一个特定提交的改动单独应用到当前分支。它与变基不同，通常不搬运整段历史，而是提取单个变更。
7.3 分叉点
分叉点是两个分支从同一祖先提交开始分离的位置。它是判断分支关系、选择变基起点或分析历史演化的重要参照。
7.4 头指针与游离状态
头指针用于指向当前检出的提交或分支位置。游离状态则指头指针不附着于某个分支名的情况。在变基或历史整理过程中，这些概念常与当前工作位置的变化相关。
8 应用实践
8.1 开源项目中的使用
在开源项目里，变基常被用于在提交前整理补丁序列，使维护者更容易阅读每次变更。由于开源协作参与者较多，项目往往更强调提交粒度清晰、历史整洁，因此变基经常出现在贡献流程中。
8.2 团队开发中的策略
团队中通常会对变基的适用范围作出约定，例如只允许对个人开发分支进行整理，不建议改写已共享分支。配合统一的提交规范，变基可以帮助团队保持较一致的历史风格。
8.3 自动化工具支持
许多开发工具和持续集成流程都能识别变基后的提交变化，并帮助检查冲突、展示差异或校验提交信息。一些脚本化工具还可以自动完成分支整理，提高重复操作的效率。
8.4 图形化客户端中的变基功能
不少图形化客户端提供拖拽式或菜单式的变基操作，降低了命令行门槛。用户可以通过可视化界面查看提交排列、调整顺序并处理冲突，适合不习惯直接输入命令的开发者。