简介：面向 Ubuntu 16.04 及以上系统的开发者，这份 GitKraken v6.5.1 安装包提供了图形化 Git 客户端的完整运行环境，适合希望减少命令行操作、同时清晰掌握分支与提交历史的中初级开发者，也是免费版最后一个可长期留存的迭代版本。压缩包共 97 个文件、约 101.9MB，以 pak 多语言资源包、node 运行时模块、so 动态链接库、bin 可执行文件与 sh 启动脚本为主，另含 asar 应用归档及 Electron 相关支撑组件；解压后即可按原有目录结构启动，无需额外编译。软件覆盖多面板仓库视图、三向合并冲突解决、提交前差异预览、分支创建切换与重命名，并可直接对接 GitHub、GitLab、Bitbucket 完成推送、拉取与审查请求。目前已有 2426 人学习下载，对需要在旧版 Ubuntu 上稳定使用 GUI 工具的读者具备实际参考价值。
1. GitKraken 6.5.1 Ubuntu 版：命令行看不见的那部分，它替你画出来
在 Ubuntu 上天天敲git log --graph --oneline --all，早晚会碰到一个场景：三条分支交叉在一起，你想看清楚某个提交到底从哪切出去、这次合并冲突的三方版本分别长什么样、rebase 之后历史被揉成了什么形状。GitKraken 6.5.1 的 Ubuntu 版解决的就是这件事——它把仓库画成一张可以拖拽的提交图，分支、标签、暂存区、冲突三方对比全部可视化，但底层仍然调用你系统里那套 git 二进制，不另建一套仓库格式，也不会把.git改成别的客户端读不懂的样子。适合已经会 add/commit/push、却被复杂合并和历史整理磨得没脾气的人；也适合刚学 Git、必须看见分支图才能理解 merge 与 rebase 差别的新手。装完就一个 deb 包的事，剩下的全是配置和习惯。
2. 拆开 deb 再装：GitKraken 在 Ubuntu 上的依赖链路
Ubuntu 上装这类图形客户端，十个失败里有八个不是包坏了，而是依赖没落地。很多人拿到 deb 第一反应是sudo dpkg -i，看到一堆红字再慌。其实只要在装之前把包里那两个元数据文件读一遍，后面会省掉半小时排查。这一章先把包拆开看结构，再讲清楚 apt 和 dpkg 的分工，最后给三条验证命令。
2.1 先看清包里装了什么：control 字段与目录布局
拿到gitkraken-amd64.deb之后先别急着装，用dpkg-deb读两遍，一遍读元信息，一遍读文件清单。
# 读元信息：包名、版本、架构、依赖清单、维护脚本 dpkg-deb -I ./gitkraken-amd64.deb # 读文件清单：装到哪些目录、装了哪些文件 dpkg-deb -c ./gitkraken-amd64.deb | head -40 # 只看依赖那一行，方便复制去查 dpkg-deb -f ./gitkraken-amd64.deb Depends-I读的是包内DEBIAN/control，重点看三个字段：Architecture必须是amd64（32 位机器和 arm 机器直接放弃，别硬装）；Version确认是 6.5.1 而不是别的；Depends是这一章的核心，它列出了包管理器在安装前必须满足的共享库。-c列出的是压缩包内的路径树，通常会看到/usr/share/下有一个完整的应用目录，/usr/bin/下有一个启动入口，/usr/share/applications/下有一个.desktop文件——最后这个文件决定了应用菜单里有没有图标，后面排查「装完找不到」时要用到。
Depends里出现的库名，对应的都是图形界面运行时绕不开的东西。下面这张表是我在几台干净机器上装完后总结的对应关系，缺哪个基本能直接从现象反推：
| 依赖包 | 承担的作用 | 缺失时的典型表现 |
|---|---|---|
libgtk-3-0 | 窗口与控件渲染 | 启动瞬间退出，终端只留一行 GTK 报错 |
libnss3 | 网络与证书校验 | 界面能开，登录或拉取仓库时报证书错误 |
libasound2 | 音频子系统接口 | 启动日志里刷 ALSA 相关警告 |
libgbm1 | 图形缓冲区管理 | 窗口出现但内容全白 |
libxss1、libxtst6 | 屏保抑制与输入模拟 | 快捷键、拖拽偶发失灵 |
libsecret-1-0 | 系统钥匙环读写 | 每次都要重新输入凭据 |
libatspi2.0-0 | 无障碍接口 | 部分桌面环境下启动即崩 |
提示：不要凭记忆去
apt install这一长串包名，版本对不上反而会把系统里已有的库降级。让 apt 自己算，依赖关系交给它，你只负责看结果。
2.2 用 apt 装而不是 dpkg -i：三条命令的顺序
dpkg -i只做两件事：把文件铺到磁盘上、跑一遍维护脚本。它不做依赖求解。依赖不满足时，包会停在half-configured状态，维护脚本没跑完，.desktop文件和启动入口就可能是残缺的——这就是很多人「装完了但菜单里没有」的根源。
正确顺序是把本地 deb 当成一个 apt 源里的包来装：
# 1. 先刷新索引，保证依赖能查到最新候选版本 sudo apt update # 2. 用 apt 装本地文件，注意路径前必须有 ./ sudo apt install ./gitkraken-amd64.deb # 3. 确认包状态是 ii（已安装且已配置） dpkg -l | grep -i gitkraken第 2 步的./不能省。省掉之后 apt 会把它当成一个包名去源里找，报「无法定位软件包」。apt 处理本地 deb 的流程是先解包、读 control 里的Depends、在当前源里求解、把缺的依赖一起装、最后才跑维护脚本，所以装完就是配置完成的状态。
如果已经手滑用了dpkg -i，也别卸载重来，一条命令能救：
# 补齐所有处于半配置状态的包依赖 sudo apt --fix-broken install # 再手动触发一次配置流程 sudo dpkg --configure -a--fix-broken做的事就是扫一遍 dpkg 数据库里状态异常的包，把它们的依赖补上并重新配置。这一步跑完，图标、启动入口、菜单项通常就都回来了。
另外提前说清楚卸载的边界：sudo apt remove gitkraken只删程序文件，~/.gitkraken下的配置、仓库列表、窗口布局都还在；重新装回来时这些东西会接着用。想彻底清干净得手动删那个目录，但我不建议，配置重建一遍并不轻松。
2.3 装完的三处验证：包状态、启动入口、运行库
装完不要靠双击图标来判断成功，命令行验证更直接。
# 1. 包状态：第一列必须是 ii dpkg -l | grep -i gitkraken # 2. 启动入口是否存在、指向哪里 command -v gitkraken ls -l "$(command -v gitkraken)" # 3. 运行库是否有 not found（路径以实际安装位置为准） ldd /usr/share/gitkraken/gitkraken 2>/dev/null | grep "not found"第 3 条是最有价值的。ldd会把可执行文件依赖的每个.so都解析一遍，输出里出现not found就是硬缺失，缺什么名字一目了然。拿到缺失的库名之后，反查它属于哪个包：
# 装 apt-file 并更新索引（只需一次） sudo apt install apt-file sudo apt-file update # 反查库文件属于哪个包 apt-file search libXss.so.1apt-file search的输出格式是「包名: 文件路径」，取冒号前面那段装就行。这台机器如果是精简安装的服务器版加桌面，缺库是常态；如果是完整桌面版，一般只会缺libsecret这一类偏门依赖。
3. 首次启动要配的四件事：git 路径、身份、签名、凭据
界面能开只是开始。GitKraken 自己不带 git 实现，它是一个壳，所有真实操作都转发给你系统里的 git，所以一旦路径指错、身份没配、签名链路断掉，界面上的按钮会报出各种看起来像客户端 bug 的错误。这四件事配完，后面九成的怪问题不会出现。
3.1 让 GitKraken 用系统的 git，而不是它自己找的那份
先在终端确认系统 git 的位置和版本：
command -v git git --version然后在客户端的偏好设置里找到 Git 可执行文件路径那一项，把值显式写成/usr/bin/git，不要留空让它自己探测。留空的后果是：某些环境下它会退回到打包时附带的一份精简 git，那份通常缺git-lfs、缺 gpg 集成，钩子行为也和系统 git 有细微差异——你会发现命令行能跑通的脚本，在界面里点提交就失败。
版本上有个边界要提醒。这是个 6.5.1 的老客户端，它解析 git 命令输出的方式是按当年的格式写死的。系统 git 如果太新（比如 2.35 以后），某些子命令的输出格式、提示语、退出码都有调整，客户端可能把「正常」误判成「异常」。我的做法是把系统 git 控制在 2.20 到 2.30 这个区间，兼顾 LFS 与 worktree 支持，也不至于和客户端打架。查版本冲突最直接的办法是在终端里手动跑一遍客户端刚跑过的命令，如果命令行成功、界面失败，基本就是解析不兼容而不是仓库坏了。
3.2 提交身份、换行策略与中文路径
GitKraken 读取的是标准~/.gitconfig，所以先在命令行把全局身份写对，界面会自动同步，不要在界面里另建一套。
# 全局身份，注意邮箱要和代码托管平台的账号一致，否则提交不会关联到你的头像 git config --global user.name "某开发者" git config --global user.email "dev@example.com" # 中文文件名不转义成八进制，界面和 diff 里才能正常显示 git config --global core.quotepath false # 换行策略：Linux 上检出保持 LF，提交时把 CRLF 转成 LF git config --global core.autocrlf input # 新仓库默认分支名，git 2.28 及以上支持 git config --global init.defaultBranch main # 看一眼最终结果 git config --global --listcore.quotepath false这条对中文用户是刚需。默认情况下 git 会把非 ASCII 文件名转成\344\270\255\346\226\207这种八进制转义，命令行还能忍，图形界面的文件列表里就是一片乱码，冲突面板也没法对着文件名找。改完之后新开的仓库立即生效，已打开的仓库重启客户端即可。
单个仓库需要覆盖身份时（比如公司仓库用另一个邮箱），去掉--global，在仓库目录下执行一次即可。优先级是仓库级高于全局级，客户端显示当前仓库的提交身份时会跟着变。
3.3 GPG 签名：pinentry 那一关怎么过
如果团队要求提交必须签名，这条链路要在装完客户端的第一天就打通，否则你会遇到「界面点提交一直转圈」这种最难查的现象。
# 1. 生成密钥，交互式选择 RSA 4096、填写姓名邮箱、设置口令 gpg --full-generate-key # 2. 取私钥 ID（第二列那一长串的后 16 位） gpg --list-secret-keys --keyid-format=long # 3. 写入 git 配置 git config --global user.signingkey 3AA5C34371567BD2 git config --global commit.gpgsign true git config --global tag.gpgsign true # 4. 验证：能签出来、能验回去 echo test | gpg --clearsign git commit --allow-empty -S -m "签名测试" git log --show-signature -1user.signingkey填的是私钥 ID，不是公钥指纹，填错会报gpg failed to sign the data。第 4 步里--allow-empty造一个空提交专门用来测签名，测完可以用git reset --hard HEAD~1撤掉。
真正会卡住的是口令输入环节。图形客户端是一个没有可控终端的进程，gpg 需要口令时会去调pinentry，而默认的pinentry-curses需要一个 tty，拿不到就卡死或者直接抛Inappropriate ioctl for device。解法是让 gpg 走回环模式并把口令缓存住：
# ~/.gnupg/gpg.conf pinentry-mode loopback# ~/.gnupg/gpg-agent.conf allow-loopback-pinentry default-cache-ttl 28800 max-cache-ttl 86400两处改完重载一次 agent，让它读新配置：
gpg-connect-agent reloadagent /byedefault-cache-ttl是口令在内存里缓存的秒数，28800 就是八小时，正好覆盖一个工作日。超过max-cache-ttl之后强制重新输入。如果嫌回环模式安全性不够，另一个选择是装一个图形化的 pinentry 前端，让弹窗由桌面环境接管，效果一样，看团队规范选。
3.4 凭据存储：别让密码弹窗打断流程
最后一件是凭据。HTTPS 方式克隆的仓库每次推送都要密码，客户端自己有一套凭据管理，但和命令行不共享，会出现「界面能推、终端不能推」的割裂感。统一交给 git 的 credential helper 更省心：
# 方案一：内存缓存，重启即失效，适合共用机器 git config --global credential.helper "cache --timeout=3600" # 方案二：走系统钥匙环，重启后仍在，需要 libsecret sudo apt install libsecret-1-0 libsecret-1-dev git config --global credential.helper libsecret # 确认当前用的是哪个 helper git config --global --get credential.helpercache的--timeout单位是秒，3600 就是一小时。它的凭据只存在内存里，进程退出就没了，安全性好但每次开机要重输一次。libsecret依赖桌面钥匙环服务，在没有钥匙环的极简桌面环境下会静默失败，表现为「配了但还是要密码」，这时候退回cache更实际。
长期来看更推荐 SSH：一次ssh-keygen -t ed25519生成密钥对，公钥贴到托管平台，之后推送不需要任何交互，也不受钥匙环影响。客户端里把远程地址从https://改成git@开头就行，或者用git remote set-url一条命令切换。
4. 冲突面板与历史整理：把 GUI 用在真正费时的地方
图形客户端的价值不在「代替 git 命令」，而在两个地方：冲突的三方对比、以及提交历史的拖拽整理。这两件事在命令行里要么看不清，要么步骤多到容易漏。这一章把这两块的实操路径走一遍，顺带说清楚 LFS 的接入时机。
4.1 三方合并面板的四个区域怎么读
冲突文件在磁盘上长这样：
<<<<<<< HEAD retry_count = 3 ======= retry_count = 5 >>>>>>> feature/backoff<<<<<<<到=======之间是当前分支（ours，也就是 HEAD）的内容，=======到>>>>>>>之间是被合入分支（theirs）的内容。客户端会把它渲染成三栏：左边 ours、右边 theirs、中间或下边是合并结果，逐块点击「取左」「取右」「两边都要」，中间栏实时更新。
这里有个最容易踩的语义陷阱：执行 rebase 时，ours 和 theirs 的身份是反过来的。rebase 的本质是把你的提交逐个摘下来重新应用到新基底上，所以「当前所在的位置」是上游分支，而你自己的提交反而变成了被合入的一方。很多人凭直觉点「保留左边」，结果把自己的改动全丢了。判断标准很简单：看面板上的分支名标签，不要凭左右位置。
冲突处理完的收尾动作是三步，顺序不能错：
# 1. 确认没有残留的冲突标记和未标记为已解决的文件 git diff --name-only --diff-filter=U git status --short # 2. 界面里点 Mark resolved 之后，文件已经进暂存区 git diff --cached --stat # 3. 中途想放弃，整场合并回滚 git merge --abort # 如果当前是 rebase，用对应的命令 git rebase --abort第 1 步的输出如果为空，说明所有冲突都已解决；非空就说明还有文件没处理，此时提交会失败。git status --short里前缀UU表示双方都改过、AA表示双方都新增，这几种都需要人工介入。
注意：放弃合并用
abort而不是reset --hard。abort会完整恢复到合并前的状态，包括未提交的改动；reset --hard会把你工作区里没提交的东西一起清掉，没有后悔药。
4.2 交互式 rebase：拖动、squash 与 fixup 的差别
整理历史是图形界面比命令行舒服最多的地方。典型场景：一个功能提交了七个 commit，中间夹着「改个错别字」「再改」「忘了加文件」这种噪音，推之前想压成两个干净提交。
在提交图上右键目标提交的父提交，选交互式 rebase，界面会列出一串提交，此时可以拖动排序、右键选择动作：
| 动作 | 效果 | 什么时候用 |
|---|---|---|
| pick | 原样保留 | 默认状态，不改动 |
| reword | 保留改动，改提交信息 | 信息写错了但代码没问题 |
| squash | 与前一条合并，两条信息拼接后让你编辑 | 想保留中间过程的描述 |
| fixup | 与前一条合并，丢弃本条信息 | 纯噪音提交，信息没有价值 |
| drop | 直接删除该提交 | 提交内容本来就不该存在 |
| edit | 停在该提交上，允许修改内容 | 需要拆分或补充改动 |
squash 和 fixup 的区别就在信息处理上。squash 会把两条提交信息都摆出来让你编辑，适合中间那次提交记录了重要决策背景的情况；fixup 直接丢掉后一条的信息，适合「修个笔误」这种。整段历史里 fixup 用得多，压完更干净。
改完之后客户端会重放提交，如果有冲突会逐个停下来让你处理，处理方式和普通合并一样。全部走完之后必须用命令行复核一遍：
# 看历史形状是否符合预期 git log --oneline --graph -20 # 看操作日志，确认每一步重放都成功了 git reflog -10 # 已经推送过的分支，改写后要用带保护的强推 git push --force-with-lease origin feature/backoff--force-with-lease比--force多一层保护：如果远端在你上次 fetch 之后被别人推过新提交，它会拒绝覆盖，避免把同事的工作冲掉。这是改写已推送历史的唯一正确姿势。git reflog是这一节的保命符——rebase 搞砸了，从 reflog 里找到操作前那个提交哈希，git reset --hard <hash>就能回到过去。
4.3 Git LFS：什么时候必须开，开了要注意什么
仓库里一旦混进设计稿、视频、数据集压缩包，.git目录会迅速膨胀到几个 G，克隆一次要等半天。这时候需要 LFS 把大文件挪到独立存储，仓库里只留指针。
# 1. 装 LFS 扩展并做一次全局初始化（写入全局钩子） sudo apt install git-lfs git lfs install # 2. 在仓库里声明要跟踪的扩展名 cd /path/to/repo git lfs track "*.psd" "*.zip" "*.mp4" # 3. .gitattributes 必须提交，否则别人克隆下来不知道哪些走 LFS git add .gitattributes git commit -m "chore: 接入 LFS 跟踪大文件" # 4. 查看当前被 LFS 接管的文件 git lfs ls-files第 2 步的跟踪规则写在.gitattributes里，这个文件是仓库的一部分，必须提交。少这一步的后果是：你本地看着一切正常，同事克隆下来拿到的是几百字节的指针文件，打开全是乱码。
第 3 步之后的大文件才会走 LFS，之前已经提交进历史的大文件不会自动迁移。要清理历史得用git lfs migrate import --include="*.zip"，这条命令会重写所有相关提交的哈希，等于把整个仓库的历史改写一遍，团队协作的仓库上执行前必须全员同步、所有分支停推。我一般只在新仓库或者个人仓库上做这件事。
还有一点：客户端里看到某个文件显示为 LFS 对象、点开预览失败，通常不是客户端的问题，而是本地没装git-lfs或者没跑git lfs install，指针文件没被拉成实体。先git lfs pull补一次，再重启客户端。
5. 避坑与排查：五类翻车现场的现象、原因与解法
下面这五条是我在不同机器上反复遇到的，按「安装启动」和「运行期」分成两组。每条都给出可直接照做的判定路径，不用凭感觉猜。
5.1 安装与启动阶段的两类问题
现象一：装完 deb，应用菜单里没有图标，终端敲命令提示 command not found。
原因：用dpkg -i安装时依赖未满足，包停在half-configured状态，维护脚本没跑完，/usr/bin下的启动入口和/usr/share/applications下的.desktop文件没有落地。此时 dpkg 数据库里这个包的状态是iF或iU，不是ii。
解决：先看状态再修，不要卸载重装。
dpkg -l | grep -i gitkraken sudo apt --fix-broken install sudo dpkg --configure -a dpkg -l | grep -i gitkraken # 复查，应为 ii如果修完仍然是ii但菜单里还没有，是桌面环境的菜单缓存问题，注销重新登录一次即可，不用改任何文件。
现象二：窗口能弹出来，但内容一片白，或者启动两三秒后直接消失。
原因：分两种。一种是运行库缺失，尤其是libgbm1，缺了之后渲染管线初始化失败，窗口建出来但画不出东西；另一种是显卡驱动或虚拟机的图形加速不可用，拿不到可用的 GL 上下文。远程桌面、虚拟机、老旧集显这三种环境命中率最高。
解决：先排依赖，再排渲染。
# 第一步：确认不是缺库 ldd /usr/share/gitkraken/gitkraken 2>/dev/null | grep "not found" # 第二步：依赖齐了还白屏，用禁用 GPU 加速的方式启动 gitkraken --disable-gpu # 如果这样能开，把参数固化到 desktop 文件的 Exec 行里--disable-gpu是这类客户端通用的降级开关，关掉硬件加速之后界面渲染走软件路径，慢一点但能用。确认有效后，编辑/usr/share/applications/下对应的.desktop文件，在Exec=那一行末尾加上这个参数，之后从菜单启动也会带上。缺点是每次包升级这个文件会被覆盖，需要重做一次——所以更省事的做法是给自己在~/.local/share/applications/下建一份同名覆盖文件。
5.2 运行期的三类问题
现象三：点提交后界面一直转圈，命令行git commit -S报Inappropriate ioctl for device。
原因：gpg 需要输入私钥口令，但图形进程没有可控终端，默认的pinentry-curses拿不到 tty 就卡住；命令行场景下则是当前 shell 没有可用 tty（比如在钩子或脚本里调用）。
解决：配置回环模式加口令缓存，具体两段配置见 3.3 节。改完必须重载 agent：
gpg-connect-agent reloadagent /bye另一个常被忽略的点是GPG_TTY环境变量。在命令行里签名失败时，先export GPG_TTY=$(tty)再试一次，如果能过，说明就是 tty 传递的问题，把这一行写进 shell 的启动文件即可。
现象四：打开某个仓库直接报错退出，命令行进这个目录也报detected dubious ownership。
原因：仓库目录的属主和当前用户不一致（常见于sudo git clone出来的目录，或者从别的机器整目录拷贝过来的），新版 git 出于安全考虑拒绝在属主不明的仓库里执行操作。老客户端不认识这个新提示，只表现为「打开失败」。
解决：二选一，改属主或加白名单。
# 方案一：把目录属主改回自己（推荐，一次性解决） sudo chown -R "$USER":"$USER" /path/to/repo # 方案二：把路径加进全局白名单 git config --global --add safe.directory /path/to/repo git config --global --get-all safe.directory方案二适合目录属主不能改的场景（比如挂载的共享目录）。注意safe.directory要写绝对路径，写*等于关掉这项保护，不建议。
现象五：大仓库打开卡顿，切个分支要等十几秒，界面一直转圈。
原因：客户端默认会扫描工作区状态并周期性 fetch 远端，工作区文件数上十万或者仓库放在机械盘、网络盘上时，这两件事都会拖垮响应。另外历史提交数过万时，一次性渲染提交图也很吃内存。
解决：按收益从高到低做三件事。
# 1. 仓库放到本地 SSD，这一步收益最大，没有替代方案 # 2. 开启文件系统监听，避免每次全量扫描（git 2.37 及以上） git config core.fsmonitor true # 3. 大仓库预设，一次性打开一批针对性优化 git config feature.manyFiles true同时在客户端偏好设置里关掉「自动 fetch」和「自动刷新工作区状态」，改成手动触发。feature.manyFiles会启用索引跳过哈希缓存、未跟踪文件缓存等一整套优化，代价是首次建立索引会慢一次。如果系统 git 版本够不上 2.37，那就只做第 1 步和关自动刷新，收益也有一半以上。
6. 进阶：用命令行复核 GUI 的每一步
图形界面最大的风险不是功能缺失，是「你以为它做了，其实它没做」。点一下暂存、点一下提交、拖一下 rebase，动作太轻，很容易漏掉中间某一步。我现在的习惯是：任何在界面里完成的操作，都用一条只读命令复核一遍。提交后git log --oneline --graph -5看形状对不对，合并后git status --short看有没有残留的UU，rebase 后git reflog -5确认每一步重放都成功。
更彻底的做法是把检查前移，用钩子把低级错误拦在提交之前。客户端会正常触发仓库里的钩子，所以这套在界面里同样生效：
#!/usr/bin/env bash # .githooks/pre-commit —— 提交前拦一道，避免界面里手滑 set -e # 1. 冲突标记残留、行尾空白这类问题一次性检查 git diff --cached --check || { echo "暂存区有冲突标记或空白错误"; exit 1; } # 2. 单个文件超过 5MB 就拦下来，提醒改用 LFS limit=$((5 * 1024 * 1024)) git diff --cached --name-only --diff-filter=ACM | while read -r f; do [ -f "$f" ] || continue size=$(wc -c < "$f") if [ "$size" -gt "$limit" ]; then echo "文件过大：$f（$((size / 1024 / 1024)) MB），请先 git lfs track" exit 1 fi donegit diff --cached --check会同时检查冲突标记和行尾空白，有问题时退出码非零，钩子直接终止提交。第二段按字节比较大小，--diff-filter=ACM只挑新增、复制、修改的文件，删除的文件不参与判断。set -e保证任何一条命令失败就整体退出，不会带着错误往下走。
钩子放在.git/hooks里不会进版本库，团队共享要换个位置：
mkdir -p .githooks mv .git/hooks/pre-commit .githooks/pre-commit chmod +x .githooks/pre-commit git config core.hooksPath .githooks最后是配置备份。~/.gitkraken那个目录里放着仓库列表、窗口布局、SSH 密钥路径这些手工调过的东西，重装系统时丢了要重新点一遍，很烦。我现在每次大版本变动前打一个包：
tar -czf ~/gitkraken-backup-$(date +%F).tar.gz ~/.gitkraken 2>/dev/null || true2>/dev/null || true是防止目录里个别文件没权限读时整条命令失败中断。具体子目录结构以实际安装为准，但整个目录打包不会漏。
从那以后我每次在界面里完成一次 rebase 或者合并，都会强制走一遍「log 看形状、status 看残留、reflog 留退路」这三条，哪怕当时觉得百分之百没问题——因为出问题的那几次，恰恰都是我觉得没问题的。希望帮到你。
本文还有配套的精品资源，点击获取
