Git 这个东西，说难不难，说简单也真不简单。我见过不少人把add和commit背得滚瓜烂熟，可是一遇到分支合并、代码冲突、提交撤销就手足无措，最后只能靠复制粘贴网上的命令来救急，运气好没事，运气差直接把同事的代码搞没。其实 Git 的常用操作命令就那二十来条，关键不是死记硬背，而是理解它们背后那套"三板斧"式的数据模型。你只要搞清楚工作区、暂存区、版本库三个状态是怎么流转的，再配合几条高频命令，日常开发 95% 的场景都能稳稳拿捏。

这篇内容适合刚接触 Git 的新手，也适合已经写了一年半年代码、但对某些命令只会"照抄用法"的开发者。我会把命令分成"状态查看、日常提交、分支合并、远程协作、撤销恢复、问题排查"六个维度来讲，每个命令都告诉你它解决什么问题、什么时候用、有哪些坑。全程没有任何学术腔，全是实战时踩过坑之后整理出来的要点，希望你看完能建立一套自己的 Git 操作套路，而不是继续当"命令搬运工"。

1. 想用好 Git，先搞清楚这棵"树"是怎么长的

1.1 工作区、暂存区、版本库到底在说什么

很多人第一次学 Git 就被三个概念搞晕：工作区（Working Directory）、暂存区（Index / Staging Area）、版本库（Repository）。我用一句话帮你记住它们的分工：工作区是你眼睛看到的文件，暂存区是你要打包进快照的购物车，版本库是已经封箱入库的货物。

你写代码时修改的是工作区文件；git add把修改内容放进暂存区；git commit把暂存区内容固化成一次提交，写入版本库。这个过程很像一个物流仓库——货物先放到暂存架上待验，验完才入正式库存。理解了这一点，后面所有命令都变得顺理成章：git status是检查当前各区域的状态，git diff是对比不同区域之间的差异，git restore则是把某个区域的内容回滚到另一个区域的状态。

新手最容易犯的错误就是在git add之后发现改错了，然后到处找"撤销 add"的命令。其实根本不用焦虑，暂存区只是准备区，改错了随时可以重新add覆盖，或者用git restore --staged把暂存区内容退回工作区。只要你清楚每个命令动的是哪个"区域"，就不会越操作越乱。

1.2 提交、分支、HEAD 三者的关系

版本库里的每一次提交（commit）都是一个不可变的快照，包含作者、时间、提交信息和一串唯一的哈希值。分支（branch）本质上只是一个指向某个提交的可移动指针，而 HEAD 则是"你当前站在哪里"的指针，通常指向某个分支的最新提交。

这种设计带来一个很重要的推论：你切换分支时，Git 做的事情只是移动 HEAD 指针、并同步更新工作区文件。它并不是把代码复制来复制去。所以分支切换非常轻量，这也是为什么 Git 鼓励"多建分支、频繁合并"——创建分支的开销几乎可以忽略不计，大胆开分支不会把仓库搞爆炸。

日常工作中我见过很多人不敢用分支，总觉得自己代码还没写完，冒然切分支会把半成品弄丢。这种担心其实多余。只要你的工作区改动没有冲突，git switch会帮你带上改动；如果确实有冲突风险，Git 会明确报错阻止你切换，绝不会偷偷丢文件。我在后面第 5 节会专门讲git stash，那就是为"没写完就想切分支"这种场景准备的。

2. 日常开发高频命令实操，先把手感练出来

2.1 状态三件套：status、log、diff

git status是我使用频率最高的命令，没有之一。我建议你每次敲别的 Git 命令之前，先敲一次git status，看清楚当前站在哪个分支、哪些文件被改过、哪些已经进入暂存区。很多时候你以为自己在 A 分支，实际却在 B 分支，一个status就能当场揭穿。

git log用来查看提交历史。裸的log输出信息太多太挤，我实际使用中几乎总是配合参数：git log --oneline只看一行摘要，git log --graph --oneline --all查看所有分支的网状关系，git log -p查看每次提交的具体改动内容，git log --author=用户名筛选某个人的提交。查最近几条提交用git log -3，查某个文件的变更历史用git log -- 文件名。这些参数不用全记，用到时能想起来"log 有这个能力"就行。

git diff是精确到行的差异查看器。git diff比较工作区和暂存区，git diff --staged（或--cached）比较暂存区和上一次提交，git diff HEAD则比较工作区全部改动和最后一次提交的差距。排 bug 时我经常用git diff快速确认"这次到底改了什么"，尤其是在多个文件混改的情况下，比肉眼翻代码靠谱得多。

2.2 提交动作的标准姿势：add、commit

git add可以接单个文件、多个文件、整个目录，也可以用.把所有改动加入暂存区。我看到不少初学者一上来就git add . && git commit -m "update"，这种做法很容易把临时文件、调试日志、敏感配置一起提交上去。更稳的做法是git add时明确指定文件，或者先用git status扫一眼再决定。养成"看清楚再 add"的习惯，能避免很多社死现场。

如果想要更精细地控制提交内容，可以使用git add -p（patch 模式），它会把一个文件内的不同改动逐块展示，让你选择哪些块加入暂存区、哪些块暂不加入。一个文件里同时修改了两处不相关的功能时，这个功能非常好用，可以让每次提交保持逻辑单一。

git commit提交时需要注意两点。一是提交信息要写清楚"为什么改"，而不是"改了什么"，比如fix: 修复登录接口在空密码时返回 500就比update强得多。二是一次commit只做一件事，别把"修 bug"和"重构代码"混在一个提交里，否则以后git log回溯时你会非常痛苦。如果提交后发现漏了一个小改动，不想为此新增一条提交记录，可以用git commit --amend把当前暂存区的改动合并进上一次提交，注意这种方式会改写提交历史，已经推送到远程并且他人拉取过的分支要谨慎使用。

2.3 分支管理基本功：branch、switch、checkout

git branch查看本地分支列表，当前分支前面会有一个星号。git branch 新分支名基于当前 HEAD 创建新分支；git branch -d 分支名删除已合并的分支；如果分支还没合并又想强删，用-D，但要先确认里面的提交真的不要了。

切换分支我主推git switch而不是老牌的git checkout。git switch -c 新分支名表示创建并切换，两步合并成一步。git checkout因为身兼"切分支"和"还原文件"两个职责，新手很容易误用——比如git checkout .会把工作区所有未提交的改动直接丢弃，我还真见过有人手滑执行完当场崩溃。相比之下git switch只管切换分支，语义清晰，更不容易出事故。

在实操中我还会用到git worktree add，它可以让你同一仓库同时检出多个分支到不同目录。场景是：你在 A 分支开发到一半，B 分支线上出了紧急 bug 要立刻修，但不想 stash 打断思路。开一个 worktree 到另一个目录，互不干扰。这属于进阶操作，但确实好用，建议了解。

3. 分支合并与冲突处理，把最头疼的部分讲透

3.1 合并前的准备工作

合并之前先确认两件事：当前所在分支是否正确、工作区/暂存区是否干净。用git status检查，如果有未提交的改动，最好先git commit或者git stash，避免合并过程中产生混乱。我犯过的错误是没提交就在分支上执行 merge，结果 Git 提示"本地改动会被覆盖"直接拒绝合并，虽然安全，但那一刻有点手足无措。

git merge有两种常见结果。快进合并（Fast-forward）发生在目标分支没有新的提交、当前分支可以直接"指针前移"时，历史会呈现一条直线。非快进合并（Three-way merge）发生在两个分支都有各自新提交时，Git 会生成一个额外的合并提交，历史呈现分叉后再汇合。如果希望保留分叉痕迹、明确记录"这里有过一次合并"，可以加--no-ff强制生成合并提交；反过来说，后台维护型项目为了历史清爽，可能会刻意用--ff-only拒绝创建合并提交。

3.2 冲突产生的原理与解决步骤

冲突的本质是两个分支修改了同一处代码，Git 无法自动判断该保留谁，只能交给人类裁决。看到"CONFLICT (content)"字样不要慌，这不是天塌了，只是 Git 在向你汇报：这块代码需要你拿主意。

解决冲突的标准流程是：先用git status找出冲突文件（状态为 Unmerged），打开这些文件，里面会出现类似下面的标记：

<<<<<<< HEAD 这里是当前分支的内容 ======= 这里是合并进来的分支的内容 >>>>>>> feature/login

你要做的是把矛盾区域改成最终想要的样子，然后删掉<<<<<<<、=======、>>>>>>>这三行标记。改完后执行git add把该文件标记为已解决，全部解决完再执行git merge --continue（在旧版本可能需要直接git commit），一个解除冲突的合并提交就诞生了。

这里有个非常实用的建议：解决冲突时，不要只盯着自己写的代码，一定要花十秒钟想想对方为什么这么改。实战中很多冲突根因是双方都改了同名的工具函数，这时"合并"不是简单的二选一，而是理解两边需求后做一个兼容双方对共识实现。如果修改文件的逻辑较大，宁可把同事拉来当面沟通，也不要自己拍板写完就提交。

3.3 merge 还是 rebase，怎么选

git rebase和 merge 的目标都是整合分支，但思路截然不同。merge 保留分叉让历史"忠实"，rebase 则是把你这条分支上的提交一个个"重放"到目标分支的顶端，让历史变成一条干净的直线。视觉上，rebase 后的 log 非常清爽；代价是改写提交哈希，一旦分支已经被别人拉取，强制 rebase 会导致对端历史错乱。

我的选择原则是：本地分支还没推送远程、或者只有自己在开发的分支，放心用 rebase 整理历史；已经推送远程并且多人共用的分支，只用 merge，绝不用 rebase 强行改写历史。场景上，从主分支同步最新代码到自己的功能分支时，git pull --rebase比git pull更常用，因为它避免了大量无意义的"merge main into feature"提交。

执行 rebase 时同样可能遇到冲突，解决方式跟 merge 冲突基本一致：改文件、git add、然后git rebase --continue。如果 rebase 越整越乱，想放弃当前操作回到 rebase 之前的状态，用git rebase --abort，它会把你安全送回起点，这一点比手动重置省心太多。

4. 远程仓库协作：clone、remote、fetch、pull、push

4.1 一次完整的远程协作流程

git clone是把远程仓库完整复制到本地，包含所有分支的引用和完整历史。注意clone之后，默认你只在默认分支上工作，其他远程分支要在需要时用git switch 分支名或git checkout --track建立本地跟踪分支。

对于已经存在本地仓库、需要关联远程的情况，用git remote add origin <仓库地址>。git remote -v可以查看当前配置的远程地址。一个仓库可以配多个远程，分别命名为 origin、upstream 等，这对于 Fork 协作很关键——origin 指向你自己的副本，upstream 指向上游原仓库，需要同步上游更新时git fetch upstream。

首次推送本地分支到远程，标准命令是git push -u origin main。其中-u是--set-upstream的缩写，作用是建立本地分支和远程分支的跟踪关系。建立之后，后续直接敲git push或git pull就能自动匹配对应的远程分支，不用每次都带全参数。

4.2 fetch 和 pull 的区别，别再混着用了

git fetch只把远程的最新提交和分支信息下载到本地，不动你当前的工作区。git pull则是git fetch加上git merge的合体，直接试图把远程分支合并进当前分支。

理解这个区别很重要。很多人习惯一上来就git pull，但 pull 实质上有"合并"动作，如果你的本地有未提交的改动且与远程改动冲突，pull 会直接失败报错。稳妥的流程是：先git fetch看看远程发生了什么，再决定是 merge 还是 rebase，最后才考虑真正合并。尤其是参与多人协作项目时，fetch + diff + pull三步走，能让你对每一次远端变化心里有底，而不是被 pull 的不确定性牵着鼻子走。

4.3 远程分支的同步与清理

git push时如果远程分支被别人先推了新提交，你的推送会被拒绝，提示"non-fast-forward"。这时不要莽撞加--force强推，因为强推会覆盖他人的工作，属于高危操作。正确做法是先git pull --rebase拉取最新代码，解决冲突后再推送。如果确实需要强推（比如你刚推送的提交发现有敏感信息需要改写），用git push --force-with-lease会比裸--force安全很多，它会在强推前检查远程分支是否被你最近获取过的状态之外的新提交改动，多一层保护。

清理远程分支方面，合并完的功能分支可以用git push origin --delete 分支名删除远程分支，本地分支用git branch -d 分支名删除。本地仓库里还留着远程已经删除的分支引用，可执行git fetch --prune（或git remote prune origin）清理。这个操作建议定期做，否则本地积累一堆幽灵分支引用，看 log 时会非常困惑。

5. 撤销与恢复命令大盘点，改错了有救

5.1 工作区改乱了：restore 和 checkout

撤销没有add过、仅存在于工作区的改动，最简单的是git restore 文件名，等价于老命令git checkout -- 文件名。如果你想把某个文件恢复到某个历史提交的状态，用git restore --source=提交哈希 文件名。注意这类操作是不可逆的，执行前确认那个文件里没有你想留的修改，建议先git diff看一眼再动手。

如果改动已经add进了暂存区但还没提交，想退回工作区使用git restore --staged 文件名，这只会让文件状态从暂存区移除，不会动文件内容。你可能会发现学会这一条后，之前网上那些"git rm --cached"的偏方基本用不上了。另外git rm有它自己的用途，但"撤销 add"不是其中一个。

5.2 已经提交了：reset 还是 revert

提交后发现写错了，你有两条路：git reset和git revert。区别核心在于：reset 是移动当前分支指针、相当于"回退时间线"；revert 是生成一个新的反向提交、相当于"用一次新提交抵消旧改动"。

git reset有三个常用级别。--soft只移动 HEAD 回到目标提交，改动全部留在暂存区；--mixed（默认）把改动退回工作区；--hard直接丢弃所有改动，工作区、暂存区、分支指针全部回到目标提交状态。--hard是条单行道，执行前必须确认，最好git log记下当前提交哈希，万一后悔还能用git reset --hard 原哈希找回。

git revert不修改已有提交历史，更适合已经推送到远程的分支。比如你发布了 v1.2 之后发现某个功能有 bug，用git revert 提交哈希生成一个相反提交把该功能去掉，历史里会清楚记录这次"撤销"。多提交连撤可以用git revert 旧提交..新提交。在多人协作分支上，我几乎只用 revert 不用 reset，因为它不会给同事造成历史错乱，合作起来更文明。

5.3 半路想切分支：stash 优雅暂存现场

开发到一半，突然要切分支去改热修复，但改动不想丢弃也不想提交。git stash会把你工作区的改动存到一个临时栈中，让工作区恢复干净。之后切分支、该干嘛干嘛，事后再回到这个分支执行git stash pop，改动就会弹回来，如同从未离开。

git stash list查看暂存列表，我可以为你恢复指定一条git stash apply stash@{1}。apply不会删除栈中的记录，pop会弹出并删除。如果 stash 后你的工作区因为后续改动而冲突，pop会报冲突，但 stash 记录还在，解决冲突后git stash drop手动清理就行。

我用 stash 还有一个高级习惯：git stash push -m "描述信息"给每次暂存写个标签。因为 stash 默认只显示WIP on branch: 哈希值，过几天再看根本想不起当时存的是什么，加上描述后辨识度立即提升。如果你并不少，会感谢这个习惯的。

另外现在 Git 2.23+ 提供了git switch的邻居git restore，以及git stash push，都是为了把各种多语义命令做拆分，让操作更安全清晰。新学 Git 的同学建议直接养成这个"新式命令"习惯，老同学想改也不难。

6. 常见问题排查速查表，直接翻答案

6.1 分离头指针（Detached HEAD）状态

当你git checkout 某个提交哈希而不是分支名时，HEAD 不指向任何分支，进入 Detached HEAD。这个状态下新提交不会属于任何分支，一旦切走很容易丢失。如果确实需要在某个历史提交上做改动，先git switch -c 新分支名基于当前状态创建分支，再接续开发。如果只是想看看代码，什么都不改、直接切走即可。

6.2 提交提交错了分支

把功能提交到了 main，而不是 feature/login。别慌，先记下那个提交的哈希，执行git switch feature/login，然后git cherry-pick 哈希把这个提交复制到当前分支。回到 main 后，如果该提交是最近一次且还没推送，git reset --hard HEAD~1把它从 main 移除；如果已经推送到远程，就用git revert生成反向提交。整个过程其实比很多人想象中简单，关键是动手前先想清楚分支指针的移动路径。

6.3 合并冲突进行到一半想放弃

内容冲突甚至文件冲突（比如两边都改动了同一个二进制文件名）导致合并卡住时，可以用git merge --abort回到合并前状态。这个命令在 rebase 场景对应git rebase --abort。切记先保存你手动改过的中间内容，否则 abort 之后那些半成品也会一起消失。

6.4 持续提示输入用户名密码

以前遇到这类问题通常靠 credential helper 配置解决；而 2021 年后，很多平台不再支持账号密码直接 push，推荐使用 SSH key 或 token 方式认证。如果git push反复失败或要求输入口令，先用ssh -T git@平台域名（以实际平台为准）诊断 SSH 是否连通，再检查本地仓库的 remote 地址用的 HTTPS 还是 SSH：git remote set-url origin可以随时切换地址格式。日常建议用 SSH 认证，配置一次长期省心。

6.5 误把大文件提交进仓库

Git 对仓库大小非常敏感，一旦提交了类似编译产物的大型二进制到历史记录中，即使之后删掉文件，这个"膨胀"仍会留在 .git 历史里。若提交还未推送，用重置或 amend 都行；若已推送且历史较深，需要工具重写历史，这一操作复杂且会改写全部提交哈希。更根本的预防方案是：把不需要跟踪的文件放进.gitignore，例如：

node_modules/ dist/ *.log .DS_Store

.gitignore是每个仓库第一件应该做好的事。

下面我把高频遇到的问题整理成一张对照表，方便你直接查阅：

每张表其实都浓缩了一个完整场景的前因后果。我把这个表做成了一张实体便签贴在显示器旁边，前几周频繁翻，之后基本不看了，因为反复几次肌肉记忆自动形成。你也可以试试这个土办法。

我个人在实际操作中的体会是：Git 命令学的不是数量，是模型。你不需要背下所有参数，只需要清楚地知道工作区、暂存区、版本库、远程这四个层级，再想清楚每条命令在这四层之间搬运了什么内容、移动了什么指针，就不会在出现冲突或误操作时手忙脚乱。后面我每次换新环境，第一件事就是把.gitignore写好，把默认提交信息规范用文本存到本地配置文件里，避免临时拼凑。建议你也找一个小项目，按这篇文章的流程从头到尾练两遍分支和远程操作，把"害怕冲突"变成"预判冲突"，那种感觉会很不一样。