GitKraken Desktop12.4.1

GitKraken Desktop 的配置重点不是先把所有集成打开，而是先固定仓库、分支和远程，再逐层启用 Commit Graph、冲突工具、Worktree 和 Agent Sessions。官方当前稳定版为 12.4.1（2026-09-02），支持 Windows、macOS 和 Linux，但不同平台的架构、发行版和高级功能条件并不相同。本文按“安装—连接—提交—冲突—协作—回退”安排配置顺序。

安装前先对照平台与方案

基础 Git 与高级集成要分层

基础仓库、分支、提交和差异操作不要求预先安装 Git 命令行；需要嵌入式终端、Git LFS、实验性工具或脚本时，再安装并固定 Git 版本。私有仓库、Issue 集成、Profiles、Cloud Patches 和部分团队能力受方案限制，先按实际需求核对授权。

第一次连接远程仓库

1. 打开或克隆：先选择本地仓库或远程提供商，确认仓库根目录和保存位置。
2. 连接账号：在 Preferences 的 Integrations 中连接 GitHub、GitLab、Bitbucket 或 Azure DevOps，账号登录与仓库推送权限分别确认。
3. 核对远程：查看 origin URL、默认分支和认证方式，企业自托管服务还要检查域名、PAT 或 SSH。
4. 建立基线：先 Fetch，再记录当前分支、未提交改动和最近一次成功同步的提交。

如果团队使用自托管 Git 服务，先确认服务器证书、代理和个人令牌范围。不要为了让列表出现仓库而复制来源不明的令牌，也不要把令牌写进提交、Issue 或截图。

用 Commit Graph 建立分支基线

Commit Graph 适合回答“当前分支从哪来、哪些提交已经合并、还有哪些工作未同步”。配置时先把图谱当作观察工具，再执行创建分支、合并或回退。

提交前把一个节点变成可复查结果

从 WIP 进入 Commit Panel 后，先排除日志、密钥、构建产物和无关格式化，再按任务暂存文件或代码块。提交消息要说明变化和原因；提交后明确判断是否需要 Push，而不是把本地节点当作远程备份。

冲突处理要经过完整闭环

1. 先确认冲突来自哪两条分支、共同基线是什么。
2. 在 Merge Tool 中逐段选择或编辑最终内容，不要盲目接受一侧。
3. 标记文件已解决后，查看完整 Diff 和冲突标记残留。
4. 运行项目要求的测试、格式检查或构建，再提交合并结果。
5. Push 前重新确认目标远程和 Pull Request 范围。

Diff、File History 和 Blame 用于解释变化来源，不能替代编译和测试。AI 生成提交消息或冲突建议时，仍要逐段审查，敏感代码和密钥不要提交给未经批准的外部服务。

Worktree、Agent Sessions 与团队权限

12.4.1 的更新包含 Worktree tab groups 和 Codex Agent 状态展示。它们适合把并行工作放到不同目录中观察，但不会替团队决定代理能访问哪些凭据、谁可以合并或哪些检查必须通过。

• 为每个任务记录 worktree 路径、分支、负责人和清理时机。
• 启用 Agent Sessions 前，先限定允许的目录、命令、网络和凭据范围。
• 在 Pull Request 合并前审查代理生成的提交、文件差异和测试结果。
• Profiles 适合分开个人与企业 Git 配置；切换前确认当前 Profile 和远程身份。

基础版、Pro 和 On-Premise 不要混写

Git LFS、终端与平台数据目录

需要终端、实验性 Git 工具或 LFS 时，按官方建议安装 Git CLI，并让 GitKraken 与命令行使用同一仓库和远程。Windows 用户数据通常位于 %APPDATA%\.gitkraken，macOS/Linux 位于用户目录下的 .gitkraken；迁移或清理前先备份设置和仓库状态。

• 大型仓库先确认 LFS、代理和凭据，再判断是扫描慢还是网络慢。
• WSL 场景按官方限制配置路径，不要把 Windows 与 Linux 两套 Git 状态混在一个目录。
• 更新后先测试打开仓库、查看图谱、提交和 Push，再恢复复杂集成。

升级后按症状回退

升级前记录版本、Git CLI、远程提供商、Profile 和关键扩展；在非关键仓库验证后再推广到团队设备。