Magit 中的变基
Source: Hacker News
Source: …
您的指挥中心：git log
我通过先调用 Magit（绑定在 F3）然后按 lL 打开日志：
l– 与日志相关命令的前缀。L– 显示 所有 本地分支以及它们跟踪的远程分支的日志。
探索更复杂的日志命令
如果在第一个 l 之后暂停，Magit 会为每个可用选项显示不显眼的提示：
因为提示始终存在，我们不必记住确切的标志。下面是几个逐步构建高级日志的示例。
| 目标 | 按键 | Magit 显示的内容 |
|---|---|---|
| 限制特定作者 | -A | 显示所有仓库作者的模糊匹配列表。输入作者姓名（例如 kqr）并回车。 |
| 限制日期范围 | =u | 显示日历视图（也可以手动输入日期）。示例：2025‑06‑01。 |
| 显示文件 diffstat | -s | 启用 --stat 标志。 |
| 限制子目录 | -- 然后 tests 回车 | 将日志限制在 tests/ 目录下的文件。 |
| 包括所有分支及远程分支 | b | 添加 --branches --remote。 |
| 图形视图，带颜色、装饰且不显示合并提交 | (默认已启用；用粗体/高亮标志表示) | --graph --color --decorate --no-merges。 |
把这些片段组合起来，完整的按键序列（␍ = 回车）是：
l -A kqr ␍ =u 2025-06-01 ␍ -s -- tests ␍ b虽然看起来很长，但我们是通过查看提示一步步构建的。经过几次练习，这个序列会变成第二天性——既 可发现 又 高效。
等价的 Shell 命令
git log --branches --remote --author=kqr --until=2025-06-01 \
--graph --color --decorate --no-merges --stat -- testsMagit 在日志提示中会显示这条完整的命令，因此我们无需翻回手册页去核对实际执行的内容。
为什么这很重要
有些人担心使用交互式界面会削弱命令行技能。Magit 刻意保持透明：每一次操作都会显示底层的 Git 命令，鼓励你在享受快速、可发现的 UI 的同时学习 CLI。
虽然本文出现在关于 rebase 的文章中，但 Git log 是理解仓库历史的基石。在 Magit 中，日志是 交互式 的，使其成为日常 Git 工作的理想“指挥中心”。
Source: …
从日志进行变基
提醒一下，这是我们之前使用的视图：
我们想把 profiling-of-test-suite 分支变基到 optimise-company-name-generation 上。当前分支是 optimise（用蓝色框标出）。
步骤
-
检出
profiling分支
将光标放在profiling分支上（它被灰色高亮），然后按bb⏎- 第一个
b= checkout（检出） - 第二个
b= branch（分支） - 模糊匹配列表默认是光标所在的分支，直接敲 Enter 即可切换到
profiling。 - 蓝色框会移动到
profiling分支，表示检出成功。
- 第一个
-
变基到
optimise
将光标移回optimise分支，然后按re⏎r= rebase（变基）e= elsewhere（即不是上游，而是别的目标）- 模糊匹配列表再次默认光标所在的提交，确认即可敲 Enter。
提示： 如果不确定该输入什么，只需键入首字母，Magit 会给出提示。
加上-i（例如re -i⏎）会启动 交互式 变基。 -
结果
日志会更新，显示profiling分支现在位于optimise之上。
交互式变基（可选）
如果需要更复杂的变基，启动交互式变基 (re -i⏎)。Magit 会展示一个可编辑的提交列表，并提供便捷的快捷键：
| 键 | 操作 |
|---|---|
k | 丢弃该提交 |
f | Fixup（压缩但不保留提交信息） |
w | 重写提交信息 |
s | Squash（与前一个提交合并） |
| … | …（在提交列表下方可看到所有支持的操作） |
在变基过程中你也可以创建新提交或合并提交，尽管这类需求并不常见。
它刚刚做了什么？
如果我们想知道 Magit 执行了哪个命令，可以按 $，就会出现 Magit 命令日志，其中列出了 Magit 运行的每个 Git 命令。在本例中，它会显示：
git checkout profiling-of-test-suite
git rebase --autostash optimise-company-name-generation…嗯，--autostash 是什么，为什么 Magit 默认使用它？我们来查阅 man git-rebase：
--autostash
在操作开始前自动创建一个临时的 stash 条目，并在操作结束后应用它。这意味着你可以在工作树脏的情况下执行 rebase。不过，需要小心使用：在成功的 rebase 之后最终应用 stash 可能会导致冲突。
好的，这作为默认设置是有道理的。我经常在工作树脏的情况下进行 rebase，能够自动处理 stash 真是太方便了。
这又是 Magit 教会我们更好使用 Git 的一种方式。如果不是 Magit 默认使用 --autostash，我可能根本不会知道它的存在。它也是我了解到 --force-with-lease 明显优于 --force 的途径，尽管很少有人知道这点。
其他 Git 界面 {#other-git-interfaces}
这并不是一个复杂的操作。我们本可以通过 Git 命令行完成它；那会非常简单——事实上，我们刚才已经看到 Magit 在底层执行的两个命令。通过在交互式 Magit 日志视图中执行 rebase，我们能够更直观地理解这些命令到底在做什么。当我们对 Magit 熟悉之后，就可以开始运行更复杂的命令，而不必担心在缺乏明确、交互式展示的情况下执行它们会缺乏信心。
当然，还有其他图形化的 Git 界面，我们完全可以使用它们来完成这次 rebase。但我们不会像使用 Magit 那样，对 Git 本身有如此深入的了解。
Magit 正好位于解决方案空间的完美位置：它本质上是 Git 命令行的一个轻量包装，并且对此毫不掩饰。与此同时，它为命令行增添了交互性、可发现性和效率，这些特性在其他地方很难找到。
我们在这里仅仅看到了它威力的一瞥——等你真正体会到 Magit 如何轻松地让我们交互式地暂存、取消暂存、恢复或重置文件、代码块，甚至代码块的部分内容时，你会更加惊讶。