新手学 Git，最常问的问题之一：用 GitHub Desktop 还是命令行？我的答案很明确：先 Desktop，再命令行。理由下面细说。

GitHub Desktop：看得见的操作

GitHub Desktop 是官方出的图形化客户端，把 Git 的常用操作做成了按钮：

  • 优点：所见即所得。分支、提交历史、文件变更都图形化展示，新手一眼看懂"分支"到底是什么。提交、推送、拉取、处理合并冲突，点几下就行，基本不会误操作。
  • 缺点：高级操作覆盖不全。变基、cherry-pick、 reflog 救场这类场景，还是得回命令行。
  • 适合谁：刚接触 Git 的人，或者主要做文档、小改动的贡献者。对他们来说，Desktop 的功能绰绰有余。

命令行：无所不能，但要先理解概念

git clone/add/commit/push 这套命令，是 Git 的"母语"：

  • 优点：功能完整，任何操作都能做。服务器、教程、CI 环境里全是命令行，学会了一通百通。而且出问题时，命令行的报错信息最完整，排查全靠它。
  • 缺点：看不见摸不着。新手很容易在 detached HEAD、rebase 冲突这种概念上卡住，一步错步步错，挫败感极强。
  • 适合谁：要长期写代码、和团队协作、玩开源的人——早晚都得会，逃不掉的。

对比一览

维度GitHub Desktop命令行
上手难度低，半小时能用中，需要理解概念
日常提交推送完全够用完全够用
复杂操作部分缺失全部支持
出错时排查提示有限信息完整
服务器/CI 环境用不上必须会

命令行必学的 8 个命令

等你准备好学命令行，先掌握这 8 个，能覆盖 90% 的日常：

clone 拉代码，status 看状态，add 暂存，commit 提交，push 推送，pull 拉取，branch 看分支，checkout -b 建分支。别的一次性记不住，用到再查，正常。

实战：同一个任务，两种走法

假设你要给某个仓库改一行文档，看看两种工具分别怎么做：

Desktop 版：打开 Desktop，确认当前分支 → 改文件 → 左侧 diff 里确认变更 → 填 commit 信息点提交 → 点 Push → 去网页点提 PR。全程可视化，每一步都知道自己在哪。

命令行版：git checkout -b fix-doc → 改文件 → git diff 确认 → git add . → git commit -m "..." → git push origin fix-doc → 去网页提 PR。步骤一样，但每一步都靠你自己确认状态，一个 git status 按习惯了就离不开了。

你会发现流程完全对应：Desktop 的每个按钮，背后都是一条命令。这也是为什么先 Desktop 再命令行的顺序如此顺滑——你学的不是两套东西，是一套流程的两种表达。

我的建议：先 Desktop 理解概念，再学命令行

顺序很重要。先用 Desktop 把"提交、分支、合并、推送"这套流程走顺，在图形界面里亲眼看到分支分叉又合并，概念就立住了。有了概念，再去学对应的命令，会发现命令只是在重复你已经理解的事情，学起来飞快。

反过来，先啃命令行的人，十个有九个在前两周就被各种报错劝退——不是他们笨，是缺少一个直观的心理模型。对着黑窗口背命令，和看着分支图理解概念，完全是两种难度。

等你用 Desktop 提过几个 PR（流程见《如何给开源项目提第一个 PR》），再花一个周末学命令行，基本一天就能上手日常命令。最终形态是两条腿走路：平时图快用 Desktop，关键时刻命令行兜底。我认识的老手，十个有八个都是这么用的。