GitButler
GitButler
官网
GitButler 是一个 Git 客户端，但它的思路和传统 Git GUI 不太一样。它不是简单给 Git 命令套一层界面，而是想把我们平时最别扭的那部分流程重新做一遍。
它最吸引我的地方，是把“几组改动同时整理”这件事做得更直观。你可以在一个工作目录里先把改动分开，再分别提交、推送、开 PR，不用老是切来切去。
为什么值得推荐
我觉得 GitButler 值得写进工具清单，主要是因为它很贴现在这种并行开发环境。大家越来越常同时推进几件事，可能是多个分支、多个 PR，也可能是你自己加上一个或几个 agent 一起干活。git worktree 会越来越流行，本质上也是在解决这个问题。
GitButler 和 worktree 不是一回事，但方向很像：尽量减少上下文切换，把并行开发这件事整理得更顺。
它最强的地方还是 Virtual Branches。很多原本要靠 stash、切分支、挑 commit、交互式 rebase 才能完成的整理动作，在 GitButler 里会直观很多。对那些很在意提交质量、PR 干净度、review 体验的人来说，这个差别会特别明显。
GitButler 怎么用
如果你主要用桌面端，我觉得可以按这个顺序上手。
1. 先接仓库，再确认 target branch
打开仓库之后，先确认 target branch。一般就是 main 或者 master。这一步挺关键，因为 GitButler 后面很多分支整理、同步上游的动作，都是围绕这个基准分支展开的。
2. 先写代码，再整理改动
这是 GitButler 比较不一样的地方。很多时候你可以先写代码，等改动出来之后，再把它们分配到不同的 virtual branch 里。这个思路和传统 Git 很不一样，但一旦习惯了，会觉得很省脑子。
3. 把不同任务分到不同 lane
如果你同时改了两个问题，比如一部分是功能，一部分是 bugfix，就把它们分到不同 lane 里。这样后面提交、推送、开 PR 都更干净。
4. 提交前集中整理历史
GitButler 很适合在提交前做最后一轮整理：
- 哪些改动应该 absorb 到已有 commit
- 哪些 commit 应该 squash
- 哪个提交信息要改
这个阶段它的体验通常比命令行 Git 轻松很多。
5. 最后再推送和开 PR
分支整理干净之后，再推送、开 PR。这样到代码托管平台上看历史，会舒服很多，不容易出现“逻辑是一个，提交是另一回事”的情况。
特色功能
下面这些功能，我觉得最能体现 GitButler 和普通 Git 工具的差别。
1. Virtual Branches 和 Stacked changes
一个适合并行改动，一个适合有前后依赖关系的多层提交。这两套加在一起，基本就覆盖了现在很常见的两类开发场景。
2. Absorb
修 review feedback 时特别好用。你补的那一点点改动，可以直接吸收到旧 commit 里，不用自己手搓 amend + rebase。
3. Undo / Uncommit
GitButler 很适合“反悔”。提交如果拆错了、顺序不对，或者你突然想换一种组织方式，回退起来比原生 Git 轻松很多。
4. Split / Squash / Reorder
拆提交、合并提交、重排顺序，这些正是 Git 最容易让人烦躁的部分。GitButler 把它们做成了常规操作。
5. Edit Mode
你可以直接进入某个 commit 的编辑状态，只改这一层，再把上面的内容自动 rebase 回去。拿来处理 review 意见特别顺。
6. Upstream sync 和 conflict handling
主分支更新后，GitButler 可以把上游变化重新整合进当前 workspace。遇到冲突时，它更像是在帮你继续整理工作，不是一下把你扔进传统 Git 的冲突泥潭里。
GitButler CLI
GitButler 现在不只是桌面应用，也已经有了自己的 CLI。官方文档里提到，桌面端那套并行分支、stack 管理、diff、提交编辑、冲突处理、上游同步、forge 集成，CLI 里也都能覆盖，而且可以直接跑在 terminal、脚本和 agents 里。
这对现在的开发环境很重要。因为很多人的工作流已经不是“只点 GUI”或者“只敲 Git 命令”了，而是桌面工具、终端、AI agent 混着用。GitButler 把这条线补齐之后，用起来就顺了很多。
如果你更常待在终端里，可以顺手看看它的 but 命令。
一个很常见的 CLI 用法
可以先记住这一组最基础的流程：
# 看当前状态
but status
# 新建一个分支
but branch new fix-login
# 提交当前改动
but commit -m "fix: login redirect"
# 推送这个分支
but push
这套命令的好处是比较顺。你不用一边脑补现在在哪个分支，一边想 stash 了什么、有没有切回来。先看 but status，再开分支、提交、推送，节奏很清楚。
常用命令
but status：看当前工作区、已应用分支、未整合的上游提交but branch new：新建分支but commit：提交改动，也支持直接指定文件或 hunkbut push：推送当前分支，或统一推送还有未推送提交的分支but diff：看改动细节but reword等提交编辑能力：改提交信息、整理提交顺序
几个很有辨识度的命令
真正让 GitButler CLI 和普通 Git 拉开差距的，是下面这些命令。
but rub
这是 GitButler CLI 里最特别的命令之一。官方的定义很有意思，就是把两个东西“揉”在一起做操作。
比如：
- 把文件 rub 到 branch 上，相当于分配改动
- 把 commit rub 到另一个 commit 上，相当于 squash
- 把文件 rub 到 commit 上，相当于 amend
这套思路一开始会有点陌生，但理解之后会觉得很统一。
but absorb
这个命令就是把新改动吸收到已有 commit 里。对日常修 review、补 fixup 来说很顺手，比手动 amend + rebase 更直接。
but commit empty
这个也很有意思。它可以先插一个空 commit，再慢慢把改动填进去。官方文档里甚至明确提到 ，这有点像 Jujutsu 那种先建提交骨架、再往里装内容的工作流。
如果你本来就习惯先想清楚提交结构，再慢慢把改动放进去，这个命令会很好用。
but mark
mark 用来创建自动分配或自动提交规则。这个能力很适合重复性的工作流，比如某类文件默认进某个 branch，或者某些改动按固定方式处理。
but oplog 和 but undo
这两个组合我很喜欢。oplog 看操作历史，undo 回退上一步。GitButler 不只是给你一个结果，还会保留一条比较像“操作时间线”的东西，这让人更敢动手整理历史。
but pick
这个命令可以把 unapplied branch 里的 commit 拿到当前的 virtual branch 里，有点像更贴 GitButler 模式的 cherry-pick。
but teardown
如果你想退出 GitButler 这套管理模式，回到普通 Git branch 工作流，可以用这个命令。这个细节也挺重要，因为 GitButler 的 virtual branch 模式本来就不是原生 Git 的默认思路。
官方 文档里有一点我比较认同：CLI 不是“桌面版的缩水替代”，而是可以直接接进脚本或 agent 工作流里的。
适合谁
- 想少写一点复杂 Git 命令的人
- 经常需要整理提交、拆 PR、做 stacked changes 的人
- 已经开始频繁使用
worktree、多分支、多任务并行工作流的人 - 一边开发一边频繁切换任务的人
- 对 Git 概念理解没问题，但不喜欢命令行交互细节的人
一个很现实的建议
GitButler 不一定能完全替代命令行 Git，但很适合当日常主力工具。
如果你经常遇到这些场景：
- 功能开发过程中顺手拆出一个 bugfix
- 混在一起的改动需要重新整理成多个 PR
- 提交前要反复清理历史
- GUI、CLI、AI agent 混着用
那 GitButler 值得认真试一阵。