GitHub Desktop 3.6 带来 Worktree：并行分支与 Copilot 冲突处理怎么用

GitHub Desktop 3.6 的变化不只是多了一个版本号：它把 Git worktree、Copilot 辅助提交信息和合并冲突处理放进了同一套桌面流程。对经常在 hotfix、功能分支和代码代理工作区之间来回切换的人来说，最直接的收益是不用反复暂存改动，也不用为每个分支再克隆一份仓库。

GitHub Desktop 3.6 到底更新了什么

GitHub 官方在 2026 年 6 月 26 日的 Changelog 中把 3.6 的变化归纳为三条线：更可控的 Copilot 提交信息、Copilot 辅助的合并冲突处理，以及 Git worktree 支持。3.6.0 已提供 macOS 和 Windows 版本，Copilot 相关能力需要相应的 Copilot 使用权限。

这几个能力放在一起有一个明显的工作流逻辑：worktree 负责把分支隔离开，提交信息规则负责让变更说明保持团队格式，冲突辅助则负责在分支重新汇合时减少人工定位成本。它们不是互相替代的 Git 命令，而是把原本分散在终端、编辑器和仓库规范文件里的动作集中到桌面客户端。

先用 worktree 拆开并行分支

假设主仓库目录正在处理一个未提交的功能改动，同时线上出现一个需要快速修复的 issue。旧习惯通常是先 stash，再切到 hotfix，修完后切回并恢复暂存内容。Git worktree 的思路是给 hotfix 建一份关联工作目录，两个分支各自拥有文件状态，但共享同一个 Git 对象库。

git worktree add ../project-hotfix hotfix/login-timeout
git worktree list

# 在独立目录完成修复后回到主仓库
git -C ../project-hotfix status
git -C ../project-hotfix switch hotfix/login-timeout

在 GitHub Desktop 3.6 中，顶部的 Current Worktree 菜单可以查看主 worktree 与 linked worktree，并创建新的 worktree。命令行仍然值得保留，因为 git worktree list 能快速确认目录、分支和关联关系，适合写进团队检查脚本。

Copilot 处理冲突时，人工要盯住哪三件事

发生冲突后，Desktop 可以解释冲突双方的改动并给出候选解决方式。这个功能降低的是“看懂冲突”的门槛，不代表可以跳过代码审查。建议把候选结果当成一个待复核的补丁，而不是自动合入的结论。

1. 先看冲突范围：确认冲突两边分别解决什么问题，尤其留意配置、权限和数据库迁移。
2. 再看结果差异：接受候选改法后，用 diff 检查是否误删了另一分支中的校验、日志或错误处理。
3. 最后跑验证：至少完成项目现有的单元测试、格式检查和构建；涉及接口时再补一条真实请求或回归用例。

如果冲突跨越多个模块，或者两边都改了同一个业务规则，Copilot 的解释只能帮助定位，不应代替熟悉领域的开发者做最终判断。

提交信息规则开始影响桌面协作

3.6 的提交信息生成会读取仓库中的 .github/copilot-instructions.md、AGENTS.md，也会遵守仓库定义的提交元数据规则。团队可以把提交标题长度、关联 issue 的格式、是否必须包含变更范围等要求写进这些文件。

# .github/copilot-instructions.md
- 标题使用动词开头，控制在 72 个字符以内
- 说明影响范围，不编造测试结果
- 涉及 issue 时使用 Closes #编号

这里的价值不在于让每条提交信息都由模型生成，而在于把“什么算合格说明”变成仓库里的可见规则。没有规则文件时，开发者仍应手动检查标题是否准确，避免把猜测写成已经完成的验证。

从旧工作流迁移时的边界

最稳妥的试用顺序是先升级一台非关键开发机，再为一个短生命周期分支创建 worktree。观察目录是否容易遗留、团队是否能理解当前 worktree、冲突结果是否能通过现有测试，确认这些问题后再把规则文件纳入正式仓库。

常见问题：GitHub Desktop 3.6 适合马上升级吗

没有 Copilot 订阅，Worktree 还能用吗？

可以。Git worktree 是 Git 本身的能力，GitHub Desktop 3.6 的 worktree 管理不等于必须启用 Copilot；只有 Copilot 辅助提交和冲突相关能力需要相应权限。

Worktree 会复制一整份仓库吗？

不会按普通 clone 的方式复制全部对象库。它创建关联工作目录并共享 Git 对象，但每个目录仍有独立的检出文件和分支状态。

Copilot 生成的冲突结果能直接提交吗？

不建议直接提交。应先查看 diff，确认两边的业务意图都被保留，再运行测试、构建和必要的接口回归。

团队已经习惯命令行，需要改用 Desktop 吗？

不需要强制替换。可以让 Desktop 负责可视化的 worktree 和冲突浏览，把 git worktree list、测试与 CI 保留为统一验收入口。

GitHub Desktop 3.6 的重点是把“并行分支—冲突复核—提交规范”串成一个更短的桌面路径。真正值得迁移的不是某个按钮，而是把 worktree 的目录边界、Copilot 的复核责任和仓库规则一起纳入团队工作流。