Git官方藏了150个命令，开发者只用到这20个

Git有150个命令。日常开发中，你真正需要的不到20个。剩下的130多个，多数人三年也用不上一次。

这不是能力问题，是信息过载。就像智能手机的隐藏功能——你知道它存在，但找不到入口，最后干脆不用。

这篇整理基于2026年最新实践，覆盖从项目初始化到团队协作的完整链路。所有命令经过真实项目验证，去掉冗余参数，保留最高频场景。

配置：一次设置，长期受益

新环境的第一件事，不是写代码，是告诉Git你是谁。这三行配置会写入全局文件，后续所有提交自动带上身份标识。

git config --global user.name "Your Name" git config --global user.email "you@example.com" git config --global init.defaultBranch main

默认分支名从master改为main是2020年后的趋势，提前统一避免团队协作时的冲突。pull.rebase设为false则保留传统的merge行为，对新手更友好——rebase的线性历史虽然好看，但操作失误时回退成本更高。

进阶用户会配置可视化diff工具。VS Code集成度最高，执行git difftool时直接唤起侧边栏对比，不用在终端里逐行辨认颜色代码。

git config --global diff.tool vscode git config --global merge.tool vscode

配置完成后，git mergetool会自动打开三方对比视图：本地修改、远程版本、合并结果并排显示，冲突标记一目了然。

项目启动：两种入场方式

从零开始和接手现有项目，命令组合完全不同。

本地新建项目的标准流程：初始化→添加文件→首次提交→关联远程→推送。最后一步的-u参数会在本地main分支与远程origin/main之间建立追踪关系，后续直接git push即可，无需重复指定分支。

git init git add . git commit -m "Initial commit" git remote add origin https://github.com/you/repo.git git push -u origin main

克隆现有仓库更常见。默认情况下，仓库名会成为本地文件夹名。如果项目叫frontend-dashboard，你的路径就会变成./frontend-dashboard。指定第二个参数可自定义：

git clone https://github.com/user/repo.git my-folder

这个技巧在同时维护多个版本时特别实用——比如原仓库、自己的fork、以及客户的私有镜像，分别命名为upstream、origin和client，切换时不会混淆。

日常循环：status-diff-add-commit的四拍节奏

开发者的肌肉记忆应该围绕这四个命令建立。它们构成一个完整的反馈闭环：查看状态→确认改动→选择提交→持久化记录。

git status的输出分为三个区域：未追踪文件（Untracked）、已修改但未暂存（Changes not staged）、已暂存待提交（Changes to be committed）。颜色编码已经暗示了下一步动作——红色需要add，绿色可以commit。

diff命令有两个变体。默认的git diff显示工作区与暂存区的差异，也就是你改了但还没add的内容。加上--staged后对比的是暂存区与最新提交，用于最后检查即将入库的代码。

git diff # 工作区 → 暂存区 git diff --staged # 暂存区 → 最新提交

add命令的-p参数被严重低估。它进入交互模式，把改动拆分成多个hunk（代码块），让你逐块确认是否加入暂存区。这在部分提交时 indispensable——比如同时修复了bug和调整了格式，只想把前者提交，后者留到下次。

commit的-am是偷懒写法，只对已追踪文件有效（即之前被add过的文件）。新建文件必须先add，这是最常见的"我提交了但文件没上去"事故原因。

fetch与pull的区别值得花时间理解。fetch只下载远程数据，不修改本地分支；pull则是fetch+merge的缩写。在团队协作中，先fetch查看远程变化再决定如何整合，比直接pull更安全——尤其是当你本地有未推送的提交时。

分支策略：checkout与switch的世代交替

Git 2.23版本（2019年8月）引入了switch和restore，意图分离原本混杂在checkout中的功能。但六年过去，老命令依然广泛使用，因为 muscle memory 难以改变。

创建并切换分支，新旧语法对比：

git checkout -b feature/user-auth # 传统 git switch -c feature/user-auth # 现代

switch的语义更清晰：专门处理分支操作，不会误触文件恢复功能。checkout则像个瑞士军刀，-b创建分支、--文件路径恢复文件、不加参数切换分支，参数顺序错了就可能产生非预期行为。

分支列表的三个维度：

git branch # 本地分支 git branch -r # 远程分支 git branch -a # 全部

删除操作的安全边际设计得很细。-d（delete）只允许删除已被合并的分支，防止丢失工作。-D（大写）是强制删除，用于舍弃实验性分支。远程删除需要单独执行，git branch -d不会同步到origin。

后悔药：reset的三种剂量与revert的安全线

版本控制的核心价值不是保存历史，而是允许犯错。Git提供了不同强度的"撤销"工具，对应不同的后悔程度。

reset命令的三种模式，从温和到激进：

git reset --soft HEAD~1 # 撤销提交，改动保留在暂存区 git reset HEAD~1 # 撤销提交，改动退回工作区 git reset --hard HEAD~1 # 撤销提交，改动彻底消失

HEAD~1表示"当前提交的前一个"。soft模式适合提交后发现漏了文件，补充后重新提交；mixed模式（默认）让你重新选择哪些改动进入下次提交；hard则是核武器，执行前建议先git stash备份。

单文件撤销有两个选择：

git checkout -- file.js # 传统 git restore file.js # 现代（Git 2.23+）

restore的语义同样更清晰：专门用于恢复文件，不会与分支切换混淆。两者都会丢弃工作区的未提交改动，执行前确认不需要这些修改。

revert是团队协作的安全阀。它不会改写历史，而是创建一个新的"反向提交"——比如原提交加了10行代码，revert就生成一个删除这10行的提交。push到共享分支后，队友pull时不会遇到"历史分叉"的冲突。

git revert abc1234

abc1234是提交哈希的前7位，足以唯一标识。revert会自动弹出编辑器让你修改提交信息，默认格式是"Revert '原提交标题'"。

amend用于最后一刻的修补。提交后发现message打错字？git commit --amend。漏了一个文件？add后再amend。它会替换最后一次提交，如果已经push到远程，需要force push才能同步——这在共享分支上是危险操作。

stash：打断工作的优雅方式

开发中途被紧急打断，是程序员的高频场景。stash把当前工作区打包成一个临时存储，让你干净地切换到其他分支，处理完后再恢复。

基础用法足够应对90%的情况：

git stash # 默认消息：WIP on branchname git stash push -m "WIP: user auth" # 自定义消息

带消息的stash在列表中更易辨认。默认的"WIP on main"三天后就忘了是什么内容，"WIP: user auth"直接提示上下文。

恢复时有两种策略：

git stash pop # 应用并删除stash git stash apply stash@{0} # 应用但保留stash

pop是一次性恢复，适合确定stash内容已完整取回。apply则允许重复应用，或者在恢复后发现有问题、需要再次stash时，不会丢失原始备份。

stash的存储结构是栈（LIFO），stash@{0}始终是最新的一条。长期不清理会导致列表臃肿，git stash drop删除单条，git stash clear清空全部。

一个细节：stash只保存已追踪文件的改动。新建文件（Untracked）默认不会被stash，需要加-u参数才能包含。这是"我stash了但文件不见了"的常见原因。

命令选择的隐性成本

这篇清单的筛选标准不是"功能最全"，而是"认知负荷最低"。每个命令都对应明确的意图，参数数量控制在3个以内，降低记忆负担。

实际观察中，开发者的Git熟练度呈现两极分化：要么只会add/commit/push三板斧，遇到冲突就重建仓库；要么沉迷炫技，用rebase -i把提交历史整理得像艺术品，却花了两小时在会议前整理代码。

健康的使用习惯是识别自己的高频场景，把对应命令练成肌肉记忆，其余功能知道存在即可。需要时查文档，比强行记忆所有参数更高效。

Git的设计哲学是"给你足够长的绳子，自己决定要不要上吊"。150个命令是绳子，这20个是安全带。

你现在的日常Git流程中，哪个命令的使用频率和它的学习成本最不匹配？