Git 从入门到精通：分布式版本控制完全教程
从零基础到团队协作，手把手教你掌握程序员必备的 Git 技能
面向人群：编程新手、在校大学生、转行开发者、以及所有想系统学习版本控制的脑力工作者
一、Git 是什么？
Git 是 Linus Torvalds 于 2005 年创建的分布式版本控制系统 ，到 2026 年已成为全球开发者使用率超过 95% 的代码管理标准工具。它不是"网盘备份"，而是一台时光机 ------ 记录你的每一次修改，让你随时回到过去的任意版本。
核心能力
| 能力 | 说明 |
|---|---|
| 版本回溯 | 任何一次保存（commit）都有快照，随时回退到历史版本 |
| 分支开发 | 创建独立分支开发新功能，不影响主线代码 |
| 多人协作 | 多人同时修改同一项目，自动合并、冲突提示 |
| 变更追踪 | 精确到行级别追踪谁在什么时候改了什么 |
| 分布式架构 | 每个人电脑上都有完整代码仓库，不依赖中央服务器 |
Git vs GitHub / GitLab / Gitee
初学者最容易混淆的概念：
| Git | GitHub / GitLab / Gitee | |
|---|---|---|
| 是什么 | 版本控制工具（软件） | 代码托管平台（网站） |
| 安装在哪 | 你的电脑上 | 云端服务器 |
| 能独立工作吗 | 能，不联网也能用 | 不能，它只是存储和展示 Git 仓库 |
| 类比 | 就像 Word 的"修订"功能 | 就像把 Word 文档传到百度网盘 |
一句话：Git 是工具，GitHub 是网站。你可以在电脑上用 Git 管理代码，然后推送到 GitHub 上备份和分享。
二、安装与初始配置
2.1 安装 Git
Windows
访问 git-scm.com 下载安装包，一路默认安装即可。安装完成后右键菜单会出现 "Git Bash Here"，这就是你的 Git 命令行入口。
macOS
bash
# 方式一：Xcode 命令行工具（自带 Git）
xcode-select --install
# 方式二：Homebrew（推荐，版本更新）
brew install gitLinux（Ubuntu/Debian）
bash
sudo apt update && sudo apt install git验证安装
bash
git --version
# 输出类似: git version 2.47.02.2 首次配置（必须做！）
Git 需要知道"你是谁"，每次提交都会记录这些信息：
bash
git config --global user.name "你的名字"
git config --global user.email "你的邮箱@example.com"
--global表示全局生效，对所有项目都使用这个身份。如果想对某个项目使用不同身份，去掉--global在该项目目录下执行即可。
2.3 推荐配置
bash
# 设置默认分支名为 main（GitHub 2020 年后的新标准）
git config --global init.defaultBranch main
# 换行符自动转换（Windows 用户强烈推荐）
git config --global core.autocrlf true
# 设置默认编辑器（可选）
git config --global core.editor "code --wait" # VS Code查看当前配置
bash
git config --list三、核心概念：一张图搞懂
在动手敲命令之前，先理解这四个核心区域：
工作目录 暂存区 本地仓库 远程仓库
(Working (Staging (Local (Remote
Directory) Area) Repository) Repository)
你的文件 git add git commit git push
──────────> ──────────> ──────────> ──────────>
<────────── <────────── <────────── <──────────
git restore git restore git reset git pull / fetch| 区域 | 通俗理解 | 操作命令 |
|---|---|---|
| 工作目录 | 你正在编辑的文件夹，修改后还没保存到 Git | 编辑代码、新建文件 |
| 暂存区 | "购物车"------ 你挑好了要提交的文件放在这里 | git add |
| 本地仓库 | Git 真正存储版本历史的地方，在你电脑上 | git commit |
| 远程仓库 | GitHub / GitLab 上的副本，用来分享和备份 | git push / git pull |
关键区别 ：
git add只是加入购物车，git commit才是结账付款。很多人以为 add 完就"保存"了，实际上 commit 才是真正记录版本的那一步。
四、Git 仓库操作实战
4.1 创建仓库
方式一：从零开始（init）
bash
mkdir my-project
cd my-project
git init # 初始化，创建 .git 隐藏目录方式二：克隆已有仓库（clone）
bash
git clone https://github.com/用户名/仓库名.git
git clone git@github.com:用户名/仓库名.git # SSH 方式（需要配置 SSH Key）4.2 查看仓库状态
bash
git status # 最常用的命令，随时查看当前状态
git status -s # 精简输出模式git status 会告诉你：
- 当前在哪个分支
- 哪些文件被修改了还没暂存（红色）
- 哪些文件已经暂存准备提交（绿色）
- 哪些文件没有被 Git 跟踪
4.3 文件的生命周期
Git 中的文件有四种状态：
未跟踪 (Untracked) → 已暂存 (Staged) → 已提交 (Committed) → 已修改 (Modified)
↓ ↓ ↓
新创建的文件 git add 后 git commit 后又改了
Git 不管理它 等待 commit 回到"已修改"状态4.4 提交修改
bash
# 第一步：添加到暂存区
git add 文件名 # 添加指定文件
git add . # 添加当前目录所有改动
git add -p # 交互式选择，逐块确认是否添加（进阶用法）
# 第二步：提交到本地仓库
git commit -m "描述你做了什么"怎么写好 commit message？
好的提交信息:
feat: 添加用户登录功能
fix: 修复首页加载白屏的问题
docs: 更新 API 文档
不好的提交信息:
改了点东西
修bug
111推荐格式：
类型: 简短描述，类型包括 feat（新功能）、fix（修复）、docs（文档）、refactor（重构）、test（测试）等。
4.5 查看提交历史
bash
git log # 完整历史
git log --oneline # 一行一条，清爽
git log --oneline --graph # 带分支图的精简历史（强烈推荐）
git log -5 # 只看最近 5 条
git log --author="你的名字" # 看某个人的提交五、分支管理：Git 的灵魂
分支是 Git 最强大的功能。它让你在独立的环境中开发新功能，不影响主线代码。
5.1 为什么需要分支？
想象你正在开发一个网站，线上版本跑在 main 分支。现在要加一个"支付功能"，需要改 20 个文件、写 3 天。如果直接在 main 上改，改到一半线上出 bug 了，你没法马上修 ------ 因为代码是"半成品"。
有了分支，你可以在 feature/payment 分支上安心开发，不影响 main。开发完再合并回去。
5.2 分支基本操作
bash
git branch # 查看所有本地分支（当前分支前有 * 号）
git branch -a # 查看所有分支（包括远程）
git branch 分支名 # 创建新分支
git checkout 分支名 # 切换到指定分支
git checkout -b 分支名 # 创建并切换到新分支（一条命令搞定）
git switch 分支名 # 新版 Git 推荐的切换分支命令
git switch -c 分支名 # 新版 Git 推荐的创建+切换
git branch -d 分支名 # 删除已合并的分支
git branch -D 分支名 # 强制删除分支（即使没合并）5.3 合并分支
bash
# 把 feature 分支合并到 main
git checkout main # 先切到目标分支
git merge feature # 把 feature 合并进来两种合并模式：
| 模式 | 行为 | 何时用 |
|---|---|---|
| Fast-forward | 如果 main 没有新提交，直接把 main 指针移到 feature 最新位置 | 简单线性分支 |
| 三方合并 | 如果 main 和 feature 都有新提交，Git 生成一个新的"合并提交" | 并行开发 |
5.4 解决合并冲突
当两个分支修改了同一文件的同一行时，Git 无法自动判断该用哪个版本，这就是冲突。
冲突文件会长这样：
<<<<<<< HEAD
<p>这是 main 分支的版本</p>
=======
<p>这是 feature 分支的版本</p>
>>>>>>> feature解决步骤：
- 打开冲突文件，找到
<<<<<<<、=======、>>>>>>>标记 - 决定保留哪个版本（或手动改写为结合两个版本的内容）
- 删除冲突标记，保存文件
git add 冲突文件→git commit
大多数现代编辑器（VS Code、WebStorm）都内置了冲突解决工具，比手动改标记方便很多。
5.5 常用分支策略
main ← 生产环境代码，只接受合并，禁止直接提交
├── develop ← 开发主线
│ ├── feature/A ← 功能分支（开发完合并回 develop，然后删除）
│ └── feature/B
├── hotfix/xxx ← 紧急修复分支（从 main 拉出，修完合并回 main 和 develop）
└── release/1.0 ← 发布准备分支这就是经典的 Git Flow 模型。小型团队可以简化为只用
main+feature/*分支。
六、远程协作
6.1 关联远程仓库
bash
git remote -v # 查看已关联的远程仓库
git remote add origin 仓库地址 # 添加远程仓库（origin 是约定俗成的名字）
git remote remove origin # 解除关联6.2 推送与拉取
bash
git push origin main # 把本地 main 分支推送到远程
git push -u origin main # 首次推送，-u 建立追踪关系，之后直接用 git push
git pull origin main # 拉取远程更新并自动合并（= fetch + merge）
git fetch origin # 只拉取不合并，先看看远程有什么变化6.3 push 被拒绝怎么办？
如果你和同事同时改了同一个分支，你先 commit 了，同事已经 push 了，你再 push 就会被拒绝：
bash
# 错误信息: ! [rejected] main -> main (fetch first)
# 正确做法：
git pull origin main # 先拉取远程更新，解决冲突
git push origin main # 再推送6.4 拉取请求（Pull Request）
PR 不是 Git 的功能，而是 GitHub / GitLab 平台的功能：
- 你在
feature/xxx分支上开发完成并 push 到远程 - 在 GitHub 上点击 "New Pull Request"，选择
feature/xxx→main - 团队成员 review 代码、讨论、修改
- 审核通过后合并到
main，删除 feature 分支
PR 是现代团队协作的核心流程，永远不要直接 push 到 main。
6.5 Fork 模式（开源贡献）
参与开源项目时，你没有直接 push 的权限：
- Fork：把别人的仓库复制一份到你自己账号下
- Clone：把你 Fork 的仓库克隆到本地
- 修改 + Push：在本地改代码，推送到你自己 Fork 的仓库
- PR：从你的 Fork 向原仓库发起 Pull Request
七、撤销与回退：后悔药大全
这是日常开发中最常需要用到的技能。
7.1 撤销工作区修改
bash
git restore 文件名 # 撤销某文件的修改（回到上次 commit 的状态）
git restore . # 撤销所有文件的修改
git checkout -- 文件名 # 旧版语法，同样的效果7.2 撤销暂存区
bash
git restore --staged 文件名 # 把文件从暂存区撤回到工作区（取消 add）
git reset HEAD 文件名 # 旧版语法7.3 撤销 commit
bash
git reset --soft HEAD~1 # 撤销最近一次 commit，改动回到暂存区（最常用）
git reset --mixed HEAD~1 # 撤销 commit 和 add，改动回到工作区（默认模式）
git reset --hard HEAD~1 # 彻底删除最近一次 commit 和所有改动（危险！）| 模式 | commit | 暂存区 | 工作区 | 适用场景 |
|---|---|---|---|---|
--soft |
撤销 | 保留 | 保留 | 改 commit 信息、合并多个 commit |
--mixed |
撤销 | 清空 | 保留 | 重新组织要提交的内容 |
--hard |
撤销 | 清空 | 清空 | 彻底放弃最近改动 |
HEAD~1表示"上一个版本"，HEAD~3表示"往前数 3 个版本"。
7.4 已经 push 了想回退
bash
git revert HEAD # 生成一个新 commit，"反向"撤销之前的修改（安全，推荐）
git reset --hard HEAD~1 # 本地回退
git push -f origin main # 强制推送（会覆盖远程历史，协作分支千万别用！）
revert是安全的做法，因为它不篡改历史，只是加了一个"撤销"的提交。reset+push -f会改写远程历史，在共享分支上是大忌。
八、进阶必备技能
8.1 Rebase（变基）
Rebase 和 Merge 都能合并代码，但思路不同：
bash
git checkout feature
git rebase main # 把 feature 的提交"接"到 main 最新位置| Merge | Rebase | |
|---|---|---|
| 原理 | 创建一个合并节点，保留两条分支线 | 把 feature 的提交"搬到" main 顶端，成一条直线 |
| 历史 | 保留真实的分支历史，有分叉 | 线性历史，看起来像在 main 上顺序开发 |
| 适用 | 公共分支合并 | 整理本地提交、同步上游变化 |
| 风险 | 低 | 会改写提交历史 |
黄金法则：永远不要 rebase 已经 push 到远程的公共分支！
8.2 Stash（暂存）
场景：你在 feature 分支上写了一半代码，突然要切到 main 去修紧急 bug。但你又不想 commit 半成品。
bash
git stash # 把当前所有改动暂存起来
git stash save "描述信息" # 带备注的暂存
git stash list # 查看暂存列表
git stash pop # 恢复最近一次暂存并删除记录
git stash apply # 恢复最近一次暂存但保留记录
git stash pop stash@{1} # 恢复指定的暂存8.3 Cherry-pick（挑选提交）
把某个分支上的某一个 commit 单独拿过来，而不是合并整个分支：
bash
git cherry-pick 提交的hash值 # 把指定 commit"复制"到当前分支典型场景：你在 develop 上写了一个工具函数，feature 分支也需要，但不需要 develop 上的其他改动。
8.4 Tag（标签）
为重要的 commit 打上标签，通常用于标记版本号：
bash
git tag v1.0.0 # 在当前 commit 打轻量标签
git tag -a v1.0.0 -m "正式版发布" # 附注标签（推荐，带说明信息）
git tag # 查看所有标签
git push origin v1.0.0 # 推送指定标签
git push origin --tags # 推送所有标签8.5 交互式 Rebase（整理提交历史）
在 push 之前，用交互式 rebase 把多个零散的小 commit 合并成清晰的提交：
bash
git rebase -i HEAD~4 # 整理最近 4 个 commit会弹出编辑器，你可以：
pick：保留该提交squash：将该提交合并到上一个提交reword：修改提交信息drop：删除该提交
8.6 .gitignore 文件
有些文件不应该被 Git 管理（编译产物、依赖包、密钥等）：
gitignore
# 在项目根目录创建 .gitignore 文件
node_modules/
dist/
.env
*.log
.DS_Store注意：
.gitignore只对未跟踪 的文件生效。如果文件已经被 Git 跟踪了，需要先用git rm --cached 文件名移出版本控制。
九、Git 与 AI 编程工具的结合
2026 年，AI 编程工具（Claude Code、Codex、Copilot 等）都深度集成了 Git。以下是用 AI 工具管理 Git 的典型场景：
9.1 AI 自动生成 Commit Message
在 Claude Code 或 Codex 中，完成一次修改后，AI 自动分析改动内容生成规范的提交信息：
用户: 帮我提交代码
AI: 检测到修改了 3 个文件，建议提交信息：
feat: 添加用户头像上传接口
- src/routes/upload.js: 新增上传路由
- src/middleware/validate.js: 添加文件校验
- tests/upload.test.js: 补充测试用例
是否提交？9.2 AI 辅助解决冲突
bash
# Claude Code 中可以直接让它分析冲突
请帮我解决当前的合并冲突，优先保留 feature 分支的功能逻辑，
但使用 main 分支的最新配置变量。9.3 AI 生成 PR 描述
AI 自动扫描改动、总结变更、生成结构化的 PR 描述，包括变更摘要、测试计划、影响范围分析。
核心思路 ：AI 帮你处理 Git 的文案和流程 ，但理解 Git 原理、做出合并决策仍然需要你自己掌握。
十、常见场景速查
场景一：我不小心在 main 上改代码了
bash
git stash # 暂存改动
git switch -b feature/xxx # 创建并切换到新分支
git stash pop # 恢复改动（改动现在在 feature 分支上了）场景二：commit 信息写错了，还没 push
bash
git commit --amend -m "新的提交信息"场景三：我提交了一个不该提交的文件
bash
git reset --soft HEAD~1 # 撤销 commit，改动回到暂存区
git restore --staged 不该提交的文件 # 把这个文件移出暂存区
git commit -m "重新提交"场景四：线上出 bug 了，需要紧急修复
bash
git checkout main # 切到主分支
git pull origin main # 拉取最新代码
git checkout -b hotfix/紧急修复 # 从 main 创建修复分支
# ... 修 bug ...
git commit -m "fix: 修复线上XX问题"
git push origin hotfix/紧急修复 # 推送并发起 PR场景五：想把某个文件恢复到上周的版本
bash
git log --oneline -- 文件路径 # 查看该文件的提交历史
git checkout 某次commit的hash -- 文件路径 # 恢复指定版本场景六：忘了自己在哪个分支、改了什么
bash
git status # 永远是你的第一个命令
git branch # 看看在哪个分支
git log --oneline -5 # 看看最近的提交十一、安全操作清单
- 每次开始工作前：
git pull拉取最新代码 - 每次动手前：确认自己在正确的分支上（
git branch） - 不直接在 main 上提交代码（通过 feature 分支 + PR）
- commit 前用
git diff --staged检查改动 - push 前用
git pull --rebase同步远程更新 - 不使用
git push -f在共享分支上 - 不在 commit 中包含密钥、密码、token（用 .gitignore）
-
git reset --hard前确认没有未保存的重要改动 - 遇到看不懂的冲突不要猜，先问队友或 AI
- 定期
git push备份本地代码
十二、常用命令速查表
日常高频
| 命令 | 作用 |
|---|---|
git status |
查看当前状态 |
git add . |
暂存所有修改 |
git commit -m "xxx" |
提交 |
git push |
推送到远程 |
git pull |
拉取远程更新 |
git branch |
查看分支 |
git checkout -b xxx |
创建并切换分支 |
git merge xxx |
合并分支 |
撤销相关
| 命令 | 作用 |
|---|---|
git restore 文件 |
撤销工作区修改 |
git restore --staged 文件 |
取消暂存 |
git reset --soft HEAD~1 |
撤销最近一次 commit（保留改动） |
git revert HEAD |
安全撤销（生成新 commit） |
查询相关
| 命令 | 作用 |
|---|---|
git log --oneline --graph |
查看提交历史图 |
git diff |
查看未暂存的改动 |
git diff --staged |
查看已暂存的改动 |
git remote -v |
查看远程仓库地址 |
十三、学习路线建议
安装 Git → 配置用户名和邮箱
↓
git init / git clone → 创建第一个仓库
↓
git add + git commit → 学会提交代码
↓
git log + git status → 学会查看状态和历史
↓
git branch + git checkout → 学会分支操作
↓
git merge → 学会合并、处理冲突
↓
git remote + git push + git pull → 学会远程协作
↓
git stash + git reset + git restore → 学会撤销和回退
↓
git rebase + cherry-pick → 进阶操作
↓
GitHub PR / Code Review → 团队协作流程不需要一次学完 。先掌握
status、add、commit、push、pull、branch、merge这 7 个命令，你已经能应付 80% 的日常场景。遇到新需求时再查对应的命令。
十四、总结
Git 不是选修课，是程序员的必修课。无论你是独立开发者还是团队的一员，Git 都是你代码安全网和工作流的基石。
三个最重要的习惯：
- 频繁 commit，有意义的 message --- 小步提交，方便回溯
- 不在 main 上直接写代码 --- 分支开发，PR 合并
- push 前先 pull --- 保持同步，减少冲突
AI 编程时代，写代码的效率翻倍了，但 Git 的决策权始终在你手里。AI 能帮你写 commit message、帮你解决冲突、帮你生成 PR 描述------但理解 Git 原理，才是你真正的护城河。
本文基于 Git 2.47+ 版本编写，覆盖 2026 年主流开发流程。Git 命令极其稳定，本文内容在未来 5-10 年内都适用。