最详细最傻瓜的Git使用教程：从入门到翻车自救

简介：一份专门面向Git初学者的详细入门教程，以PDF文档形式呈现，旨在帮助零基础用户理解分布式版本控制思想，并快速掌握从安装配置到日常提交回退的完整操作链路。内容从Git诞生背景与两大特性讲起，逐步覆盖Windows安装验证、git init创建版本库、git add/commit提交版本、git log查看记录、git reset --hard回退，以及reflog解决找回版本等高频场景，图文步骤清晰，适合学生、开发者用于自学或备查。资源为单个PDF文件，大小3.05MB，便携易用，目前已有一万余人学习下载，属于点击率较高的实用型教程。读者按章节边读边练，即可建立清晰的版本管理概念，避免多人协作及代码丢失的常见问题。

1. 这份 Git 使用教程要解决什么问题：写给零基础，也写给翻过车的

Git 使用教程网上一搜一大把，但多数要么太简：教你 git add、git commit 就算完事，合并冲突全靠猜；要么太深：一上来就讲底层对象模型，让人当场放弃。这份「最详细、最傻瓜」的 Git 使用教程，按真实工作中的路径来讲——安装配置、日常提交、分支合并、远程推送，再到误操作恢复，每步给出命令、参数和适用场景，照着敲就能跑通。

定位很简单：不用背命令，只要知道三件事：我现在在哪个状态、这个命令会改变什么、出问题了怎么退回去。踩过的坑按「现象 → 原因 → 解决」整理成专门一章，帮你绕开。

它适合刚接触 Git 的零基础，也适合用了一阵子、一遇冲突就发怵的开发者。照做一遍后，提交前知道该 add 什么，合并前敢动手，意外时能用 reset、revert、reflog 这些后悔药把损失追回来。

2. 先吃透 Git 的三棵树模型再动手：工作区、暂存区、版本库与首次配置

很多人学 Git 卡住，是因为不理解它把改动放在哪里。Git 有三个存放内容的地方，行话叫三棵树。搞懂这三棵树，后面所有命令都只是把改动从一棵树挪到另一棵树。别急着敲命令，先花五分钟把这个模型刻进脑子里，比记二十个命令都值。

2.1 工作区、暂存区、版本库：一张表看懂三个状态和三条命令

工作区就是你磁盘上能看到的项目目录，你在这里编辑代码；暂存区是提交前的中转站，决定下一次提交包含哪些改动；版本库存的是已经提交的历史，在 .git 目录里。平时敲的 add、commit、log，本质是在这三者之间搬运数据。

为什么要卡一个暂存区？因为一次提交应该是一个完整的逻辑单元。你一天里改了五个文件，可能只有两个属于同一件事，git add 让你能挑着提交。这是 Git 比很多老式版本工具精细的地方，也是初学者最容易懵的地方——为什么我改了文件，git commit 却提示 nothing to commit？因为改动只停留工作区，还没进暂存区。

git status # 查看当前处在哪个状态 git add index.html # 把工作区的修改放入暂存区 git commit -m "feat: 新增首页结构" # 把暂存区固化成一次提交 git log --oneline # 查看版本库里的提交历史

git status 的输出里三行关键词要认清楚：Changes not staged表示改动在工作区；Changes to be committed表示改动已进暂存区；Untracked files表示文件从未被 Git 跟踪。每次操作前扫一眼这几行，能挡掉八成低级错误。-m 后面的提交信息建议写成类型加简短描述的形式，这一点下一章细讲。

注意：git commit 只提交已进入暂存区的内容。直接改文件后立刻 commit，会看到 no changes added to commit。git commit -a可以跳过 add 直接提交已跟踪文件的修改，但对新增文件无效——不少人在这个细节上翻过车。

2.2 多平台安装 Git 与首次配置：用户名、邮箱、换行符和 SSH 密钥

安装这一步没太多玄学，但平台不同命令不同。Windows 上我一般用官方安装包或系统自带的包管理器，macOS 用户常见做法是先用包管理工具装一个新版，Linux 发行版直接用系统源安装。

# Windows（以常见包管理器为例） winget install --id Git.Git -e --source winget # macOS（常见做法：先用包管理工具装最新版） brew install git # Debian / Ubuntu 系 sudo apt update && sudo apt install git

装完先验证：git --version，能看到版本号就说明装好了。接下来是第一次使用时必须做的配置，很多人跳过这步，提交记录里显示的用户名是一串随机字符，后面改起来非常别扭。

git config --global user.name "你的名字" git config --global user.email "你的邮箱" git config --global core.autocrlf input git config --global core.editor "code --wait" git config --list # 验证配置是否生效

user.name 和 user.email 会写进每一次提交的元数据，也就是 git log 里看到的作者信息。core.autocrlf 处理换行符问题：Windows 默认用 CRLF，其他平台用 LF，两地提交混在一起，会出现整个文件都被标记为修改的玄学现象。Windows 上建议设为 true，macOS 和 Linux 上设 input 即可。core.editor 配的是编辑器命令行入口，设置之后，git commit 不带 -m 时会打开编辑器让你写多行提交信息。

推送远程仓库前，一般还要配一把 SSH 密钥，免去每次输入账号密码的麻烦。

ssh-keygen -t ed25519 -C "你的邮箱" # 一路回车，生成于 ~/.ssh/id_ed25519.pub

把 .pub 文件里的内容复制到远程托管平台的账户设置里即可。生成时如果提示文件已存在，说明之前配过，直接用旧的也可以，不必强行覆盖。

2.3 git init 还是 git clone：两种开局方式与 .gitignore 的第一份模板

接手一个项目时，先判断用哪种方式把仓库建立起来。git init 是把一个普通目录变成 Git 仓库，适合全新项目；git clone 是把远程仓库完整复制到本地，适合已有项目。两者选错不会造成损失，但后续操作差很多——init 出来的仓库没有 remote 配置，push 之前要手动关联远程地址。

git init # 在项目根目录初始化 git clone https://example.com/team/project.git # 克隆远程仓库

clone 会把完整历史和远程分支都拉到本地，自带 remote 配置，等于开局就绪；init 则是从零开始，第一次推送需要 git remote add origin 再接上远程。我一般建议：只要能访问远程仓库，优先 clone，省去一堆关联配置。

在第一次 add 之前，一定要先建 .gitignore。它声明哪些文件永远不要被 Git 跟踪，比如依赖目录、构建产物、日志和密钥文件。下面是一份适合大多数项目的起步模板：

node_modules/ dist/ *.log .DS_Store __pycache__/ .env

这段规则的含义：忽略 node_modules 和 dist 整个目录、所有 .log 后缀文件、macOS 的 .DS_Store、Python 的缓存目录pycache，以及 .env 环境变量文件。其中 .env 必须尽早忽略，否则密钥一旦进了版本库，光删文件不够，要从历史里抹掉才算干净。还要记住：.gitignore 只对未被跟踪的文件生效——这一点在第 4 章专门展开，是新手踩得最密集的坑。

3. 日常开发主流程：从 git add 到 git push 的标准操作与参数说明

三棵树模型理解了，日常开发其实就是一条固定流水线：改代码、进暂存区、提交、推送。这一章把一天里的高频动作串成流程，帮你把操作练成肌肉记忆。

3.1 git status / git add / git commit：提交的最小闭环与提交信息约定

一次规范的提交，我一般按四步走：先看状态，再选择性 add，再确认暂存内容，最后提交。

git status # 先看当前状态 git add src/main.py tests/test_main.py # 只加本次相关的文件 git status # 确认 staged 内容无误 git commit -m "feat: 增加用户登录接口"

先 status 再 add 再 status 再 commit，这个闭环能挡掉一半低级错误。git add 支持同时加多个文件，也可以加整个目录比如 git add src/。新手最常见的错误是不看状态就 git add .，把调试日志、临时文件、本不该提交的东西一股脑塞了进去。add . 这个命令我不建议新手期用，它看似省事，实际把选择权交给了默认行为，容易制造脏提交。

提交信息约定，业内比较通用的是「类型: 描述」前缀格式：feat 表示新功能，fix 表示修 bug，refactor 表示重构，docs 是文档，test 是测试，chore 是杂项。好处是 git log --oneline 扫一眼就能定位提交意图，也方便自动化工具生成变更记录。各家团队可能有自己的细则，但统一格式一定比自由发挥好。

除了整文件暂存，还有一个能力叫分块暂存：当一个文件里有两处不相干的改动时，用交互模式逐块选择。

git add -p src/main.py

进入交互模式后，Git 会把改动按 hunk 切块逐个询问。y 表示暂存当前块，n 表示跳过，s 表示把大块拆成更小块，q 表示退出。这个命令是提交颗粒度的兜底手段——同一个文件里既改了登录逻辑又改了样式，就不该算作一次提交，用 -p 能把它们拆成两条独立记录。

3.2 分支操作：git branch、git switch、git merge 的分工与协作模式

分支是 Git 最核心的价值：让多人并行开发互不干扰。理解分支最简单的方式，是把它看作贴在提交记录上的标签——创建分支就是贴新标签，切换分支就是换一张标签贴在当前位置。

git branch feature/login # 创建分支 git switch feature/login # 切换分支 git switch -c feature/login # 创建并切换，最常用

-c 是 create 的缩写，一步完成创建加切换，日常使用率最高。新版 Git 推荐用 git switch 做分支切换，语义比老命令 git checkout 清晰；checkout 被保留给恢复文件这类场景。命令会变，概念不变，switch 和 checkout 做的是同一件事——移动 HEAD 指针。

功能做完后要合回主线，标准动作是先切回目标分支再合并：

git switch main git merge feature/login # 默认 fast-forward 合并 git merge --no-ff feature/login # 强制产生合并提交

默认的 merge 在能直接快进时会走 fast-forward，不产生额外提交，历史是一条直线；--no-ff 则强制留一个合并提交，把功能分支的痕迹保留下来。想保留分支开发脉络的团队，一般用 --no-ff；个人项目或追求线性历史的场景，默认模式更清爽。

常见的小团队协作模式基本是：main 保持稳定，功能分支命名带语义，合并前先拉取最新 main。这个「先拉再合」的习惯，直接决定你后面会不会遇到大批冲突，也是第 4 章避坑的前提。

3.3 git push 与 git pull：远程协作的两个高频动作和 upstream 参数

本地提交只存在于你的电脑上，推送到远程才能让团队看到。第一次推送和后续推送之间，差一个 upstream 绑定。

git remote add origin https://example.com/team/project.git # 首次关联远程 git push -u origin main # 首次推送并记录 upstream git push # 之后就直接用

-u 是 --set-upstream 的缩写，作用是把本地分支和远程分支绑定，绑定后后续 push、pull 都不需要再带参数。upstream 是很多报错的核心：执行 git push 却提示 no upstream branch，原因就是没做过 -u 绑定，或者本地分支与远程分支名对不上。

git pull 比很多人想得复杂一点点：它实际上是两步合一——先 fetch（把远程新提交下载到本地），再 merge（把下载内容合并进当前分支）。理解这点，你就能看懂为什么有时候 pull 完，git log 里会多出一个 Merge branch 的提交，那是 pull 里的 merge 产生的，不是你手动合并的。

git fetch origin # 只下载远程改动，不动本地工作区 git diff main origin/main # 对比本地和远程的差异 git pull # 确认无误后合并

想避免 pull 自动产生合并提交，可以用 git pull --rebase，把本地未推送的提交挪到远程新提交之后，历史保持线性。这一步放到第 6 章细讲，因为它牵扯 rebase 对提交历史的改写规则。先记住一个结论：push 被拒（non-fast-forward）的根源，几乎都是推之前没拉最新内容——远程已经有人提交了新版本，本地还停在旧位置。

4. Git 翻车避坑指南：合并冲突、提交错分支、HEAD 游离等 5 个高频事故

这一章是血泪经验。每个坑按「现象 → 原因 → 解决」拆开，不用记全部细节，只要遇到类似场景时能想起来这事在第 4 章见过。最重要的话放前面：无论多慌，不要删 .git 目录，那等于把后悔药一起扔了。

4.1 合并冲突：看到 CONFLICT 不要慌，按这三步处理

现象：执行 git merge 时终端输出 CONFLICT (content)，打开文件后看到成片的 <<<<<<<、=======、>>>>>>> 标记。

原因：两个分支改动了同一个文件的同一片区域，Git 无法判断保留哪一方，把决定权交给你。

解决：先 git status 找 unmerged 文件，打开文件处理标记，保留需要的内容，删掉标记行，然后 add 并 commit。

git status # 定位 unmerged 的文件 # 手动编辑文件，解决冲突标记 git add src/config.py # 标记该文件冲突已解决 git commit # 完成合并

合并进行中时，分支名后面会带着 (MERGING) 标识；如果冲突远超预期，git merge --abort 可以一键回到合并前状态。对于反复出现的同区域冲突，我习惯把冲突样式配成 diff3 模式，它会额外显示一个合并前的公共祖先版本，方便判断双方改动各基于什么：

git config --global merge.conflictStyle diff3

4.2 提交到了错误的分支：用 git reset --soft 把提交"搬"走

现象：你在 main 分支上做了一堆改动并提交，回过神来发现这些活应该在 feature 分支上做。

原因：手比脑子快，没切分支就开始写。这是所有误操作里发生频率最高的。

解决：用 --soft 重置撤销这一次提交，但保留全部改动，然后切到正确分支重新提交。

git reset --soft HEAD~1 # 撤销提交，改动保留在暂存区 git switch feature/ui # 切换到正确分支 git commit -m "feat: 页面与交互逻辑"

--soft 只移动 HEAD 指针，工作区和暂存区的改动原封不动，是最安全的撤销方式。关键点是先重置再切分支，而不是先在错误分支上继续写一堆再处理。如果已经在错误分支上提交了多次，把 HEAD~1 换成 HEAD~n 即可一次撤销多笔。

4.3 HEAD detached 游离状态：改完才发现不在任何分支上

现象：git status 显示 HEAD detached at 4f8e2a1，你在这个状态下改了一堆文件并提交，切回 main 后改动像消失了一样。

原因：你 checkout 的是一个提交哈希或标签，而不是分支名。此时 HEAD 不指向任何分支，新提交只挂在那个提交对象上，没有任何分支引用它，看起来就像丢了。

解决：发现游离状态时立刻拉一条新分支接住现场。

git switch -c rescue # 从当前游离位置创建新分支 git switch main # 回到主线 git merge rescue # 把刚才的改动并回来

重点在于：游离状态下不要继续开发，先建分支落袋为安。如果已经在游离状态下提交了，直接从游离位置切回 main，Git 会提示「以下提交将丢失」——那不是吓你，是真的会丢。git switch -c 是处理这个场景最顺手的命令。

4.4 误删分支或者改动丢失：git reflog 找回被遗忘的提交

现象：执行 git branch -D feature/report 删掉了分支，后续发现所有提交都消失了；或者 git reset --hard 之后发现回错了版本。

原因：分支只是指向某个提交的标签。删分支删掉的是标签，提交对象在 .git 里并没有立刻消失，只是暂时没有任何引用指向它。

解决：用 git reflog 找出 HEAD 曾经指向的位置，再用新分支接住。

git reflog # 列出 HEAD 每一次移动的记录 git branch report-rescue abc1234 # 用新分支接住丢失的提交

reflog 记录的是 HEAD 的本地移动日志，是真正的最后一层后悔药。它有两处局限：默认只保留约 90 天的记录，并且只记录本地活动。误删分支后如果继续大幅操作，或者仓库里跑了垃圾回收，找回概率会下降。所以平时提交越勤，这个坑的代价越小。

4.5 .gitignore 失效：文件还是被跟踪，原因只有一个

现象：把 .env 写进了 .gitignore，但 git status 里依然能看到它的改动，甚至已经被推送到远程。

原因：.gitignore 只对未被跟踪（untracked）的文件生效。这个文件在写入规则之前就已经被 git add 过，从此它被 Git 跟踪，忽略规则对它就是一张废纸。

解决：用 --cached 把它从跟踪清单里移除，但不删磁盘文件。

git rm --cached .env # 从跟踪清单移除，保留文件本体 echo ".env" >> .gitignore # 确认忽略规则存在 git commit -m "chore: 停止跟踪 .env"

--cached 的含义是从版本库里移除，但不动磁盘上的文件，适合处理这类不该被跟踪却已经被跟踪的文件。但要注意，取消跟踪不等于从历史里清除：之前已提交的内容还留在历史记录中，有人 clone 就能翻出来。真正要清除密钥类内容，要么改写历史，要么直接轮换密钥——后者往往更省事。

5. 版本回退的后悔药：git reset、git revert、git stash 怎么选

这三个命令是后悔三件套，但适用场景完全不同，选错了轻则本地历史混乱，重则影响整个协作仓库。先记一句话：reset 改自己的历史，revert 产生新提交来抵消旧的，stash 是临时寄存。

5.1 git reset 的三种模式：soft、mixed、hard 各毁掉什么

git reset --soft HEAD~1 # 撤销提交，保留暂存区 git reset --mixed HEAD~1 # 撤销提交和暂存，保留工作区（默认） git reset --hard HEAD~1 # 提交、暂存、工作区全部回到过去

对应第 2 章的三棵树模型，reset 就是让 HEAD 回到过去，顺带决定哪些区域一起回退。--soft 是最温柔的后悔药，只撤回提交本身，改动全保留；--hard 是最暴力的，会把工作区里没提交的修改一起抹掉。执行 --hard 之前，至少看一眼 git status 和 git diff，确认没有未提交的独有内容。

注意：不要在已经 push 到远程共享分支的仓库上执行 hard reset。本地退回后，下次 push 会被拒绝；强行 force push 会覆盖别人基于旧历史的提交，这是协作里最容易引发众怒的操作。

想改最近一次提交的信息而不动内容，还有一个更轻的命令：git commit --amend。它相当于把上一次提交替换成一个新提交，常用于修正提交信息或补充漏掉的小改动。

5.2 git revert 与 git reset 怎么选：已推送的历史别硬改

reset 是回到过去，适合还没推送的本地提交；revert 是造一个反方向的提交，把旧提交的效果抵消掉，历史本身不被改写。

git revert HEAD # 新增一个提交，抵消上一个提交的内容 git revert abc1234 # 撤销任意一次历史提交

revert 的产出是一条新提交记录，git log 里能看到原提交和抵消它的提交同时存在，所有参与协作的人都不会产生「我的提交怎么不见了」的困惑。这是它与 reset 最本质的区别：前者安全、可见，后者干净、危险。撤销合并提交时要带 -m 参数，-m 1 表示保留第一个父分支的内容，不带这个参数 revert 会报错并提示语法。

选型上的经验是：提交还没 push，用 reset，历史干净；已经 push 且别人可能拉取过，用 revert，宁可多一条提交记录也不改写共享历史。我在真实项目里见过因为追求漂亮历史、在共享分支上 force push 导致的集体事故，从此团队共识就是：共享分支安全第一，美观第二。

5.3 git stash：临时保存现场，切分支查问题不丢进展

现象：功能分支写到一半，线上出故障需要立刻切到 main 修复。直接 git switch main 可能被拒绝，提示 Please commit your changes or stash them。

原因：未提交的改动会跟随分支切换，Git 不允许它造成脏切换。

解决：先把改动收进暂存栈，切分支处理，回头再恢复。

git stash push -m "登录页改到一半" # 把未提交改动收起来，附带便签 git switch main # 干净切换 git switch feature/login # 处理完切回来 git stash list # 查看暂存栈 git stash pop # 恢复最新一条，并从栈中弹出

push 的 -m 参数相当于给这次暂存贴便签，强烈建议用。stash 默认只收起已被跟踪文件的改动，新文件要加 -u 才会一起收，比如 git stash push -u。pop 和 apply 的区别在于是否保留记录：pop 恢复后删除栈里那条，apply 恢复但保留，适合想把同一份改动试到多个分支的场景。

新手最容易在 stash 上犯的错是不命名、攒一堆，一周后 git stash list 里全是 WIP on，完全想不起来每份改动的内容。遇到这种情况，用 git stash show <编号> 看摘要，确认后再决定弹哪一条。

6. 让 Git 更好用的进阶技巧：交互式 rebase、别名配置与三个习惯

基础操作够用了，剩下的是提升效率和避免返工的细节。

6.1 用 git rebase -i 整理提交历史：把乱糟糟的 commit 压成一条线

功能分支写到后期，提交往往堆成一串 update 和 fix。合并主线前，我习惯用交互式 rebase 把它们整理成几条有意义的记录。

git rebase -i HEAD~5 # 对最近 5 个提交做交互式整理

执行后打开编辑器，每行对应一次提交，把需要合并行的 pick 改成 squash（或简写 s），最上面一行保留为合并后信息的入口；保存退出后再编辑一次最终的提交信息。整理完的 git log 干净很多，review 代码的人也轻松不少。

这个操作有两条硬边界：第一，只对尚未 push 的提交做 rebase，已共享的历史一旦改写，所有提交的哈希都会变，协作分支当场断裂；第二，rebase 重放中可能遇到冲突，同一个冲突要解多次，感觉失控时 git rebase --abort 原地退出，这才是正确的后悔药。

6.2 配置 Git 别名与三个值得长期保留的操作习惯

别名是我建议配的第一项懒人配置——把高频命令缩成两三个字母，行为不变，零副作用。

git config --global alias.ts "status -sb" git config --global alias.lg "log --oneline --graph --all" git config --global alias.unstage "restore --staged"

之后 git ts、git lg、git unstage 直接可用。-sb 是短状态加分支跟踪，--graph 让历史以树形展示。别名只绑定账户级配置，和具体项目无关，所以不要在别名里写死任何业务路径。

三个习惯：第一，提交前必看 git status 和 git diff，确认只包含本次相关文件；第二，每天开工先 git fetch 而不是直接 git pull，看清远程发生了什么再合并，能避掉一半冲突；第三，报错先读错误信息本身，push 被拒这类问题，第一行就写着 non-fast-forward 的处理方向。

我早期丢过的代码，几乎都栽在「不确认状态就动手」：不看分支名就提交，不看差异就 add .，不看报错就乱敲命令。Git 的命令不多，难的是每次操作前确认自己在哪个状态。把上面的命令在本地仓库各跑一遍，故意造几个冲突再解开，一次之后你就再也不怕它。希望帮到你。

本文还有配套的精品资源，点击获取