工作这些年，我带过不少新人，几乎每个第一次接触 Git 的人都会卡在同一个问题上：“为什么git add之后还要git commit？这不是脱裤子放屁多此一举吗？” 这个问题其实特别值得认真回答，因为只要搞懂了 Git 的三大分区设计，后面所有命令你都能猜到个八九不离十。这篇文章我就从基础分区讲起，把日常用到的高频命令、分支合并、免密配置、疑难杂症一次说清楚。适合刚入门想建立完整认知的开发者，也适合命令用得不熟、经常在网上现搜命令的“检索型选手”。
先说清楚这篇文章能帮你解决什么问题。Git 不难，难的是它的概念模型和命令行操作习惯和平时的文件操作思维完全不同。你如果只是照着网上的教程敲命令，今天记住了明天就忘，一不小心还会把代码搞丢。但只要分区模型在脑子里立住了，命令就是顺水推舟的事。下面我按“设计原理 → 核心命令 → 实操流程 → 疑难排查”的顺序来拆，尽量用大白话讲透。
1. Git 工作的底层逻辑：三个分区的设计哲学
1.1 工作区、暂存区、版本库分别是什么
Git 的核心模型可以用一句话概括：一个项目在 Git 眼中被分成三个区域，文件在不同区域之间流转，而所有 Git 命令都是在推动这种流转。
这三个区域分别是：
- 工作区（Working Directory）：就是你电脑上能直接看到的文件夹，你在编辑器里改的就是这些文件。这里面的文件是“活”的，随便你改、随便你删。
- 暂存区（Staging Area / Index）：一个看不见的中间缓冲区，对应
.git/index这个文件。它记录的是“你准备把哪些改动纳入下一次提交”。 - 版本库（Repository）：就是项目根目录下的
.git文件夹，存的是每一次提交的历史快照。一旦提交成功，这个状态就被永久记录在 Git 的历史里。
我用生活类比帮你理解一下：工作区是你逛菜市场时眼前的所有摊位，看到什么都想买；暂存区是你手里的购物车，挑好的菜先放进去；版本库是你家的冰箱，把购物车里的东西归置好、冷冻起来。买菜可以反复挑（改文件），放购物车也可以反悔（取消暂存），但一旦塞进冰箱（commit），你就建立了一个可追溯的“存货清单”节点。
为什么 Go 的设计要搞得这么麻烦？因为实际开发中经常遇到这种情况：一个文件里改了三处逻辑，其中两处属于 bug 修复，第三处是新功能，你希望它们成为两个独立的历史记录。有了暂存区，用git add -p就能把同一个文件的不同片段分开暂存，分别提交。如果没有暂存区，这一现实需求根本无法实现。
1.2 三大分区的存储本质
很多初学者以为 commit 就是把文件复制一份存起来，这个理解不够准确。真正发生的事比这更精妙。
当你在工作区创建文件并执行git add时，Git 会先把文件内容压缩并计算出一个 SHA-1 哈希值，存进.git/objects里，这种对象叫作blob 对象。暂存区其实存的是“这个文件的路径 + blob 对象的哈希”这种映射关系。
当你执行git commit时，Git 会做三件事：
- 把所有暂存的 blob 对象组合成一颗树对象（tree），相当于目录快照。
- 创建一个commit 对象，包含作者信息、提交信息、时间戳，以及指向上一个 commit 的指针。
- 把当前分支的指针挪到这个新 commit 上，同时更新 HEAD 指向这个分支。
整个过程不需要复制整个项目，文件内容只存一份，重复内容还会被 Git 自动去重。这也是为什么 Git 仓库即使提交了几千次，占用的空间通常也比你想象中小得多。
理解这一层还有一个实际好处：你会明白git reset为什么能切换“软”“硬”模式，因为本质上 reset 就是在移动指针、重置索引、覆盖工作区这三件事中选几件做。这个概念是后面所有高阶操作的地基，建议反复体会几遍。
2. 分区之间流转的核心命令
2.1 从工作区到暂存区：git add 的完整解读
git add是把改动从工作区放进暂存区的唯一常规入口。它最常见的三种用法：
# 暂存当前目录及子目录下的所有变更 git add . # 暂存所有变更（包括已删除的文件） git add -A # 只暂存指定文件 git add src/router/index.js这三条命令的区别有必要说清楚。git add .只作用于当前目录，如果你在仓库根目录执行倒还好，如果在子目录执行就可能会漏掉上级目录的改动。git add -A则始终从仓库根目录开始扫描，无论你在哪执行，改动都会被完整捕捉。我个人的习惯是，除非明确只想提交某个文件，否则一律用git add -A或git add .在根目录执行，避免“我明明 add 了为什么没提交上去”这种低级事故。
git add之后想反悔，把某文件从暂存区撤出来，用：
git restore --staged <file> # 老版本写法 git reset HEAD <file>注意这里有个非常容易踩的坑：git restore --staged <file>只是把文件“挪出暂存区”，不会丢失你工作区里的修改，文件内容还在，只是状态从“已暂存”变回“已修改”。搞清楚这个行为，你就不会在做撤销操作时心慌了。
2.2 从暂存区到版本库：git commit 的细节
commit 是把暂存区固化成历史记录的动作。最基本的命令就是：
git commit -m "修复登录页验证码刷新问题"如果你不写-m，Git 会打开默认编辑器等你输入提交信息。环境里默认编辑器通常是 vim，热词里有同学提到 vim 命令，那这里必须提醒一句：在 vim 里输入完提交信息后，要先按 Esc 进入普通模式，再输入:wq回车保存退出。很多新手第一次提交时卡在这一步，以为程序死机了，其实是被 vim 的交互模式困住了。
commit 信息怎么写得像样？有几点经验值得参考：
- 用祈使句开头，比如“修复”“新增”“优化”“重构”，让历史列表看起来像一份工作清单。
- 控制在 50 个字左右，核心信息放前面。像“改了登录逻辑”这种太模糊，“修复移动端登录按钮点击没反应的样式问题”这种才有检索价值。
- 如果是一次规模较大的提交，用
git commit（不带 -m）进入多行编辑模式，第一行写标题，空一行后写正文，说明改动背景和影响范围。这条习惯很多人不在意，但当你三个月后回头查一个老逻辑时，多写一行背景说明能救你半条命。
还有一个各位迟早会遇到的点：git add和git commit可以合并写。小改动用git commit -a -m "内容"可以跳过 add，直接把已跟踪文件的改动提交上去。但这条命令对“未跟踪的新文件”无效，对已 add 到暂存区的文件也会有重复提交的隐患。所以我建议新手不要偷这个懒，老老实实 add 完再 commit，等形成了条件反射再考虑简化。
2.3 分区的回退操作：reset 的三种模式
Git 的撤销操作里，git reset是最核心也最危险的一个。它的完整形态是：
git reset --soft <commit> git reset --mixed <commit> # 默认模式 git reset --hard <commit>这三种模式的差别对应到三大分区上，很容易记忆：
| 模式 | 移动分支指针 | 重置暂存区 | 覆盖工作区 | 适用场景 |
|---|---|---|---|---|
--soft | 是 | 否 | 否 | 想重新提交，保留所有改动 |
--mixed | 是 | 是 | 否 | 想撤销提交，但保留代码改动 |
--hard | 是 | 是 | 是 | 想彻底丢弃改动，回到某历史状态 |
举个例子。你刚 commit 了一个文件，回头发现漏加了一个文件，这时候用git commit --amend其实更合适，相关内容后面会讲。但如果想撤销最近提交、把改动拿回工作区改一改再提交，git reset --soft HEAD~1就够了；想把改动挪回暂存区来重新 add，就用联--mixed；如果这次提交本来就是错误尝试，代码全不要了，git reset --hard HEAD~1一步到位。
这里必须敲黑板提醒：git reset --hard会直接覆盖工作区文件，任何未提交的改动都会灰飞烟灭，而且没有后悔药。我见过不止一个同事在分支合并失败时，急着用 hard reset 回退，结果自己刚写的代码全没了，哭都来不及。所以执行 hard 之前，务必先用git status看一遍，或者用git stash把手头改动先暂时存起来。
3. 从零搭建：安装配置与日常高频操作
3.1 Git 安装与环境配置
Git 的安装本身不复杂，但不少同学卡在“下载”和“配置”两步上。各平台的方式：
- Windows：官网下载安装程序，一路 Next 即可。安装完成后在开始菜单里能找到 Git Bash，日常命令推荐在 Git Bash 里跑，不要用 CMD，否则路径分隔符和部分命令行为不一致会坑你。
- macOS：装了 Homebrew 的，
brew install git一行搞定；没装的话直接官网下载 pkg 包安装。 - Linux：Debian/Ubuntu 系用
sudo apt install git，CentOS/RHEL 系用sudo yum install git。
安装完成后第一件事是配置身份。这一步很多人跳过，导致第一次 commit 时直接报错 “Please tell me who you are”。Git 规定每次提交必须带作者信息，否则无法生成 commit 对象。两条命令解决：
git config --global user.name "你的名字" git config --global user.email "你的邮箱"为什么要敲这个？因为每次提交记录的元信息里包含这两项，在你回看历史、审查代码时都是关键线索。注意这里邮箱不强制要求是你注册平台的邮箱，但为了能对上远程平台的账号，强烈建议写成和 GitHub/Gitee 一致的邮箱。可以用git config --list检查当前配置是否生效。
3.2 新项目接入 Git 的标准流程
分两种情况说。
一是从零开始的项目，你要做的是进入项目根目录，执行：
git init git add -A git commit -m "项目初始提交"git init会在当前目录生成.git文件夹，标志这个目录已进入 Git 管辖。对新人来说，等到把初始提交做完，Git 的历史线就建立了，后面其实就是重复“改代码 → add → commit”的小循环。
二是从远程仓库拉取现有项目，用：
git clone <仓库地址>很多人初学时分不清clone和init的关系，其实一句话就能概括：clone是init+remote add+fetch+checkout的组合拳，直接把远程仓库完整复制到本地，同时绑定好远程源。所以如果你有现成仓库，根本不需要 init。
日常开发里最典型的“上班流程”是：
git pull # 拉取最新远程分支代码 git checkout -b feat/xxx # 基于当前分支新建自己的开发分支 # ... 写代码 ... git add -A git commit -m "完成某功能" git push origin feat/xxx # 推送到远程这里有一个热词提到 IDE 创建新项目拉取 Git，其实就是图形界面版的 clone。IDEA、VS Code、GitHub Desktop 本质执行的都是同一套命令，图省事用界面没问题，但只要理解了命令行这套流程，无论界面怎么换你都不会懵。
3.3 分支管理与合并操作
分支是 Git 被讨论最多的功能之一，热词里也出现了“git分支合并”，这里我重点讲透。
分支的本质就是一个可以移动的指针，指向某个 commit。默认分支叫main或master，你新建一个分支，其实就是复制一份指针，带着新指针去走另一条历史线。几乎所有日常命令都围绕“指针的在移动”展开。
基础的三件套：
# 查看本地分支（-a 可查看远程分支） git branch # 新建并切换分支 git checkout -b feature/login # 切换分支（新版 Git 更推荐的语义化命令） git switch feature/logingit checkout -b是老的写法，新版 Git 引入了更明确的git switch -c命令区分“切分支”和“恢复文件”两种操作。我建议新朋友直接用git switch，少踩一个坑——git checkout这个词在 Git 里有两种含义的，语义太模糊，很容易让新手混淆。
分支合并，最常用的命令是：
# 切到想要接收代码的目标分支，比如 main git switch main # 把 feature 分支的改动合并进来 git merge feature/login合并的结果分三种情况：
- Fast-forward（快进）：目标分支没有产生新提交，合并时 Git 直接把 main 的指针移动到 feature 所在位置。这种最理想，不会有冲突。
- Recursive（递归合并）：两条分支都有新提交，Git 会生成一个额外的“合并提交”把两条线拼在一起，这种情况通常自动完成。
- Merge conflict（冲突）：两条分支改了同一文件的同一区域，Git 不知道以谁为准，只能停下来让人类裁决。
出现冲突时不要慌。冲突文件里会出现类似这样的标记：
<<<<<<< HEAD 这是当前分支的代码 ======= 这是要合并过来的代码 >>>>>>> feature/login处理方式就是打开文件，手动把两段代码调整成你想要的样子，删除掉这三行标记，然后git add+git commit收尾。注意，不要尝试把冲突标记也一并提交进去，中文注释习惯写“解决冲突”的提交信息是最好的标记。
4. 提高效率的进阶命令与配置技巧
4.1 修改提交记录：git commit --amend 的正确用法
热词里有“git commit --amend怎么使用”，这个命令的实际使用频率其实很高，但危险性也被严重低估了。
git commit --amend的作用是“修改最近一次提交”。具体可以命中两种场景：
- 提交信息写错了。比如消息写成了“修改”，你希望在历史里看到“修复登录页 bug”，直接
git commit --amend -m "修复登录页 bug"。 - 提交漏了文件。你 commit 之后发现还有一个改过的文件没进去，执行
git add 漏掉的文件然后git commit --amend --no-edit，注意这里加了--no-edit，意思是“保留原来的提交信息不用重新输入”。
原理上，--amend不是修改旧的 commit 对象，而是生成一个新的 commit 对象来替换它，旧的会从分支历史上“消失”。
这里有一条红线规则：不要 amend 已经推送到远程、且其他人正在使用的提交。因为远程历史已经被改过之后，别人的本地历史和远程会对不上，强制 pull 会出现奇怪的交织记录。所以 amend 只适合处理那些“还没 push 的本地提交”。
4.2 免密配置与远程协作
热词里出现了“git免密”“git配置gitee密钥”“ssh认证失败 git”，这几个问题本质是同一件事：如何在推送代码时不用每次输入用户名密码。
最简单可靠的方式是配置 SSH 密钥。流程：
# 1. 生成密钥，-C 填自己的邮箱 ssh-keygen -t ed25519 -C "you@example.com" # 2. 一直回车，生成完后把公钥内容复制下来 cat ~/.ssh/id_ed25519.pub # 3. 登录 Gitee/GitHub，在“设置 → SSH公钥”里粘贴保存生成密钥时有个小细节：默认路径是~/.ssh/id_ed25519，如果你电脑上已经有其他用途的 SSH 密钥（比如连接服务器的），建议最好单独命名，比如id_ed25519_gitee，然后在~/.ssh/config里指定 Host 对应的 IdentityFile，否则多个密钥会打架。
配置完之后，把远程地址从 HTTPS 改为 SSH 格式：
git remote -v # 先看当前远程地址 git remote set-url origin git@gitee.com:用户名/仓库名.git从此 push、pull 都不需要输密码。SSH 免密的原理是：你的机器保存了私钥，远程服务器认你的公钥，握手时自动完成认证，无需输入账号密码。
常见的“ssh认证失败”bug 有三种：
- 公钥没配置到平台，报 Permission denied (publickey)。
- 本地有多个密钥，Git 用了错的私钥，需要在
~/.ssh/config里指定。 - 你 clone 时用的是 HTTPS 地址，SSH 地址没生效，先检查
git remote -v。
4.3 临时工作切换：git stash 场景实战
“改到一半，突然需要切分支去修个紧急 bug”，这类场景几乎每天都在发生。如果你直接切分支，Git 会阻止你，因为工作区有未提交的改动。这时候两个选择：commit 掉，或者用 stash 暂时收起来。
git stash就是“把你的工作现场暂时挂起”的专用命令，核心用法就三条：
git stash # 暂存所有未提交改动 git stash pop # 恢复最近一次暂存 git stash list # 查看暂存列表细节补充两点：git stash默认不会暂存未跟踪的新文件（untracked files），如果新文件也要一起收起，要加-u：git stash -u。另外，恢复时不建议用apply而建议用pop，因为pop会把暂存记录同时删掉，避免你的 stash 列表越积越多、到最后自己都忘了哪些是干嘛的。
如果同时暂存了多次，可以git stash pop stash@{2}选择恢复指定记录。这套操作总结下来一句话：stash 是“临时柜”，不是“长期仓库”，长期不用的分支改动该提交就提交，挂在 stash 列表里的东西放太久基本等于丢了。
5. 常见问题与疑难杂症排查实录
5.1 高频报错速查表
这些年带人过程中，遇到最多的报错其实就是那么几个，做成表格放在这里，方便你直接对照：
| 报错信息 | 原因 | 解决方法 |
|---|---|---|
fatal: not a git repository | 当前目录不在 Git 仓库内 | 确认已执行git init，或 cd 到仓库根目录 |
Please tell me who you are | 未配置 user.name / user.email | 执行git config --global补配置 |
Permission denied (publickey) | SSH 认证失败 | 检查公钥是否配置平台、是否用了正确私钥 |
error: failed to push some refs | 本地落后于远程 | 先git pull --rebase再 push |
! [rejected] ... (fetch first) | 远程有新提交，本地被拒绝 | 用git pull --rebase变基后重推 |
CONFLICT (content) | 合并且两边改了同一处 | 手动解决冲突，删除标记后 add+commit |
列一个不算报错但很多人会疑惑的现象：git commit后提示 “nothing to commit, working tree clean”，但你明明改了文件。这种情况大概率是你改的文件被.gitignore忽略了，或者改动发生在未跟踪的文件上，你在 add 时没把新文件加进去。用git status一看便知。
5.2 .gitignore 不生效的真正原因
热词里有“git 的过滤文件 没有作用”，这问题太常见了。表现是明明在.gitignore里写好了node_modules/，但执行git status还是能看到 node_modules 的变动。真相往往是：这个文件在加入 .gitignore 之前已经被 git 跟踪进了版本库。.gitignore只对未被跟踪的文件生效，已跟踪的文件不受这个规则约束。
解决办法是把它们从版本控制中移除，但保留在本地：
git rm -r --cached node_modules--cached的意思是只删暂存区里的记录，不碰工作区的真实文件，执行完 add 并 commit 一次，之后.gitignore才会真正起作用。
另外写.gitignore时有个细节值得注意：行末不要加空格，目录要写成node_modules/带斜杠的形式，而不是node_modules，否则匹配逻辑可能和你的预期不一致。这个细节坑过很多人，我写这份文件时已经形成了肌肉记忆。
5.3 Git LFS 处理大文件
热词里也有“git lfs使用”“git lfs clone卡住”，说明不少朋友已经碰到大文件托管的问题了。Git 本身不适合存大文件——每次修改都会把整份二进制历史留档，仓库会迅速膨胀，clone 变得极慢。Git LFS（Large File Storage）就是官方解决方案：把大文件的实际内容存到 LFS 服务器，Git 仓库里只保留一份指针文件。
基本使用流程：
# 1. 安装 LFS（Windows 安装 Git 时可勾选；macOS 用 brew install git-lfs） git lfs install # 2. 声明哪些文件由 LFS 接管 git lfs track "*.psd" git lfs track "assets/*.zip" # 3. 正常提交推送，LFS 自动处理 git add -A git commit -m "添加大文件资源" git push origin main如果发现git lfs clone卡在下载阶段，通常是因为网络不稳定或 LFS 服务器响应慢。这时候可以拆开操作：先正常git clone仓库（只下指针文件，很快），再执行git lfs pull拉取大文件本体。这个步骤对大仓库的体验提升非常明显，我处理 1GB 以上资源仓库时都这么干。
最后说几句真心话
带团队这几年，我最大的体会是：Git 命令不怕记不住，怕的是不理解它背后的分区模型。只要三分区的关系在你脑子里清清楚楚，add、commit、reset、stash 这些命令的行为你基本都能推导出来，报错信息也看得懂。反而是那些拿着公共文档硬背命令的人，换个场景就容易翻车。
最后再分享一个小技巧：不要怕多敲命令。Git 的操作是“可逆”的，绝大多数误操作都能通过git reflog找回历史。真搞不定了，git status永远是第一求助对象，它会教你下一步该怎么做。把基础分区和这套命令练成肌肉记忆，你后面学分支模型、工作流协作、版本回退都会顺很多。
