1. 为什么我会推荐 GitHub Desktop 而不是硬啃命令行很多人觉得用 Git 就必须用命令行不用命令行的都是“伪开发者”。这个观点我持保留意见。拿我自己举例第一次接触 Git 时也是从命令行一步步敲出来的git add、git commit、git push这些命令背得滚瓜烂熟但真正到了团队协作场景我发现维护分支策略、处理合并冲突、打量每次提交之间的 diff光靠命令行效率实在太低。后来我开始在主力机器上使用 GitHub 官方出品的 GitHub Desktop日常操作中 80% 的场景都切换到图形界面完成只有遇到特别复杂的历史改写才回到命令行。GitHub Desktop 并不是一个“简化玩具”它更像是给 Git 工作流加了层可视化仪表盘。你依然在用真正的 Git所有操作背后都会生成对应的 Git 命令仓库结构也和命令行操作完全一致。它适合刚接触 Git 的新手因为不需要记忆命令语法同样也适合有经验的开发者因为可以把注意力放在代码变化本身而不是命令拼写是否正确。这篇文章我打算把 GitHub Desktop 从安装到日常使用完整讲一遍包括分支管理、提交推送、冲突处理等核心操作。文中所有操作我都基于 Windows 和 macOS 两个平台实测过版本以 3.x 系列为准。如果你还在犹豫要不要从命令行切换到图形界面或者刚注册 GitHub 账号不知道从哪里开始这篇文章可以直接当作操作手册来用。1.1 这类工具到底解决了什么痛点先聊一个现实问题Git 本身的命令体系非常庞大commit --amend、rebase -i、cherry-pick、reset --hard这些高级命令各有各的使用边界新手很容易在某个步骤上卡住然后去搜索引擎里查半天命令是什么。最典型的场景是很多初学者在本地仓库里改了一堆文件然后打开终端输入git push origin master结果提示error: failed to push some refs这时候整个人是懵的因为命令输出的信息量太大而且全是英文术语。GitHub Desktop 的核心价值是把这些高频操作变成可视化按钮。你改了文件界面上直接显示每个文件新增删除了哪些行用绿色和红色标出来你想切换分支下拉列表里点击就行不用记git checkout -b feature/xxx这种带参数的命令你想把本地提交推到远程只需要点一下 “Push origin”连远程分支名、上游关系都帮你处理好。这种“所见即所得”的方式大幅降低了新手的学习门槛也减少了误操作的概率。有人会问那用了图形界面之后还需要学习命令行吗我的答案是需要但不是现在。图形界面做日常操作命令行做疑难杂症处理两者不冲突。等你在 GitHub Desktop 里理解了提交、分支、合并这些概念的本质再回头学命令行会发现那些命令其实就是图形界面背后同一套逻辑——只是换了种输入方式。所以 GitHub Desktop 不是用来替代学习的它是用来降低开始门槛的。1.2 和其他 Git 图形工具相比它到底强在哪市面上做 Git 图形界面的工具并不少Sourcetree、GitKraken、Tower、VS Code 自带的源代码管理面板我基本都试过。GitHub Desktop 和它们相比最大的优势是“和 GitHub 平台无缝衔接”。比如你登录之后可以直接 Browse 到自己的仓库列表一键 clone 下来推送分支之后界面上会出现 “Create Pull Request” 按钮点一下就直接跳转到 GitHub 网页的 PR 创建页面不需要自己复制 git remote 地址再跑去网页操作。另一个优势是性能和上传体积。GitHub Desktop 本身是用 Electron 技术栈做的占用内存不算低但日常操作响应很快尤其是对大仓库的 diff 展示它做了很多优化不会像某些工具那样打开一个几百 MB 的仓库就卡死。再加上它是 GitHub 官方维护功能迭代节奏跟得上平台变化比如对 GitHub Actions 的集成、对 Codespaces 的入口支持这些都是第三方工具短期追不上的。不过它也不是没有缺点。GitHub Desktop 目前只支持 GitHub 和 GitHub Enterprise 两种远程仓库平台如果你用的是 GitLab 或 Gitea 自建服务它会直接放弃。另外它不支持复杂的分支图形化显示比如说你假设在界面上看到类似 Sourcetree 那样的 commit 流向图GitHub Desktop 给你的是简化版的历史列表。总的来说它只专注于解决 GitHub 工作流里的核心问题而不是一个万能 Git 工具。2. 安装与初始化配置既然决定要用了第一步自然是怎么装、怎么登录、怎么把代码仓库拉到本地。这个过程比想象中简单但有些坑还是值得说一说。2.1 在 Windows 和 macOS 上安装Windows 和 macOS 的安装方式不太一样。macOS 用户可以打开 GitHub Desktop 官网下载 dmg 文件或者使用 Homebrew 执行brew install --cask github对于开发环境已经装了 Homebrew 的人来说命令行装工具比去网站下载要高效得多。Windows 用户则直接下载 exe 安装包双击运行按默认配置走完向导即可。安装过程中有两点需要留意。Windows 系统下GitHub Desktop 会自动帮你安装一个内置的 Git 环境也就是它不完全依赖系统全局 Git。这在某种程度上是好事因为有些 Windows 机器上旧版 Git 的路径配置有问题内置 Git 避免了环境变量冲突但也意味着你在 GitHub Desktop 里的提交作者信息和系统命令行 Git 可能不是同一套需要单独配置后面我会详细说。第二点是安装完毕后首次启动会询问是否和 Git 命令行关联如果勾选了之后在 GitHub Desktop 里点 “Open in Command Prompt” 或 “Open in Terminal” 就能直接打开对应目录的命令行窗口这个功能很实用建议勾上。装完之后界面会引导你进行 GitHub 账号登录。登录方式有两种一种是网页浏览器授权也就是在默认浏览器里打开 GitHub 登录页授权后桌面端自动关联另一种是手动输入 Personal Access Token。对于普通用户来说浏览器授权最方便点一下 Allow 就行。如果你开启了双重身份验证也会在网页流程里一起处理不需要额外去配置什么。2.2 登录账号并克隆第一个仓库登录之后你会看到一个欢迎界面上面有几个选项Clone a repository from the Internet、Create new repository、Add local repository。这其实就是你最常用到的三个入口。第一次使用的时候我建议直接用 “Clone a repository from the Internet” 来找一个已有的仓库练手可以是你自己在 GitHub 上创建的测试仓库也可以随便找一个开源项目。点击之后会弹出一个对话框会列出你能访问的所有仓库。你可以直接在搜索框里输入关键词快速筛选选中之后还需要选择本地存放路径。这一步有个小心得不要把仓库直接 clone 到桌面或下载目录最好建立一个统一的开发目录比如D:\ProjectsWindows或~/ProjectsmacOS这样以后管理多个项目时思路清晰。克隆完成后界面上会显示仓库当前所在分支、文件数量等信息。你可以直接看到仓库文件和本地文件系统的对应关系。从这里开始就算是正式进入日常操作流程了。2.3 设置提交身份信息避免提交人显示错误有一个很容易被忽略的步骤是 Git 的 user.name 和 user.email 设置。如果你在用 GitHub Desktop 之前在系统里装过 Git或者之前用命令行提交过代码那么全局配置里可能已经有旧信息。如果不一致提交历史里会出现“微信扫描二维码登录后没绑定邮箱”之类的奇怪问题。GitHub Desktop 里设置 Git 用户信息的方式非常隐蔽——它藏在 菜单 - OptionsWindows 或 PreferencesmacOS - Git 里。有的版本甚至叫 “Advanced” 标签需要手动填入 Name 和 Email。这里的邮箱不一定非要是 GitHub 的 noreply 邮箱但最稳妥的做法是打开 GitHub 网页端 - Settings - Emails把那个 “Keep my email addresses private” 选项下方的 noreply 邮箱地址复制下来填进去这样你的提交就和账号关联起来了而且不会暴露真实邮箱。如果你已经用错误的身份提交过若干次别急GitHub Desktop 同样支持修改历史中的作者信息但这个功能隐藏在 历史记录 - 右键选中的提交 - Amend Commit 里只针对最近一次提交有效。想要批量修改历史提交作者信息那就只能回到命令行用 filter-branch 或 filter-repo 来处理这里不展开反正记住了初始设置这一步做对了后面能省掉一堆麻烦。3. 核心界面一览与日常操作流程我见过不少教程用大段文字描述 GitHub Desktop 的界面但实际上界面结构很简单你把窗口打开之后从左到右、从上到下扫一眼就能明白个大概。不过话说回来能真正明白每个区域是干什么用的在什么场景下去点击它才是关键。这里我按实际操作角度来讲。3.1 解剖 GitHub Desktop 的主界面GitHub Desktop 的主界面可以分为几个区域顶部是当前仓库信息和同步操作按钮左侧是分支列表和仓库切换面板中间是文件变更列表和 diff 预览区域右下角的按钮则是提交相关的动作。顶部最左边有一个下拉框显示当前仓库名称。点击之后可以看到你本地所有的仓库列表用于快速切换不用每次用文件管理器去找目录。中间有个 “Current Branch” 下拉框显示当前分支名点击后可以切换分支、创建分支、以及查看所有远程分支。右侧是一排重要的功能按钮比如 Fetch origin、Pull、Push、Publish branch 等这些按钮根据当前仓库状态动态显示。左侧栏是变更文件列表。当你在本地改了文件之后所有变更会出现在这里。每个文件前面会显示一个状态标记修改过的文件是橙色圆点新增的文件是绿色加号删除掉的则是红色减号。点击任何一个文件中间区域就会显示这个文件的 diff 视图——改动前的行会标红并显示 “-” 符号改动后的行标绿并显示 “” 符号。左侧栏底部还有一个 “1 changed file” 之类的总览点开之后可以按文件类型或文件夹分组查看。这个界面设计有一个细节很值得点赞你可以在 diff 视图里直接编辑文件。大多数人知道在 IDE 里改代码但不知道在 GitHub Desktop 的 diff 里鼠标点击到某一行后是可以直接打字的改完保存后 diff 会实时刷新。这个功能适合做一些小修补比如调整配置文件里的一个端口号不需要再跳回编辑器。3.2 完成一次完整的提交从改文件到推送远程日常开发中最常用的操作就是提交。拿一个实际场景来说你在本地仓库里新建了一个 README.md 文件然后想在 GitHub 上保留一份。这个时候操作顺序是打开 GitHub Desktop - 看到未提交的 README.md 出現在变更列表里 - 在左下角的 Summary 输入框里填写提交说明比如 “Add README.md” - 点击 “Commit to main” 按钮。提交之后文件变更列表会清空历史记录里多出一条新提交。注意这时候远程仓库还看不到这个提交因为提交只发生在本地。接下来看右上角会有一个 “Push origin” 按钮点击之后本地提交才会推送到 GitHub。如果按钮没有出现说明当前分支的远程分支设置可能有问题或者本地没有新的提交可以推送。有一个关于提交说明的习惯建议你写的 commit message 最好在 50 个字符以内能够一句话说明改动了什么。如果改动较大也可以利用界面里的 “Description” 区域补充详细说明。GitHub Desktop 没有强制你遵守 Conventional Commits 规范但作为团队项目提交信息清晰与否直接影响后面看历史记录的效率。3.3 拉取最新代码Fetch、Pull 的时机与区别很多刚接触这工具的人分不清 Fetch 和 Pull 的区别。简单来说Fetch 是从远程仓库获取最新的提交信息但不会改动你本地的文件Pull 则是把远程最新的提交合并到你当前分支并更新本地文件。GitHub Desktop 对这两者做了整合界面上有一个 “Fetch origin” 按钮点击之后如果发现远程有更新并且本地没有冲突按钮会变成 “Pull”再点一次即可完成更新。比较典型的使用节奏是每天开工之前先点一下 Fetch origin看看远程有没有新提交准备开始干活之前拉一下最新代码保证自己不是基于过期的旧代码在修改写完代码准备推送之前再次 Fetch 并 Pull确保线上不会因为多人同时修改同一个文件而产生冲突。这个习惯能很有效地降低合并出错的概率。如果你发现 Fetch 之后按钮变成了带有数值提示的样式比如 “Pull 3” 或者 “Push 2”说明远程分支领先本地 3 个提交或者本地分支领先远程 2 个提交。这种提示等于帮你做了状态摘要不用每次都在命令行里敲git status去查看 ahead / behind。4. 分支管理与团队协作流程分支是 Git 最核心的概念之一可以理解成从主线上分离出来的独立开发空间。你用分支改代码不会影响主线上的稳定版本改完后合并回去就行。GitHub Desktop 把分支管理的整个操作做到了非常顺手的地步下面我结合真实的协作流程来讲。4.1 创建本地分支为每一个功能单独开一条线我见过很多新手直接在 main 分支上改代码改完就 push这种习惯在个人项目里还行但在团队项目里非常危险。正确的做法是每做一个功能或修一个 bug 就新建一个分支。在 GitHub Desktop 里新建分支非常简单点击顶部当前分支名的下拉框在底部输入新分支名称点击 “Create new branch”。分支命名我推荐使用feature/xxx、bugfix/xxx、docs/xxx这样的前缀方便从名字上判断用途。比如要做登录功能就建一个feature/login要修复首页样式问题就建一个bugfix/homepage-style。创建分支时有个选项“Checkout after create”是默认勾选的意思是一创建就切换到该分支。这一点很关键新创建的分支会复制当前分支的全部文件内容作为起点所以一定要确认你创建分支之前所在的分支是正确的。如果你在 main 分支上正在开发一个半成品功能这时候创建新分支半成品也会被带进新分支这是很多初学者容易踩的坑。4.2 把分支推送到 GitHub 并发起 Pull Request本地分支创建之后你在这个分支上完成了功能开发和提交。接下来想把这部分代码分享给团队点一下界面上的 “Publish branch” 按钮有的版本叫 “Publish”本地分支就被推送到远程 GitHub 仓库并建立跟踪关系。推送之后界面会出现一个 “Create Pull Request” 按钮。点击会自动打开 GitHub 网页端并预填好 source branch当前分支和 target branch通常是 main 或 dev 分支你在网页里填写 Pull Request 标题和描述再点击确认就可以发起代码审查请求。整个流程从本地到远程再到 PR完全无缝。这里有个体验很好的点GitHub Desktop 还会显示当前分支和 main 分支之间的领先/落后情况。比如说你在本地写了一堆 commit 还没有推界面上会显示 “This branch is 3 commits ahead of main”非常直观。如果这些 commit 中间有需要调整的地方你也可以在历史记录里右键选择 “Revert” 或 “Cherry-pick”这些高级操作不需要命令行也能完成。4.3 本地分支清理合完 PR 后怎么保持整洁每个 PR 合并之后远程分支一般会由仓库管理员删除但你本地可能还保留着那个分支。GitHub Desktop 在分支下拉列表里会用一个灰色的图标区分远程已删除的本地分支。你可以在分支列表底部点击 “Choose…” 来查看所有分支或者在分支上右键选择 “Delete” 来删除本地分支。删除本地分支之前要确认当前不在该分支上否则 Git 是不允许删除的。另一个小技巧是在分支列表里点击排序方式的筛选可以把“My branches”本地分支和“Pull Requests”远程 PR 相关分支分开显示。养成顺手清理旧分支的习惯能让你在切换项目时快速找准目标分支不会在几十个分支里迷失方向。5. 历史记录、冲突处理与回滚操作做开发不可能永远一帆风顺改错代码、合并时撞车、提交了不该提交的文件这些问题谁都遇到过。GitHub Desktop 在这方面的解决思路是把“回溯”和“修复”变得可视化你不用在命令行里背语法只需要理解概念然后点击对应按钮。5.1 查看提交历史读懂每一次代码变更点击仓库主界面上方的 “History” 选项卡就能看到当前分支的完整提交历史。每条提交会显示 commit message、作者头像、提交时间和哈希值。点击某一条提交右侧会列出这次提交涉及的所有文件变更以及详细的 diff 内容。查看历史的实用场景很多一种是“排查代码从哪个版本开始出了问题”你可以沿着历史记录从新到旧逐条点击比对文件内容变化另一种是“想知道某个文件为什么被改成这样”你可以直接在文件树里右键看文件历史或者通过提交信息里的关联 issue 编号去 GitHub 网页查看完整讨论。GitHub Desktop 还支持直接在当前分支历史里通过搜索框过滤提交信息找起来非常快。5.2 冲突是怎么产生的以及如何在图形界面中解决冲突几乎每个用 Git 的人都会遇到。简单来说它发生在你和别人改了同一个文件的同一块内容然后合并时 Git 不知道听谁的。GitHub Desktop 检测到冲突时会在界面上弹出一个提示告诉你 “We couldn’t automatically merge these branches”然后列出有冲突的文件列表。这时候你点击有冲突的文件可以在 diff 视图里看到类似这样的内容 HEAD 这是当前分支的代码 这是要合并进来的分支的代码 feature/xxx你需要手工决定最终保留哪部分可以只保留上方或下方也可以把两段内容都留下来整合成一个新的逻辑。修改完成后删除掉、、这三行标记再保存文件。但注意一个细节在 GitHub Desktop 的 diff 页面里直接编辑冲突标记保存后界面会自动检测到文件内容更新但你还需要重新添加暂存并提交GitHub Desktop 通常会显示一个提示条告诉你冲突已解决点击 “Commit merge” 按钮确认合并提交即可。关于处理冲突有一条非常管用的实战建议不要只在自己本地凭感觉处理冲突。如果冲突涉及的代码不是特别明确最好去 IDE 里打开文件结合上下文和周边的代码结构来判断哪个版本更合理。因为 diff 视图里只显示冲突片段很多上下文都被隐藏了盲目保留某一段很容易破坏代码逻辑。5.3 回滚误操作撤销提交和恢复已删除内容还有一种常见场景是你刚提交完发现里面少了关键文件或者提交信息写错了。在 GitHub Desktop 里选择历史记录里最近一次提交点击右键会出现两个选项Amend Commit和Revert。Amend 的意思是修改最近一次提交比如可以添加漏掉的文件、修改说明文字然后重新提交相当于用新提交替代旧提交。Revert 则是创建一个新的提交把这个提交的改动逆过来也就是“撤销”但保留历史轨迹。这两种方式在已经推送远程的状态下都可以使用但 Revert 更适合团队协作场景因为它不会重写历史不会导致别人 pull 时出问题。如果你修改了一个文件但还没提交就想要撤销改动可以在变更列表里右键该文件选择 “Discard Changes”这等于把文件还原到最近一次提交时的状态。注意这个操作不可恢复所以 Git 一般都会弹出一个确认框一定要看清提示再点确定。还有一点如果你误删了本地文件只要这个文件之前有提交记录GitHub Desktop 的变更列表里会以红色删除标记显示你可以直接右键选择 “Discard Changes” 来恢复如果没有提交记录那就只能靠编辑器或文件系统的回收站了。5.4 暂存临时修改Stash 的图形化替代方案有时候你可能正在一个分支上改代码突然需要切到另一个分支去处理紧急问题但当前这个分支的修改还不想提交。命令行里你需要git stash而在 GitHub Desktop 里这个功能默认是隐藏的。在左侧栏底部有三个小点组成的按钮点击后可以选择 “Stash all changes”GitHub Desktop 会把当前所有未提交的更改保存成一个暂存记录然后工作区恢复干净状态。等你切回来之后可以在底部同样的位置点击 “Restore Stash” 来恢复暂存的更改。我实际用下来觉得它的设计还算清晰但没有命令行 stash list 那种多个暂存记录的管理界面所以在同一个时刻只保留一份未提交修改的场景下体验最好。如果你需要保存多个暂存堆栈那可能还是得回到命令行。6. 实用技巧、常见问题与避坑指南GitHub Desktop 做日常开发绰绰有余但也有些操作细节和容易踩的坑是官方文档不会重点标注的。我根据自己的长期使用经验在这部分进行一次系统整理。6.1 好用但容易被忽略的小功能第一个是集成 GitHub Actions 的工作流。如果你在仓库里配置了 CI/CD推送代码之后可以在 GitHub Desktop 顶部的 Actions 图标查看运行状态。点进去会展示 workflow 的运行列表失败的 workflow 会以红色显示点进去就能看到具体哪个步骤报错。不用跑到网页端刷新页面这个体验非常顺滑。第二个是Copy SHA。在历史记录里右键任意提交选择 “Copy SHA”就能复制这个提交的完整 40 位哈希值。跳转到 GitHub 网页查看某个特定提交或者需要把 commit 哈希贴到 issue 里做关联时这个功能特别省事。第三个是Repository menu。菜单栏里的 Repository 下拉菜单集中了不少高级功能包括Open in Visual Studio Code、Open in Command Prompt、View on GitHub、Remove repository from Desktop等。尤其是 “Open in Visual Studio Code”它会用当前仓库根目录启动 VS Code不用手动操作文件系统去定位目录。6.2 认证方式选择HTTPS 还是 SSH很多老玩家偏爱 SSH 方式认证因为不用每次输入密码如果配置了密钥。但 GitHub Desktop 用 HTTPS 也完全没问题因为它基于系统钥匙串Windows 的凭据管理器保存凭据首次登录之后后续操作都是全自动的不需要重新输入密码。如果你在电脑上使用 GitHub Desktop 并且想继续用命令行 Git建议把系统安装 Git 时自动生成的全局凭据管理器和桌面版配置的凭据保持一致性。如果你打算手动使用 SSH过程也很简单先用命令行生成 SSH key然后把公钥添加到 GitHub 账号设置里。之后在 GitHub Desktop 克隆仓库时需要在仓库的 URL 地址里手动改成gitgithub.com:user/repo.git这种格式或者在克隆对话框里点击 “Choose…” 时直接输入 SSH URL。GitHub Desktop 本身不会强制要求你选择哪种协议但它支持两种而且会自动识别。我的实际感受是HTTPS 对大多数情况下最省事SSH 更适合你需要在多台设备之间复用同一套密钥的场景。6.3 常见问题速查认证失败、仓库过度膨胀和文件忽略这里整理一个常见问题速查表覆盖我日常最常被问到的几个问题。问题现象原因分析解决办法推送时提示 Authentication failed登录凭据过期或 GitHub 账号开启了双重认证后 token 失效在系统设置里找到 Windows 凭据管理器或 macOS 钥匙串删除旧的 GitHub 凭据然后重新通过浏览器授权登录仓库显得特别大克隆和操作都很慢仓库里有大文件长期提交比如视频、模型文件、日志在仓库根目录添加.gitignore忽略掉这些文件已误提交的大文件需要使用 Git LFS 迁移或借助官方反馈工具处理本地修改无法推送到远程报错提示 non-fast-forward远程分支领先于本地分支存在需要合并的历史先点击 “Fetch origin” 再 Pull 最新代码合并完成后再推送如果 Pull 出现冲突按上文冲突解决步骤处理某类文件始终不出现在变更列表里该文件被 .gitignore 规则排除了打开仓库目录下的 .gitignore 文件删除对应规则如果确实想强制提交可以在历史记录或文件浏览器里手动删除忽略限制但一般不建议这么做提交人显示不是自己的 GitHub 账号本地 Git 配置里 user.name 和 user.email 与 GitHub 账号不一致前往 GitHub Desktop 的 Options - Git正确设置身份信息已有历史提交可以用 Rebase 或个人参数强制修改6.4 让你的 GitHub Desktop 更顺手的几个技巧除了上面这些常见问题我再分享几个利用 GitHub Desktop 提升工作效率的手法。第一个是善用文件过滤和搜索。当一次变更涉及几十个文件时左侧栏顶部的搜索框可以直接按文件名过滤你再也不用在一长串列表里一个个找。第二个是养成一致的提交节奏。与其憋一个大提交把一堆不相关的改动混在一起不如小步快跑每完成一个独立的小功能就提交一次这样后续排查问题会轻松非常多。第三个是熟悉右键菜单。GitHub Desktop 里几乎所有文件、提交、分支都有右键菜单很多你以为是隐藏功能的操作其实藏在里面。我统计过右键菜单里触发频率最高的是 “Reveal in File Explorer” 和 “Copy Path”一个用来快速定位文件一个用来拿到文件的完整路径。7. 从入门到熟练我的个人体会GitHub Desktop 本质上不是一个“菜鸟专用工具”而是一个非常聪明的 Git 工作流加速器。它把 Git 最常用、最需要判断的操作从命令行抽象成界面交互让用户把脑力集中在代码本身而不是命令语法和错误提示上。在实际使用中我最大的感受是它帮我养成了更好的 Git 习惯。以前用命令行时我经常因为嫌麻烦而跳过分支管理直接在 main 上开干现在创建分支只需一次点击拉取更新只需一次点击成本极低所以我会更愿意为每一个小功能开分支、写清晰提交说明、及时推送。时间久了仓库历史变得干净而有逻辑团队成员协作起来也顺畅得多。如果你是一个刚开始接触 GitHub 的初学者我建议你从 GitHub Desktop 起步先把 clone、commit、push、pull、branch 这些核心操作练熟等你对 Git 的概念有了肌肉记忆再考虑去挑战命令行。如果你已经有几年的命令行经验也不妨给它一次机会像我现在这样很多日常操作已经不再去终端敲命令了。最后分享一个我自己常用的小流程每天早上到工位的第一件事就是把所有项目的仓库依次打开点击 Fetch origin看看哪些项目有更新然后根据更新情况决定是先处理 PR 备注还是先开发新功能。这套操作在 GitHub Desktop 里只需要几秒钟就能完成不需要切换终端、不需要记忆命令就已经有了一个非常流畅的开端。希望这篇教程能帮你在 Git 的使用路上少踩几个坑多省一些时间。