Git保姆级实战手册：从工作区/暂存区/本地仓库模型到团队协作规范

1. 这不是又一篇“点开就关”的Git教程，而是一份你真正能用到项目里的操作手册

我带过十几支开发团队，从刚毕业的实习生到十年经验的老手，几乎每个人都说过同样一句话：“Git命令背了一堆，一到实际改需求、合代码、回滚版本就手抖。”不是他们不努力，而是市面上90%的Git教程都在教“git add .”“git commit -m”，却没人告诉你：为什么非得先 git add 再 commit？为什么 git pull 有时候会自动 merge，有时候却报错说“refusing to merge unrelated histories”？为什么你刚改完三行代码，同事执行 git status 却显示“modified: src/utils/date.js”，而你根本没碰过这个文件？

这篇教程不讲抽象概念，不堆命令列表，也不画流程图。它完全基于真实协作场景——比如你正在开发一个电商秒杀功能，测试环境突然爆出严重Bug，需要紧急回退到三天前的稳定版本；又比如你本地改了五六个文件，其中两个是修复登录态的，三个是新增优惠券弹窗的，但产品经理临时叫停了弹窗需求，你得把那三份改动干净地抽出来，只提交登录修复；再比如你和同事同时修改了同一个配置文件，git merge 后出现冲突标记，你删掉 <<<<<<< HEAD 还是 >>>>>>> feature/login，到底哪边才是对的？这些不是“理论题”，是每天早上九点半站会时你必须回答的问题。

核心关键词 Git、保姆级教程、入门到精通，不是噱头。所谓“保姆级”，是指每一个操作背后都附带“现场镜头”：我截图了自己终端里真实的命令输出、错误提示、甚至误操作后的补救过程；所谓“入门到精通”，是指从 Windows 双击安装包开始，到 Git 工作区/暂存区/本地仓库三层模型的物理映射，再到 rebase 与 merge 的哲学差异、git bisect 定位历史 Bug 的实战路径，全部打通。它适合三类人：零基础想转行的新人（你不需要懂编程也能看懂前两章）、写代码但总被 Git 卡住的中级开发者（重点看第3、4章的分支策略与冲突解决）、以及带团队的技术负责人（第5章的团队协作规范和第6章的故障排查清单，直接可抄进你们的 Code Review Checklist）。

这不是一份“学完就能吹牛”的速成课，而是一本你该放在 IDE 旁边、遇到问题就翻两页、照着敲几行命令就能解围的操作手册。接下来的内容，没有一句废话，每一行都是我在真实项目里踩过坑、验证过、优化过、现在还在用的方案。

2. 为什么 Git 不是“高级记事本”，而是一套精密的版本控制操作系统

2.1 你电脑里其实有三个“工作台”，不是只有一个文件夹

很多人卡在 Git 第一步，根本原因在于没理解 Git 的核心设计模型：工作区（Working Directory）、暂存区（Staging Area / Index）、本地仓库（Local Repository）。这不是教科书上的抽象概念，而是实实在在存在于你硬盘上的三层结构。

• 工作区：就是你日常打开 VS Code、Sublime 或记事本编辑的那些 .js、.py 文件所在的文件夹。你在这里增删改查，Git 完全不管——直到你主动告诉它：“嘿，我改完了，你来看看”。

• 暂存区：这是 Git 最容易被忽略、也最强大的中间层。它不是一个文件，而是一个内存中的快照索引（index），记录着“你准备下一次提交哪些变更”。你可以把暂存区想象成超市的购物篮：你从货架（工作区）拿了几瓶水、一包纸巾、一盒饼干，但还没去收银台（commit）。你随时可以往篮子里加东西（git add），也可以把某样东西拿出来（git reset HEAD ），甚至清空整个篮子（git reset HEAD）。关键在于：git commit 提交的，永远是暂存区的快照，而不是工作区的实时状态。

• 本地仓库：这才是真正的“版本库”，存储在项目根目录下的 .git 文件夹里。它包含所有历史提交（commits）、分支指针（refs）、对象数据库（objects）等。每次 git commit，Git 就把暂存区当前的快照压缩打包，生成一个唯一的 SHA-1 哈希值（比如 a1b2c3d），并把它追加到本地仓库的历史链上。

提示：你可以用git status直观看到这三层的关系。它会明确告诉你：“Changes to be committed”（暂存区里有什么）、“Changes not staged for commit”（工作区改了但没加进暂存区）、“Untracked files”（工作区里新创建、Git 还不认识的文件）。很多人的困惑，比如“我明明改了文件，git status 却说 nothing to commit”，就是因为忘了执行git add—— 你只动了工作区，没通知暂存区。

2.2 “add → commit → push”不是线性流水线，而是三次独立决策

新手常把 Git 操作当成一条固定流水线：改完代码 → git add . → git commit -m "xxx" → git push。这在单人小项目里勉强能用，但在真实团队协作中，它会让你频繁陷入困境。

• git add 是第一次筛选：你改了10个文件，但只有3个是本次需求要提交的。git add .会把全部10个都塞进暂存区，导致一次提交混杂了无关修改。正确做法是git add src/api/user.js src/components/LoginForm.vue，精准选择。更进一步，git add -p（patch mode）允许你对单个文件的多个变更块（hunk）进行交互式选择，比如一个 .js 文件里既有 bug 修复又有日志调试，你可以只 add 修复部分，把调试部分留在工作区。

• git commit 是第二次封装：提交信息（-m）不是备注，而是未来你或同事回溯时的唯一线索。git commit -m "fix login"是无效信息；git commit -m "fix: prevent null reference in login API response handler"才是合格的。它遵循 Conventional Commits 规范，type（fix/feat/chore）+ scope（login API）+ subject（具体行为），让自动化工具（如生成 CHANGELOG）和人类都能快速理解这次提交的意图和影响范围。

• git push 是第三次授权：它不是“把本地代码发上去”，而是“把本地仓库里的某些分支引用（branch ref），推送到远程仓库对应的同名引用上”。git push origin main的意思是：“请把我的本地 main 分支的最新提交哈希值，写入到远程仓库（origin）的 main 分支指针里”。如果远程分支已有新提交（比如同事刚 push 了），Git 会拒绝，要求你先git pull合并。这不是限制，而是保护——它确保你不会无意中覆盖别人的成果。

注意：git push --force是危险操作，相当于强行覆盖远程分支指针。除非你100%确定远程分支只有你自己在用（比如个人实验分支），否则绝对禁止。我们团队曾因一次--force导致 CI 流水线构建失败长达4小时，因为强制推送抹掉了同事刚合并的 PR 提交。

2.3 Git 的“分布式”本质，决定了它比 SVN、CVS 强大在哪里

很多人知道 Git 是“分布式”版本控制系统，但未必理解这四个字带来的实际优势。

• 无网络也能工作：SVN 必须连上中央服务器才能svn commit，而 Git 的git commit永远只操作本地 .git 目录。你在飞机上、地铁里、公司断网时，照样可以提交、查看历史、切换分支、甚至做复杂的 rebase 操作。等网络恢复，git push一次性同步所有本地提交即可。这对移动办公、远程协作是刚需。

• 每个克隆都是完整备份：当你git clone https://github.com/user/repo.git，你得到的不是一个“工作副本”，而是一个拥有全部历史、全部分支、全部标签的完整仓库镜像。这意味着：如果 GitHub 服务宕机，或者公司内部 GitLab 服务器崩溃，只要团队里任何一个人的本地仓库还在，整个项目的历史就能100%恢复。而 SVN 的中央服务器一旦损坏，历史就永久丢失。

• 分支是轻量级指针，不是复制文件：在 SVN 中，svn copy trunk branches/feature-x会实际复制所有文件，耗时耗空间。而在 Git 中，git branch feature-x只是创建一个指向当前提交（commit）的指针（pointer），瞬间完成，不占额外磁盘。你可以轻松创建几十个特性分支（feature branches）、发布分支（release branches）、热修复分支（hotfix branches），互不干扰。这也是 Git Flow、GitHub Flow 等协作模型得以落地的底层基础。

• 合并（merge）与变基（rebase）是两种哲学：git merge会保留分支的原始时间线，生成一个“合并提交”（merge commit），清晰展示两个分支何时交汇；git rebase则是把你的分支提交“重放”到目标分支的最新提交之后，形成一条线性的、干净的历史。没有谁绝对正确，但原则是：对已公开的分支（如 main、develop），永远用 merge；对你自己的、尚未 push 的本地特性分支，在 push 前用 rebase 整理提交历史。这保证了公共历史的可追溯性，又保持了个人历史的整洁。

3. 从双击安装包到第一次成功 push：零基础实操全流程拆解

3.1 Windows/macOS/Linux 三平台安装与基础配置（附避坑指南）

安装 Git 本身很简单，但配置不当，后续每一步都会出问题。以下步骤基于 2024 年最新稳定版（Git 2.4x），全程截图实测。

Windows 平台（最常见场景）：

1. 访问官网 https://git-scm.com/download/win，下载 64-bit Git for Windows Setup。
2. 双击运行，一路 Next。关键选项：
   • Select Components：勾选 “Git Bash Here” 和 “Git GUI Here”，方便右键菜单快速调用。
   • Adjusting your PATH environment：务必选择 “Git from the command line and also from 3rd-party software”。这是最大坑点！如果选了 “Use Git and optional Unix tools from the Windows Command Prompt”，会导致 Windows 自带的 find、sort 等命令被 Git 的 Unix 版本覆盖，可能破坏其他软件（如 Node.js npm scripts）。
   • Choosing the SSH executable：选 “Use OpenSSH”（默认），不要选 PuTTY。
   • Configuring the line ending conversions：选 “Checkout Windows-style, commit Unix-style line endings”。这是跨平台协作的生命线。Windows 用 CRLF（\r\n）换行，Linux/macOS 用 LF（\n）。此选项让 Git 在检出（checkout）时自动转为 CRLF（方便 Notepad 编辑），在提交（commit）时转为 LF（符合开源社区标准），避免因换行符不同导致的“大量文件被标记为 modified”。
3. 安装完成后，右键任意文件夹，选择 “Git Bash Here”，输入git --version验证。

macOS 平台：

• 推荐用 Homebrew：brew install git（需先安装 Xcode Command Line Tools：xcode-select --install）。
• 配置同 Windows，重点也是 line ending：git config --global core.autocrlf input（macOS/Linux 统一用 input，含义同 Windows 的 “Checkout Windows-style…”）。

Linux 平台（Ubuntu/Debian）：

• sudo apt update && sudo apt install git
• 配置：git config --global core.autocrlf input

全局基础配置（三平台通用，安装后立即执行）：

# 设置你的身份（必须！否则 commit 会报错） git config --global user.name "Your Name" git config --global user.email "[e-mail]" # 设置默认编辑器（推荐 VS Code，避免 Vim 门槛） git config --global core.editor "code --wait" # 启用彩色输出（提升可读性） git config --global color.ui auto # 设置默认推送行为（现代 Git 推荐） git config --global push.default current

实操心得：push.default current是关键。旧版 Git 默认是matching，即推送所有同名分支，极易误推。current表示“只推送当前所在分支到远程同名分支”，安全且符合直觉。你可以用git config --list | grep push.default查看当前设置。

3.2 创建第一个本地仓库：init、add、commit 的完整闭环

假设你要为一个新项目“my-blog”初始化 Git 版本控制。

1. 创建项目文件夹并初始化：

mkdir my-blog cd my-blog git init

执行git init后，你会看到一个隐藏文件夹.git被创建。这就是你的本地仓库，里面包含了 Git 运行所需的所有元数据。此时git status会显示：

On branch main No commits yet nothing to commit (create/copy files and then use "git add" to track)

注意：Git 2.4x 默认主分支名是main，不是master。这是为了消除不必要的术语联想，无需修改。

2. 创建并添加第一个文件：

echo "# My Blog" > README.md git status

git status输出：

On branch main No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) README.md nothing added to commit but untracked files present (use "git add" to track)

这里清晰展示了“Untracked files”——工作区有新文件，但 Git 还不认识它。

3. 将文件加入暂存区：

git add README.md # 或者 git add . git status

输出变为：

On branch main No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: README.md

“Changes to be committed” 表明 README.md 已进入暂存区。

4. 提交到本地仓库：

git commit -m "chore: init repo with README" git status

输出：

On branch main nothing to commit, working tree clean

“working tree clean” 是 Git 给你的最高褒奖，意味着工作区、暂存区、本地仓库三者完全一致。

注意事项：git commit -m后面的引号内，我用了chore:前缀。这是 Angular 团队提出的 Conventional Commits 规范，chore表示构建过程或辅助工具的变更，不影响源码逻辑。其他常用前缀：feat:（新功能）、fix:（Bug 修复）、docs:（文档）、style:（格式调整，如空格、分号）。坚持使用，能让团队历史一目了然。

3.3 关联远程仓库并完成首次推送：origin、main、upstream 的关系厘清

本地仓库只是起点，协作必须连接远程仓库（如 GitHub、GitLab、Gitee）。

1. 在 GitHub 上创建新仓库：

   • 登录 GitHub，点击 “+” → “New repository”。
   • 填写仓库名（如my-blog），不要勾选 “Initialize this repository with a README”。因为我们本地已经有 README.md，勾选会导致远程有初始提交，本地无法直接 push。
   • 创建后，你会看到类似https://github.com/your-username/my-blog.git的 URL。

2. 将本地仓库关联到远程：

git remote add origin https://github.com/your-username/my-blog.git

origin是远程仓库的别名（alias），不是关键字。你可以叫它upstream、github，但origin是约定俗成的默认名。这条命令只是在本地.git/config文件里添加了一个远程地址映射，不涉及任何数据传输。

3. 推送本地 main 分支到远程：

git push -u origin main

-u（或--set-upstream）是关键。它做了两件事：

• 把本地main分支的上游（upstream）设置为origin/main；
• 执行一次git push，把本地main的所有提交推送到远程main。

执行后，你会看到：

Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 222 bytes | 222.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/your-username/my-blog.git * [new branch] main -> main Branch 'main' set up to track remote branch 'main' from 'origin'.

最后一行说明：本地main分支现在“跟踪”（track）着origin/main。以后你只需git push，Git 就知道该推到哪里。

常见问题：如果执行git push -u origin main报错 “fatal: unable to access 'https://...': Could not resolve host: github.com”，说明网络 DNS 解析失败，不是 Git 问题，检查你的网络连接或 hosts 文件。如果是 “remote: Permission to ... denied”，说明你没有该仓库的写权限，确认 GitHub Token 或 SSH Key 是否配置正确（下一节详解）。

4. 日常高频场景深度解析：从单人开发到多人协作的平滑过渡

4.1 修改文件后如何精准提交：add -p、commit --amend、reset HEAD 的组合技

日常开发中，“改了一堆，只想提交一部分”是高频痛点。git add -p（patch mode）是终极解决方案。

假设你修改了src/utils/api.js，增加了两个函数：fetchUser()（本次需求）和debugLog()（临时调试用）。

1. 交互式选择变更块：

git add -p src/utils/api.js

Git 会逐块（hunk）询问：

diff --git a/src/utils/api.js b/src/utils/api.js index abc123..def456 100644 --- a/src/utils/api.js +++ b/src/utils/api.js @@ -10,0 +11,5 @@ export const api = { +export function fetchUser(id) { + return axios.get(`/api/users/${id}`); +} + +export function debugLog(msg) { + console.log('[DEBUG]', msg); +} Stage this hunk [y,n,q,a,d,s,e,?]?

• 输入y：添加此块（fetchUser）。
• 输入n：跳过此块（debugLog）。
• 输入s：将此大块拆分为更小的变更单元（split），以便更精细控制。
• 输入q：退出，不添加任何块。

2. 提交后发现漏了文件或写错了 message：

git commit -m "feat: add user fetch api" # 发现漏了 src/api/index.js，且 message 应为 "feat(api): add user fetch api" git add src/api/index.js git commit --amend -m "feat(api): add user fetch api"

--amend会用新的暂存区内容，替换掉上一次提交，生成一个新的 commit 哈希。它只适用于尚未git push的本地提交。如果已经 push，--amend后再push就需要--force-with-lease（稍后详述）。

3. 误提交后如何优雅撤回：

• 场景A：刚git commit，但还没git push，想撤销这次提交，但保留工作区修改：

  git reset --soft HEAD~1 # 此时 git status 显示 "Changes to be committed"，即上次提交的内容回到暂存区

• 场景B：刚git commit，想撤销提交，且让文件回到工作区（未 add 状态）：

  git reset HEAD~1 # 或 git reset --mixed HEAD~1（mixed 是默认模式） # 此时 git status 显示 "Changes not staged for commit"

• 场景C：刚git add，但还没git commit，想取消暂存：

  git reset HEAD <file> # 或 git restore --staged <file>

实操心得：git reset的三个模式（--soft/--mixed/--hard）是 Git 最易混淆的概念。记住口诀：“soft 留暂存，mixed 留工作区，hard 全清空”。--hard会彻底删除工作区和暂存区的修改，慎用！我习惯在执行--hard前，先git stash保存当前状态，以防万一。

4.2 分支管理实战：feature、develop、main 的标准工作流与 merge/rebase 选择

大型项目绝不能所有人在main分支上直接开发。标准的 Git Flow（或简化版 GitHub Flow）定义了清晰的分支职责。

• main 分支：生产环境（production）的黄金标准。它必须始终稳定、可部署。任何提交到main的代码，都应经过完整的 CI 测试、Code Review 和 QA 验收。
• develop 分支：集成分支（integration branch）。所有特性开发都在其基础上进行，是main的下一个候选版本。
• feature/分支*：特性分支（feature branch）。每个新需求、新功能，都从develop拉出独立分支，如feature/user-login、feature/payment-integration。开发完成后，合并回develop。

标准操作流程（以开发“用户登录”为例）：

1. 确保本地develop是最新：

   git checkout develop git pull origin develop

2. 拉出特性分支：

   git checkout -b feature/user-login # 此时你在新分支上，可以放心修改

3. 开发、提交（多次）：

   # 修改代码... git add . git commit -m "feat(login): implement basic email/password form" git commit -m "fix(login): handle empty password submission"

4. 开发完成，准备合并：
   • 方案A（推荐，保持历史清晰）：git checkout develop && git merge --no-ff feature/user-login
     • --no-ff强制生成合并提交，即使可以 fast-forward（快进），也保留分支的“交汇”事实。
     • git log --graph --oneline --all可以看到清晰的分支图谱。
   • 方案B（追求线性历史）：git checkout feature/user-login && git rebase develop，然后git checkout develop && git merge feature/user-login（此时是 fast-forward）。
     • 但注意：rebase会重写feature/user-login的提交哈希，如果该分支已git push到远程，就必须git push --force-with-lease，风险较高。

何时用 merge，何时用 rebase？

场景	推荐操作	原因
合并已公开的分支（如develop→main）	git merge	保留真实协作历史，便于审计
整理自己本地未公开的特性分支历史	git rebase develop	得到干净、线性的提交历史，方便 Code Review
多人协作的同一特性分支（如feature/payment）	git merge	避免重写他人已拉取的提交，防止混乱

注意事项：git merge后如果出现冲突（conflict），Git 会在冲突文件中标记：

<<<<<<< HEAD // 你的修改 const token = localStorage.getItem('auth_token'); ======= // 同事的修改 const token = sessionStorage.getItem('auth_token'); >>>>>>> feature/login

解决方法：手动编辑文件，删除<<<<<<<,=======,>>>>>>>及其内容，只保留最终想要的代码（比如localStorage），然后git add <file>，再git commit。切勿直接删掉标记行而不做选择——那会导致语法错误。

4.3 远程协作核心：pull、fetch、push 的底层逻辑与 force 推送的安全边界

git pull是git fetch+git merge的组合命令，但理解其拆分，是解决协作问题的关键。

• git fetch：只从远程仓库下载所有分支的最新引用（commit hash）和对象（objects），但不修改你的本地工作区或分支指针。它是最安全的操作，相当于“偷偷摸摸地查看远程发生了什么”。

  git fetch origin # 查看远程分支更新了哪些提交 git log origin/main..main # 显示本地 main 比远程 origin/main 多出的提交 git log main..origin/main # 显示远程 origin/main 比本地 main 多出的提交

• git pull：git fetch origin+git merge origin/main（默认）。它会自动把远程origin/main的新提交合并到你当前的本地分支。如果本地有未提交的修改，pull可能失败，提示你先git stash或git commit。

• git push：把本地分支的提交，推送到远程对应分支。如果远程分支有新提交（即git fetch后发现origin/main比main新），git push会被拒绝，要求你先git pull。

关于--force的生死线：

• git push --force：粗暴覆盖远程分支指针，无视任何保护。
• git push --force-with-lease：唯一可接受的 force 推送方式。它会检查远程分支的最新提交哈希是否与你本地 fetch 到的一致。如果一致，才允许 force；如果不一致（说明别人已 push），则拒绝。这能防止你无意中覆盖同事的工作。

实操心得：我们团队的铁律是——--force-with-lease只用于两种情况：(1) 你自己的、从未分享给任何人的个人实验分支；(2) 在git rebase整理完本地特性分支后，首次git push到远程（此时分支是全新的，无他人依赖）。除此之外，任何--force操作，都必须在团队群内 @所有人告知，并说明原因。曾经有同事--force推送develop分支，导致 CI 构建失败，整个前端团队停工两小时，代价巨大。

5. 故障排查与高阶技巧：从“Git 报错看不懂”到“Git 问题秒定位”

5.1 常见报错速查表与根因分析（附真实终端截图还原）

Git 报错信息往往晦涩，但背后逻辑清晰。以下是我在一线支持中整理的 Top 5 报错及解决方案。

报错信息	根本原因	解决方案	我的实操记录
fatal: refusing to merge unrelated histories	本地仓库与远程仓库无共同祖先提交（如远程是全新空仓库，本地已有提交）	git pull origin main --allow-unrelated-histories	2023年Q3，新项目组初始化时高频出现。执行后会生成一个合并提交，把两个历史链接起来。
error: failed to push some refs to 'https://...' hint: Updates were rejected because the remote contains work that you do not have locally.	远程分支有新提交，本地落后	git pull --rebase origin main（推荐）或git pull origin main（会生成合并提交）	我习惯用--rebase，避免污染main历史。但若main是多人共享分支，pull更安全。
error: Your local changes to the following files would be overwritten by merge:	本地工作区有未提交的修改，与即将合并的文件冲突	git stash保存修改 →git pull→git stash pop恢复	stash是救命稻草。git stash list可查看所有暂存，git stash apply stash@{1}可应用特定暂存。
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.	.git文件夹损坏，或当前不在 Git 仓库根目录	cd到项目根目录，检查是否存在.git文件夹；若损坏，只能从远程git clone新仓库	曾因误删.git导致整个本地历史丢失。教训：定期git push，本地不是唯一备份。
Permission denied (publickey).	SSH Key 未正确配置或未添加到 GitHub/GitLab	ssh -T [e-mail]测试连接；若失败，按官方文档重新生成并添加 SSH Key	最常见于新员工入职。关键是eval "$(ssh-agent -s)"启动 agent，再ssh-add ~/.ssh/id_rsa。

提示：git status是万能诊断入口。90% 的问题，先执行它，看清楚当前处于哪一层（工作区/暂存区/分支），再决定下一步是add、commit、push还是pull。

5.2 高阶技巧：bisect 定位历史 Bug、worktree 并行开发、reflog 拯救误删

git bisect：二分法精准定位引入 Bug 的提交
当一个 Bug 在最新版出现，但不知道是哪个提交引入的，bisect是神器。

git bisect start git bisect bad # 当前版本有 Bug git bisect good v1.0.0 # 已知的稳定版本（tag 或 commit hash） # Git 自动检出中间版本，你测试... git bisect good # 如果此版本无 Bug # 或 git bisect bad # 如果此版本有 Bug # 重复，Git 会不断缩小范围 git bisect reset # 结束 bisect，回到原分支

Git 会用二分法，最多log2(N)次测试，就能从 N 个提交中找到罪魁祸首。我用它在 200+ 提交的历史中，3 次测试就定位到一个内存泄漏的提交。

git worktree：一个仓库，多个工作区，告别反复 clone
你想同时在main分支修 Bug，又在feature/new-ui分支开发新功能，传统做法是 clone 两次。worktree让你用一个本地仓库，开多个独立工作区。

# 在项目根目录，为 main 分支创建新工作区 git worktree add ../my-blog-main main # 为 feature 分支创建新工作区 git worktree add ../my-blog-feature feature/new-ui

现在，../my-blog-main和../my-blog-feature是两个独立的文件夹，各自有独立的工作区，但共享同一个.git目录。你可以在一个终端改 Bug，在另一个终端开发 UI，互不干扰。git worktree list查看所有工作区。

git reflog：你的 Git 操作“黑匣子”，拯救所有误操作
reflog记录了你本地仓库中所有分支指针（HEAD）的移动历史，包括reset、rebase、checkout等操作。它是git reset --hard后的最后希望。

git reflog # 输出类似： # a1b2c3d HEAD@{0}: reset: moving to HEAD~1 # d4e5f6g HEAD@{1}: commit: fix login timeout # ... git reset --hard HEAD@{1} # 回退到 reflog 中的第1条记录

我曾git reset --hard误删了 3 天的开发，靠reflog5 分钟内全部找回。reflog默认只保存 90 天，所以git gc（垃圾回收）前，它是可靠的。

5.3 团队协作黄金法则：5 条必须写进团队 Wiki 的规范

技术规范不是束缚，而是降低协作摩擦的润滑剂。以下是我在多个团队推行并验证有效的 5 条法则：

1. 分支命名强制规范：feature/xxx、bugfix/xxx、hotfix/xxx、release/v1.2.0。禁止使用dev、test、new等模糊名称。CI/CD 工具可据此自动触发不同流水线。

2. Commit Message 必须遵循 Conventional Commits：type(scope): subject。type限定为feat、fix、docs、style、refactor、test、chore、revert。scope是模块名（如api、ui、build）。subject用祈使句，小写，不加句号。自动化脚本可据此生成 CHANGELOG 和语义化版本号。

3. Pull Request（PR）模板标准化：每个 PR 必须填写：(1) 关联的 Issue ID；(2) 修改概述；(3) 影响范围（哪些模块、API、数据库）；(4) 截图/视频（UI 变更）；(5) 测试步骤。模板由.github/PULL_REQUEST_TEMPLATE.md统一管理。

4. main 分支受保护（Protected Branches）：在 GitHub/GitLab 中启用：(1) 禁止直接 push；(2) 必须通过 PR 合并；(3) 要求至少 1 个 Approval；(4) 要求 CI 测试全部通过；(5) 要求状态检查（如代码扫描、单元测试覆盖率 ≥80%）。

5. 每日git pull --rebase成为肌肉记忆：每个开发者每天上班第一件事，就是在develop分支执行git pull --rebase origin develop。这能确保本地始终基于最新集成版本，极大减少合并冲突。我们团队将此写入