简介：GitHub Desktop for Mac 是一款为 Mac 用户设计的可视化 GitHub 集成客户端，主要面向刚接触 Git 的初学者，也适合需要在图形界面下高效完成提交、分支与代码审查的日常开发者。这份压缩包共包含 1556 个文件，大小约 26.78MB，除应用运行所需的 png、tiff、nib、svg 等界面与资源文件外，还内置了大量 git 子命令工具、man 手册页、认证插件和配置模板，能够支持完全离线安装及命令参考查阅。目前已有 455 人学习下载。通过该包，用户可以完整获得 GitHub Desktop 主程序及其附属 Git 工具链，在本地直观完成克隆仓库、暂存改动、创建分支、发起 Pull Request 等操作；包内附带的手册页与示例文件还可帮助梳理 git config、git log、git merge 等常用命令的底层逻辑，便于开发、排错和深入学习。整体目录结构清晰，适合作为 Mac 上 Git 协作的随查随用工具包。
1. GitHub Desktop for Mac 到底是给谁用的
很多 Mac 开发者第一次装 GitHub Desktop，是想少记几条 Git 命令；但用过一段时间之后的感受恰恰相反，它的价值不是“不用敲命令”，而是把每次提交前的变化摊开给你看。当你面对一个改了三十个文件的仓库，命令行里git diff一屏一屏往外翻的时候，GitHub Desktop 能让你先看目录、再看文件、最后看每一行改动，这个节奏对新手和熟手都有用。它是在协作场景里定位的工具：克隆远程仓库、切换分支、发起 Pull Request、处理冲突，都能在图形界面里完成。这篇笔记从安装、配置讲到日常使用和踩坑，按真实工作流来写，新手能照做，熟手可以跳过安装直接看避坑。
2. 安装与首次配置：一条命令装好，五个设置决定后半程手感
2.1 为什么在 Mac 上推荐用 Homebrew 安装而不是官网 dmg
官网下载 dmg 直接拖进 Applications，是 Mac 用户最熟悉的安装方式，适合临时尝鲜。但如果你打算长期用它管理仓库，我建议把它交给 Homebrew 来维护。Homebrew 是 mac 软件包管理工具里最普及的一个，GitHub Desktop 在它的 Cask 源里有正式收录，一条命令装完，后续升级一行命令搞定，不用每次去官网重新下载 dmg。
# 安装 Homebrew 本身，如果还没装 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" # 使用 cask 安装 GitHub Desktop brew install --cask github前面那行curl是 Homebrew 官方安装脚本，不多解释；重点是第二行。--cask github指的是 Homebrew Cask 里的包名，cask 分发 GUI 应用，formula 分发命令行工具。如果你不加--cask，brew install github会去装 GitHub 官方的命令行工具gh，这是很多人第一次翻车的地方。装完以后，应用会出现在/Applications/GitHub Desktop.app，但数据文件散落在~/Library/Application Support/GitHub Desktop这几个目录里。
用 cask 安装还有个隐性好处：brew upgrade github就能跟着官方版本走，不用赌哪天打开应用才意识到自己落后了三个大版本。很多人装 Homebrew 本身会卡在下载阶段，尤其是在某些网络环境里拉 install.sh 或 bottle 一直中断。常见做法是先切到中科大或清华的镜像源再跑安装脚本，HOMEBREW_BOTTLE_DOMAIN指到镜像站后，下载就顺畅很多。装完 Homebrew 再执行brew install --cask github，基本不会再遇到中断。
提示：判断 cask 源是否正常，可以先跑
brew info --cask github，能看到版本号和安装路径就说明源没问题；如果提示找不到这个 cask，先执行brew update再试。
2.2 首启配置：登录、身份与默认 shell 的取舍
第一次启动 GitHub Desktop，会直接进入登录页。它走的是 OAuth 流程，自动打开浏览器授权，授权完跳回应用，全程不需要输入密码。这个授权令牌会存放在 macOS 钥匙串里，对应条目一般叫github.com对应的 internet password。如果你所在的办公网络把浏览器回调挡掉了，可以用另一种方式：在 GitHub 网页端创建一个 Personal Access Token，回到 GitHub Desktop 的登录页，选 “Sign in with token” 粘贴进去。这个方式适合没有浏览器回调的受限环境，但创建 token 时只勾repo相关权限就好，权限大了是给自己埋雷。
登录完先处理默认 shell。路径是 Preferences -> Shell，macOS 上现在默认是 zsh，我建议直接保留 zsh，不要为了“兼容公司脚本”去选 bash。macOS 自带的 bash 还停留在 3.2，很多语法和 zsh 环境不兼容，选 zsh 能让 GitHub Desktop 打开终端时和你日常终端环境完全一致。这个设置决定的是你在仓库里执行构建命令时的环境变量，如果这里选错了，后面在 GUI 里点开 Terminal，发现nvm、java、mvn全部找不到，那才真是开屏劝退。
同一屏里还有 Fetch 周期设置，默认每隔一段时间自动抓取远程引用。如果你的仓库特别大或者文件数特别多，可以把自动 fetch 关掉，改成手动点 Fetch origin。这个设置不影响 push，只影响你能不能及时看到别人的新分支，大仓库为了这一点实时性付出 CPU 代价不划算。
2.3 把提交身份与全局 Git 解耦：应对“明明配了却不对”的尴尬
Mac 上很多人同时用 GitHub Desktop、IDEA 自带 Git、命令行，这几个工具读的都是同一套 Git 配置，但优先级不一样。GitHub Desktop 的 Preferences -> Git 里填的 Name 和 Email，本质是写入~/.gitconfig，属于 global 层；如果你在某个仓库里单独执行过git config user.name，仓库级配置会盖过全局配置，于是在 GUI 里显示的是仓库级身份，而 GitHub Desktop 的偏好设置里还写着另一个名字。查身份来源，用这几条命令：
git config --local --list # 看仓库级配置 git config --global --list # 看用户级配置 git config --show-origin user.name # 看当前生效的 user.name 来自哪个文件第三条最关键。--show-origin会直接告诉你当前生效的user.name是从~/.gitconfig还是从.git/config里读出来的，一目了然。GitHub Desktop 没有暴露仓库级配置的编辑入口，但它会遵守 Git 的配置优先级，所以排查时以这三条命令的输出为准。
身份配置还有个细节容易被忽略：个人邮箱和公司邮箱最好分开。在 GitHub 网页端 Settings -> Emails 里开启邮箱隐私后，会拿到一个你的用户名@users.noreply.github.com匿名地址，把它填到 GitHub Desktop 的全局配置里，个人项目提交就不会暴露真实邮箱。公司项目如果要求提交归因到人，那就单独在仓库里执行git config user.email "你的公司邮箱"。这样全局是匿名身份，特定仓库是公司身份，互相隔离，不会出现“PR 里显示的人不是自己”的乌龙。这里的常见事故是：同事辞职后账号被移除，他提交过的历史 commit 全部变成灰色头像，原因是当初没把邮箱和 GitHub 账号绑定，除非当初设置了 noreply 邮箱，否则后来再补绑也没法完全修复历史。
如果你还需要让提交显示 Verified 徽标，可以在 Preferences -> Git 里配置 GPG 签名密钥。命令行对应的是：
gpg --list-secret-keys --keyid-format LONG git config --global user.signingkey <你的密钥ID> git config --global commit.gpgsign trueuser.signingkey填的是 GPG 密钥的长 ID，commit.gpgsign打开后每次提交都会自动签名。GitHub Desktop 会调用本机 gpg 程序，如果之后弹窗提示找不到 gpg，多半是~/.gnupg/gpg-agent.conf里的 socket 路径和 GUI 环境不一致，重新登录一次 macOS 会话就能恢复。
3. 日常协作全流程：从克隆到提交，几个容易被忽略的操作
3.1 克隆仓库的三种入口，以及 clone 时最容易被忽略的路径问题
GitHub Desktop 里克隆仓库有三种入口，覆盖面不太一样。第一种是 File -> Clone Repository，弹窗里会列出你有权限的仓库，支持 GitHub.com 和 GitHub Enterprise 两个来源；第二种是直接在 URL 标签页粘贴一个 Git 地址，用来处理那些不在 GitHub 上托管的仓库，比如公司内网 GitLab；第三种是在网页仓库页面点 Code -> Open with GitHub Desktop，浏览器会通过github-desktop://协议把仓库信息交给本机应用。第三种最快，省得在长列表里翻名字。
克隆地址之外，路径问题才是最多人踩的坑。GitHub Desktop 默认把仓库放在~/Documents/GitHub下，如果开启了 iCloud 的“桌面与文稿”同步，~/Documents会被 iCloud 按需管理。一个挂在 iCloud 上的 Git 仓库，随时可能因为“未下载”状态去触发网络下载，下载中一旦断网，很容易出现.git/index.lock或对象文件缺失。我习惯在第一次克隆时就把路径改成~/Code、~/work这类不在云同步范围内的目录。命令行验证路径和仓库状态：
mkdir -p ~/Code cd ~/Code git clone https://github.com/yourname/your-repo.git这段命令的意义不是让你放弃 GUI，而是让你知道仓库的本地落点，后面出了问题能直接进目录排查。克隆完成后第一件事是执行git remote -v，确认 remote 地址是 HTTPS 还是 SSH 风格。如果你在 GUI 里克隆失败、命令行却成功，多半是 remote 地址和本地已有配置冲突；反过来命令行失败、GUI 成功，那一般是凭据存储方式不同导致的。两边一起用，能快速缩小排错范围。
另外注意，仓库路径里尽量不要有中文。中文路径在大部分场景下能工作，但老牌的构建工具链对非 ASCII 路径支持很差，报出来的错误五花八门，最后查一圈才会发现是路径问题。GitHub Desktop 自身没问题，但你的项目不一定，这属于能避就避的玄学。
3.2 分支管理：创建分支、切换分支与 PR 工作流
分支入口在工具栏正中间，当前分支名的右侧会有一个 “New Branch” 按钮。它默认基于你当前所在分支创建，所以创建前最好先切回默认分支，否则容易把别人还没合并的改动带进新分支。分支命名建议遵守团队约定：feature/、fix/、release/是通用前缀，CI 触发规则和 PR 模板通常会解析这些前缀。
GitHub Desktop 在切换分支时处理未提交改动的方式和命令行不同。命令行里如果有未提交的修改，直接git checkout有可能会报错，或者把改动带到另一个分支；GitHub Desktop 会弹窗询问，你可以选择暂存当前改动再切换，这个机制对日常多任务并行很友好，避免了“切到别的分支发现同事代码混进来了”的社死现场。
把本地分支推上去并发起 PR，可以直接按Cmd + Shift + P，会打开默认浏览器进入 GitHub 的 compare 页面。命令行对应的操作是：
git push -u origin feature/readme-update-u参数建立本地分支与远程分支的追踪关系，之后在这个分支上直接git push就够了。GUI 推送成功后，分支菜单里会看到origin/feature/readme-update，这表示追踪关系已经建立。如果只显示feature/readme-update没有origin/前缀，说明推送还没完成，或者是远端分支名和本地不一致。
分支删除这里有个小习惯：合完 PR 后，GitHub 网页端一般会自动帮你删远程分支，本地分支你不删，它会一直堆积。GitHub Desktop 的当前分支菜单里可以执行 Delete 操作，删除前它会检查你是否已经合并，未合并时会再确认一次。这个确认很有价值，命令行里的git branch -D是强制删除，字面上就危险得多。
3.3 提交、推送与拉取：GUI 的自动快照和提交时机
GitHub Desktop 的 Changes 视图是整个应用的核心。左侧列出变更文件，右侧显示 diff，最上面是提交信息输入框。默认状态下，文件不会自动进入暂存区，你需要逐个勾选，这对应命令行里的git add <file>。如果你不改勾选就直接点 Commit All，它会把所有已跟踪文件的改动一次性提交掉。
命令行的等价写法是：
git add src/components/Button.jsx git commit -m "fix: 修复按钮在窄屏下溢出" git push这样拆开提交的目的，是为了把一个混合改动拆成多个语义明确的提交。比如一次修改里既有格式化改动又有业务逻辑改动，混在一个 commit 里，后面拿git bisect定位回归时，会看到一个 commit 里既有无关的空白变化又有真正的代码变更，排查成本极高。GUI 里逐文件提交虽然慢一点，但能逼着你把每次提交想清楚。
关于暂存区状态，命令行和 GUI 的对应关系可以这样理解：GitHub Desktop 里文件前面的图标，M 表示修改，A 表示新增，D 表示删除，R 表示重命名，U 表示未跟踪。这些符号其实就是git status --short的第一列缩写。如果你在终端里看到一个文件显示AM，代表已暂存的新增内容后面又叠加了新的未暂存修改，这种状态在 GUI 里会显示成一个文件同时有 staged 和 unstaged 两部分，提交时要特别注意。
拉取行为里有必要调一个默认设置。GitHub Desktop 的默认 pull 策略是 rebase，不是 merge，这在不少从命令行过来的人眼里是反直觉的。第一次在 GUI 里点 Pull，发现自己的提交被“挪”到了远程提交后面，会以为代码丢了。这其实是 rebase 的正常表现，它保持历史线性，但也可能改变你本地提交的时间线。你可以在 Repository -> Repository Settings -> Pull behavior 里把策略改成 merge，如果你更习惯看到 merge commit 的话。改完之后拉取行为就和传统git pull一致了。
Fetch 和 Pull 是两个按钮，别混。Fetch origin 只更新远程引用，不碰你的工作区；Pull 才会把远程变更合并到当前分支。GUI 里这两个动作是分开的，建议在需要确认远端状态时先 Fetch，看完变化再 Pull，避免远程突然多出别人刚推的提交把你本地搞乱。
3.4 冲突解决：用 GUI 做“手动合并”并不会更轻松，但能更安全
GitHub Desktop 没有提供像 IDE 三路合并那样的图形化冲突编辑窗口。它只会在冲突文件上打一个黄色标记，你需要右键文件，选择打开外部编辑器，手动处理冲突标记。如果只有一两个文件冲突，这个流程还够用；如果冲突文件达到十几个，我不建议在 GitHub Desktop 里逐个打开，直接切到 VS Code 的源代码管理面板，或者用 IDE 的合并工具，效率高很多。
冲突标记的形态是这样的：
<<<<<<< HEAD 当前分支上保留的内容 ======= 要合并进来的远端内容 >>>>>>> feature/other-branch处理规则很简单：把<<<<<<<、=======、>>>>>>>这三行连同你不需要的内容一起删掉，只留下想保留的行，保存文件。Git 判断冲突是否解决的依据，是文件里是否还残留冲突标记。切回 GitHub Desktop 后，文件状态会从冲突变成已修改，这时可以直接提交。
这里要提醒的是，GitHub Desktop 在冲突界面不会帮你展示“基线版本”，也就是不显示合并前两个分支共同的那个版本。如果双方都改过同一段，你只靠当前 diff 很难判断谁是对的。我一般在冲突前先执行一次：
git log --merge --oneline这个命令会列出当前合并相关的提交，可以快速看到两侧分支最近改动过哪些内容，避免删错行。处理完保存后，提交前再用git diff --check扫一遍空白符错误，它会检查文件尾部空白和空格/tab 混用的问题。这些错误不会让合并失败，但会在 CI 上留个小尾巴，属于能顺手扫掉就扫掉的问题。
4. 与本地开发环境联动：Terminal、外部编辑器与 Git LFS
4.1 在 GitHub Desktop 里一键打开 Terminal
GitHub Desktop 在顶部菜单里有一个 Open in Terminal，快捷键是Ctrl + `。这个动作会打开你在 Preferences 里指定的默认终端，并自动cd到当前仓库目录。很多人喜欢在 GUI 里看 diff，但跑构建命令还要手动切到终端再输一遍目录，这个按钮省掉的就是这一步。
打开终端后，我通常会先确认三件事：
pwd git status ./mvnw -q package第一行确认目录，第二行确认 GUI 里的状态和命令行一致，第三行就是直接跑构建。如果你的项目是 Java 系，用./mvnw而不是mvn，能避免本机 Maven 版本和项目要求不一致的问题。这个细节在 Mac 上很常见：很多人自己下载安装的 Maven 是 3.6，项目要求的是 3.8，结果构建在 CI 上好好的，本机就报错。
一个容易忽略的点是，GitHub Desktop 的 Open in Terminal 并不额外帮你加载某个 shell profile，它用的是 Preferences -> Shell 里指定的那个程序。如果你日常在 zsh 里通过~/.zshrc配置了 Java 环境、NVM 路径，那么这个终端会把这些配置都带起来。反过来，如果你把默认 shell 设成了一个不加载 profile 的奇怪位置，打开后环境变量会缺一大片。这类问题看着像构建问题，实际是 shell 配置问题。
4.2 外部编辑器配置，以及为何建议选 VS Code
在 Preferences -> Integration -> External Editor 里可以选择外部编辑器，常见选项包括 VS Code、Sublime Text、Atom 等。我建议选 VS Code，不是因为它多好用，而是它的冲突处理能力刚好补齐 GitHub Desktop 的短板。GitHub Desktop 无法提供合并视图，但 VS Code 的源代码管理面板集成了三路合并编辑器，点击冲突文件就能看到左侧、右侧和结果列表，处理十几个冲突文件时安全感完全不同。
配置完成之后，在 GitHub Desktop 里右键仓库文件，会出现 “Open in Visual Studio Code” 菜单。这里有个连带问题：Finder 的右键菜单里默认没有“用 VS Code 打开”这一项。如果你想在 mac 右键菜单里直接打开某个文件夹到 VS Code，需要先安装 VS Code 的命令行工具：在 VS Code 里按Cmd + Shift + P，执行 “Shell Command: Install 'code' command in PATH”，安装完成后命令行里才有code命令，Finder 的右键菜单也会出现对应入口。
如果你不想装 VS Code，也可以用 Sublime，但建议先想清楚：你的使用场景是打开单个文件看 diff，还是经常处理冲突？如果只是看 diff，任何编辑器都够；如果是处理冲突，VS Code 的三路合并目前还是最顺手的。这个选择基本决定你后面几周的心情。
4.3 Git LFS 配置与仓库体积治理
GitHub Desktop 自带 Git LFS 支持，但前提是本机已经安装了git-lfs二进制。如果你没有装，clone 一个含 LFS 文件的仓库时，只会看到一堆指针文件，而不是实际内容。安装和启用命令：
brew install git-lfs git lfs install第一行安装命令行工具，第二行把 LFS 的过滤器写入全局 Git 配置。到这一步只是完成了“工具可用”，真正让某个仓库启用 LFS，还需要在仓库里声明跟踪哪些文件类型：
git lfs track "*.psd" "*.zip" "*.pkl" git add .gitattributes git statusgit lfs track会修改.gitattributes文件，把指定后缀名映射到 LFS 过滤器。之后这些文件在提交时只会写入一个几百字节的指针，实际内容存到远程 LFS 服务。注意 GitHub 免费仓库的 LFS 存储和流量都有限额，超出后 push 会被拒，所以不要为了省事把整个目录都塞进去，只跟踪真正的大文件类型。
检查仓库体积膨胀的来源，用下面的命令：
du -sh .git git count-objects -vHdu看.git目录总大小，count-objects看松散对象数量和压缩情况。如果.git的体积远大于工作区，那说明历史记录里塞过大文件，且这个历史不可能通过删当前文件变小。这时需要用git filter-repo这类工具重写历史，但它会改变所有提交的 hash，团队里每个人都得重新克隆仓库，执行前一定要和所有人对齐。GitHub Desktop 不会在界面上提醒你这些风险，它只负责把仓库呈现出来，体积治理的功课全在命令行。
5. GitHub Desktop for Mac 的常见问题与避坑清单
5.1 push 到远程仓库时报 403 或 not found，认证信息滞后
现象：仓库列表还能正常拉取，但 push 时提示权限不足，或者直接报仓库不存在。常见于你切换过 GitHub 账号，或者被移出了某个组织的仓库权限。
原因：GitHub Desktop 的 OAuth 令牌还挂在旧账号上。它不会自动读取系统钥匙串里其他账号的凭据，也不会因为你网页端切换了账号就更新本地令牌。旧令牌没到期，push 时就会拿旧身份去认证，远程自然拒绝。
解决：先到钥匙串访问里删除过期的 GitHub 条目。路径是 应用程序 -> 实用工具 -> 钥匙串访问，搜索github.com，把对应的 internet password 删除。然后回到 GitHub Desktop 触发一次 Fetch，它会重新走 OAuth 授权流程。如果仓库的 remote 地址用的是 SSH，那么情况和 OAuth 无关，需要检查 SSH key：
git remote -v ssh -T git@github.comgit remote -v看仓库地址是 HTTPS 风格还是git@github.com:风格。ssh -T git@github.com会告诉你当前 SSH 身份被识别成哪个账号。如果你在 Mac 上配置了多个 SSH key，确认~/.ssh/config里没有把同一个 key 重复绑定到多个 Host 上，否则认证顺序会混乱。很多人用过好用的 ssh 工具来管理多服务器，但 GitHub 仓库的 SSH 身份只认~/.ssh/config和 ssh-agent，第三方工具里的配置在这里不生效。
5.2 打开仓库一直转圈，卡在加载界面
现象：仓库能正常显示，但打开后顶部一直转圈，分支列表空白，CPU 占用升高，等很久才恢复，甚至一直不恢复。
原因：GitHub Desktop 在打开仓库时会执行 Git 状态扫描，同时渲染整个变更列表。仓库文件数越多、.git历史越庞大，这个扫描越慢。Electron 本身的内存占用也高，两个因素叠在一起，就会出现长时间加载。
解决：先考虑仓库本身。把node_modules、构建产物、日志目录都加入.gitignore，如果这些文件已经被跟踪了，就用git rm -r --cached从版本控制里移出，保留本地文件。其次，如果仓库里有大量历史二进制文件，优先做 LFS 迁移。还可以把 Preferences 里的 diff 显示方式从 Split 改成 Unified，Split 需要对每个文件做两栏渲染，开销明显更大。仓库特别大时，Fork 和 GitHub Desktop 之间我会优先选择前者，GUI 工具在超大仓库上的性能天花板就在这里。
5.3 中文文件名显示异常或无法提交
现象：GitHub Desktop 的变更列表里中文文件名显示成\346\265\213这样的转义字符，某些情况下推送后网页端文件名变成乱码。
原因：Git 默认对非 ASCII 路径做转义，这是core.quotepath导致的。GitHub Desktop 在展示时没有做完整解码，直接把转义序列显示了出来。
解决：在命令行里执行：
git config --global core.quotepath false git config --global core.precomposeunicode true第一条让 Git 不转义非 ASCII 路径，第二条是 macOS 专属设置。macOS 文件系统用 NFD 形式存储文件名，Git 内部按 NFC 规范化，precomposeunicode让 Git 在 Mac 上自动做转换，避免同一个中文文件在 macOS 和 Windows 之间反复推送时变成两份独立历史。设置完成后重启 GitHub Desktop 才能生效，命令行里可以用git status --short验证：能看到中文明文而不是\346开头的一串，就算对了。
5.4 多客户端共用仓库的 index.lock 与“另一个 git 进程”提示
现象：在 IDEA、Xcode 或命令行同时开着同一个仓库时，GitHub Desktop 提示Unable to create .git/index.lock: File exists.。
原因：Git 仓库同一时刻只允许一个写操作。其他 IDE 的 Git 插件可能还在后台做 fetch 或 status 扫描，上一步操作异常退出也可能留下锁文件。GitHub Desktop 发现锁文件存在，就会认为有另一个 Git 进程在写仓库。
解决：先关闭所有可能占用仓库的软件，再确认真没有 Git 进程残留：
ps aux | grep "[g]it" rm -f .git/index.lock[g]it的写法是为了让 grep 不匹配自己那条命令行。确认没有任何 Git 相关进程后，再手动删除锁文件。如果删完没多久又出现，检查仓库是否在 iCloud 或网盘同步目录里，同步服务可能会把锁文件或 Git 对象文件标记成冲突副本，导致 Git 认为索引损坏。这种问题很难从 GUI 侧解决，只有把仓库移出云同步目录。
5.5 拉取后本地未提交改动消失，以为代码丢了
现象：本地改了一个文件还没提交，点 Pull 之后远端也改了同一文件，GitHub Desktop 弹出冲突提示，处理过程中本地改动被覆盖，文件回到了远端版本。
原因：Git 本身对未提交改动是保护的，正常情况下不允许直接覆盖。但拉取动作触发冲突后，界面里会提供“放弃本地修改”之类的选项，很多人在弹出的对话框里没有仔细看就点了确认，实际执行的是丢弃本地改动。这个操作没有二次确认，而且不像提交可以撤销。
解决：先看 stash 列表：
git stash list git stash show -p stash@{0}GitHub Desktop 在某些拉取冲突前会尝试暂存本地改动，如果列表里有东西，git stash pop就能找回。如果没有 stash，再看 reflog：
git reflogreflog 会记录 HEAD 的每一次移动轨迹，找到丢失改动前的那个 commit，用git reset --hard <commit>能回到那个位置。这属于后悔药，能救急但不是每次都能完整找回。更稳的习惯是：在拉取前，未提交的重要改动先手动复制到临时文件，或者直接提交一个 WIP 提交。最怕的是你点击那些看起来像“同步”的按钮时，根本没意识到里面包含“放弃本地修改”的选项。
6. 让 GitHub Desktop for Mac 更好用的几个进阶验证技巧
先给日常加一个简单验证函数。GitHub Desktop 的界面会把仓库状态包装得很干净，但有些判断还是命令行更快。我在~/.zshrc里放了一个短函数，用来在打开 GitHub Desktop 之前确认仓库的真实状态：
gv() { echo "当前分支: $(git branch --show-current)" echo "工作区状态:" git status --short echo "落后远端: $(git rev-list --count HEAD..@{upstream} 2>/dev/null || echo 'no upstream')" }第二步的三行输出分别回答三个问题：我在哪个分支、工作区干不干净、落后远端几个提交。最后一行最关键，数字是 0 才说明本地和远端同步。如果数字不是 0，你在 GitHub Desktop 里直接点 Pull 就没问题；如果它提示 no upstream，说明这个分支还没推过，需要先 push。这个函数输出干净，适合放在每天开工的第一步。
再配合几个 GitHub Desktop 的快捷键：Cmd + Shift + P直接打开 Pull Request 页面，Cmd + Enter提交当前文件。还有一个经常被忽略的是Cmd + Z，它可以在提交完成但还没推送时撤销这次提交，等价于git reset --soft HEAD^，提交内容会回到变更列表里，你可以补充文件或修改提交信息。如果已经 push 了，就不要再按Cmd + Z，这时候撤销会造成历史分叉，处理起来很麻烦。
处理完冲突之后，我也养成了一个固定动作：切回终端执行git diff --check和git status。第一道命令检查冲突处理后有没有残留空行或 tab 问题，第二道命令确认暂存区状态和 GUI 一致。这个流程看起来多余，但能避免“冲突解决了、提交也推了、CI 却因为空白字符挂了”的翻车。
我现在已经不会只用 GitHub Desktop，也不会只用命令行。碰到小改动、想看 diff、要快速提交，GUI 确实顺手；碰到 rebase、历史重写、多分支清理，还是命令行更可控。真正让我放心的组合是：用 GitHub Desktop 看协作状态，用gv验证分支同步情况，遇到复杂操作就切到终端。希望帮到你。
本文还有配套的精品资源，点击获取