06 · 合并、变基与冲突

状态：✅ 已实现 · 范围：v1 · 工程参考：../spec.md

合并（Merge）

把当前分支变基到…——任选 ref；脏工作树会先自动 stash（完成后恢复）。
交互式 rebase——入口在提交图（右键某提交 → "自此交互式 rebase"）或分支选择器：
- 列表编辑器逐行显示将要重放的提交。行操作：pick / reword / edit / squash / fixup / drop（行内按钮）。
- 拖动某行的手柄调整顺序，也可以用该行的上移 / 下移按钮——按钮保留是为了让计划能纯键盘操作。拖拽时会有一条线标出该行落位的地方。
- 变基过程中，操作横幅提供 Continue / Skip / Abort；停在 edit 行相当于暂停——amend 或执行命令后 Continue。
两种 rebase 都在后台执行、不阻塞窗口；整段 Git 输出进入 Output 面板，提交图在变基结束或停下时刷新。

Cherry-pick——从提交图或提交详情面板入口：一次一个提交，也可以 Ctrl/Cmd 点选多行，把整份选区一次拣完；对话框按实际执行顺序列出提交（最早的在前）。可选 --no-commit（变更进入暂存区，先不提交）。在界面上直接给出 A..B 区间为 [Later]。
Revert——入口与选项同上，单个或整份选区；批量 revert 从最新的提交开始撤销，否则较早的变更会重新出现。revert 合并提交需选择主线（对话框会解释哪个 parent 是哪个）。
冲突走同一套横幅流程。批量操作时，Skip 跳过让它停下的那个提交，继续执行队列里剩下的。

右键某提交 → "把当前分支重置到此处"：

模式	行为
Soft	仅移动分支指针；index 与工作树不动（改动保持已暂存）。
Mixed	移动分支指针；重置 index；改动留在工作树（未暂存）。
Hard	全部重置——工作树改动会丢失。需确认；对话框会点名将被丢弃的提交，且会先创建 backup ref。

操作因冲突停下时（merge、rebase、cherry-pick、revert）：

仓库分节顶部与提交图中出现操作横幅：Continue / Skip / Abort，以及未解决文件数的实时计数。
Conflicts 组（第 03 页）列出冲突文件。对每个文件：
- Ours / Theirs / Both 解决操作，
- 在编辑器中打开（带语法高亮的冲突标记），
- 在外部合并工具中打开——命令可在设置中配置（如 Beyond Compare、WinMerge、KDiff3）。
已解决的文件可标记（"标记为已解决"，或暂存时自动标记）。
Continue 前会校验：若仍有未解决文件，弹窗列出清单，而不是让 Git 中途失败。
Abort 精确恢复操作前状态；Skip（rebase/cherry-pick）跳过当前提交。

stash apply/pop 冲突是例外：它不会开启一个操作，因此没有横幅。stash 记录保留，冲突文件带着标记留在工作树，并有一条提示说明发生了什么（第 07 页）。

内置编辑器显示标准冲突标记（<<<<<<<、=======、>>>>>>>），边栏提供 采纳 ours / 采纳 theirs / 全部采纳 操作。完整的三方合并编辑器为 [Later]。

每个破坏性操作之前——reset --hard、rebase（含交互式）、历史改写、stash drop、删除分支、强制删除 worktree——GitTreeDesk 都会在 refs/gitreedesk/backup/… 下创建backup ref，指向即将被替换的状态。backup ref 不出现在常规分支/tag 列表中。
操作完成后，toast 提供 Undo（恢复 backup ref）。之后仍可从仓库右键菜单 → "从备份恢复…" 找回，列表显示每次备份的操作、时间与目标 ref。
备份/撤销历史同时记录在该仓库的操作日志中（Output 面板）。

有进行中的操作时，GitTreeDesk 会拦截与之冲突的操作（例如 merge 中发起 rebase），弹窗解释原因并给出合法的下一步动作（先 continue / 先 abort）。