Git新手实操手册：从不敢敲命令到团队安全协作

1. 这不是“又一本Git教程”，而是一份能让你今天就敢在真实项目里敲命令的实操手册

你点开这个标题，大概率正卡在某个地方：刚 clone 下来一个仓库，想改两行代码却不敢动，怕一不小心就把整个团队的进度搞崩；或者被同事一句“你 git add -A 之前没 git status 看一眼？”问得哑口无言；又或者，你已经背熟了“工作区、暂存区、本地仓库”三个名词，但当终端里跳出 CONFLICT (content): Merge conflict in src/utils.js 的时候，手还是悬在键盘上不敢敲回车。别慌——这不是你笨，是绝大多数 Git 教程从一开始就走错了路：它们把 Git 当成一门语言来教语法，而 Git 本质上是一个 协作操作系统 ，它的每个命令，都是为了解决一个具体、高频、带痛感的真实问题。我带过 27 个不同技术栈的开发团队，从嵌入式固件到前端微服务，发现新手最常摔跤的从来不是 rebase 和 cherry-pick 这类高阶操作，而是 git pull 后文件莫名消失、 git push 被拒绝、甚至 git commit 提交了错误的文件却不知道怎么撤回。这篇内容不讲“分布式版本控制原理”，不画抽象的状态机图，只聚焦三件事：第一，你每天早上打开电脑后实际要做的前 5 个动作，每个命令背后发生了什么、为什么必须这么写；第二，当终端报错时，如何像读诊断书一样快速定位问题根源，而不是复制粘贴报错信息去搜“git xxx failed”；第三，所有示例全部基于真实项目结构——有 package.json 的前端工程、有 requirements.txt 的 Python 服务、有 .gitignore 里写了 __pycache__/ 却依然被提交的尴尬现场。它不承诺让你成为 Git 大师，但保证你读完第 3 小节后，就能独立完成一次无风险的特性分支开发与合并。关键词：git beginner tutorial、git commands explained、git workflow for teams、git merge vs rebase、git undo mistakes。

2. 为什么“从零开始学 Git”是最大误区？——重新理解 Git 的底层设计逻辑

2.1 Git 不是“保存历史”，而是“构建可验证的协作契约”

很多初学者以为 git commit 就是“保存当前代码快照”，这就像说“汽车引擎的作用是让轮子转起来”——没错，但完全没抓住要害。Git 的核心设计哲学，是把每一次代码变更都变成一份 带数字签名的法律契约 。当你执行 git commit -m "fix login timeout" ，Git 干了三件关键事：

1. 计算内容指纹 ：对工作区所有已 git add 的文件内容，用 SHA-1 算法生成唯一哈希值（如 a1b2c3d... ），这个值就是该次提交的“身份证号”，任何字节改动都会导致哈希值彻底改变；
2. 构建链式证据链 ：新提交会明确记录上一个提交的哈希值（parent commit），形成一条不可篡改的时间链；
3. 绑定作者身份 ：自动写入你的 user.name 和 user.email （注意：这不是邮箱登录凭证，只是署名标识），并打上精确到秒的时间戳。

这意味着，Git 仓库里没有“修改记录”，只有 一系列自证清白的、带时间戳和作者签名的完整状态快照 。所以 git log 不是“查看历史”，而是“调取司法档案”； git blame 不是“找背锅人”，而是“追溯某行代码的法定责任人”。我曾处理过一个线上事故：用户反馈支付接口返回空数据。运维直接 git checkout 切到上周版本，问题消失。但真正关键的是 git blame api/payment.py —— 它立刻指出第 47 行 return {} 是 3 天前由 dev-frontend 提交的，而该提交信息写着 “临时注释掉校验逻辑便于联调”，真相瞬间浮出水面。这种可追溯性，才是 Git 在团队协作中不可替代的价值。

2.2 三大区域不是“概念”，而是物理存在的三块硬盘分区

教科书常说“工作区、暂存区、本地仓库”，但新手根本无法建立空间感。换种说法：把 Git 想象成你办公桌上的三个物理抽屉：

• 工作区（Working Directory） ：就是你肉眼可见的整个项目文件夹，比如 ~/my-project/ 。你在这里写代码、删文件、改配置，所有操作都只影响这个抽屉；
• 暂存区（Staging Area / Index） ：一个隐藏的、名为 .git/index 的二进制文件，它不存文件内容，只存“下一步要提交哪些文件的哪些版本”的清单。你可以把它理解成快递打包台——你把要寄出的包裹（文件）一件件放上去，但还没贴单发货；
• 本地仓库（Local Repository） ： .git/ 文件夹本身，里面是 Git 的“中央数据库”，所有提交历史、分支指针、对象存储都在这里。它是最终的“发货仓库”，一旦包裹（commit）进了这里，就永久存档。

关键认知突破点在于： git add 不是“添加文件”，而是“把工作区当前状态的快照，登记到暂存区的发货清单上” 。所以 git add . 的本质是：扫描工作区所有文件，计算每个文件的 SHA-1 哈希，然后把“文件路径 + 当前哈希值”写入 .git/index 。这也是为什么 git add 后再改文件， git commit 提交的仍是 add 时的版本——因为发货清单早已锁定。我见过太多人 git add src/ && git commit -m "update frontend" 后，发现漏改了一个 CSS 文件，于是直接 git commit --amend ，结果把本不该提交的 node_modules/ 临时文件也塞进了历史。正确做法永远是：先 git status 看清单，再 git add 精确选择，最后 git commit —— 这不是繁琐，是给协作留下的安全冗余。

2.3 分支不是“平行宇宙”，而是“指向提交的轻量级指针”

新手常被“分支切换像时空穿越”这类比喻误导。实际上， git branch feature/login 这条命令，只是在 .git/refs/heads/ 目录下创建一个纯文本文件 feature/login ，里面只写了一行内容： a1b2c3d... （即当前所在提交的哈希）。分支本身不占用额外空间，它就是一个 41 字节的指针。 git checkout feature/login 的真实动作是：把 HEAD 这个“当前分支游标”指向 feature/login 文件，然后把工作区文件恢复成该指针所指提交的内容快照。所以 git merge main 的本质是：找到 main 分支指针指向的提交，把它作为新提交的第二个父节点（first parent 是当前分支头），然后移动当前分支指针到这个新提交上。没有魔法，只有指针移动和快照拼接。这也解释了为什么 git branch -d 删除分支几乎瞬时完成——它只是删了一个文本文件。我在带新人时，会让大家手动 cat .git/refs/heads/main 看内容，再 git checkout dev 后 cat .git/HEAD ，这种“亲手触摸 Git 内部”的体验，比看十张架构图都管用。

3. 新手每日必用的 5 个命令：从“不敢动”到“稳准狠”的实操拆解

3.1 git status ：不是检查清单，而是你的“协作健康报告”

这是你每天打开终端后第一个该敲的命令，但它被严重低估。 git status 的输出绝非简单罗列文件状态，而是 Git 给你的一份实时协作健康诊断书。我们以一个真实前端项目为例：

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   src/components/LoginForm.jsx
        modified:   src/utils/api.js

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/components/PasswordResetModal.jsx
        package-lock.json

no changes added to commit (use "git add" and/or "git commit -a")

逐行解读其潜台词：

• On branch main ：你当前站在 main 这条“主干道”上，所有操作默认影响此分支；
• Your branch is up to date with 'origin/main' ：本地 main 分支指针和远程 origin/main 指向同一个提交，说明你没落后于团队；
• Changes not staged for commit ：工作区有 2 个文件被修改，但尚未放入暂存区（发货清单）。注意括号里的提示： git restore 是 Git 2.23+ 推荐的弃用 git checkout -- 的新命令，用于丢弃工作区修改；
• Untracked files ：2 个全新文件，Git 完全不认识它们。 package-lock.json 出现在这里，说明你可能刚运行 npm install ，但 .gitignore 里没配置它（这是常见疏漏！）；
• no changes added to commit ：暂存区为空，意味着即使你此刻 git commit ，也不会提交任何东西。

提示：永远用 git status -s （short format）代替默认输出。它用极简符号编码状态： M （modified）、 A （added）、 D （deleted）、 ?? （untracked），一行一个文件，扫一眼 3 秒内掌握全局。我团队所有成员的 shell 提示符都集成了 git status -s ，只要目录在 Git 仓库内，提示符末尾就会显示当前分支和状态简码，比如 (main ↑2) 表示 main 分支，有 2 个未推送提交。

3.2 git add ：精准控制“发货清单”，避开 90% 的误提交

git add 是新手最容易滥用的命令。 git add . 看似省事，实则埋雷。我们拆解三种精准添加策略：

场景一：只添加特定文件

git add src/components/LoginForm.jsx src/utils/api.js

这是最安全的方式，明确指定要提交的文件。适合修复单个 bug 或实现小功能。

场景二：交互式添加（推荐给复杂修改）

git add -p

-p （patch）参数启动交互模式。Git 会把每个文件的修改拆分成“补丁块”（hunk），逐块询问：

Stage this hunk [y,n,q,a,d,s,e,?]? 

• y ：添加此块
• n ：跳过此块
• s ：将此块进一步拆分为更小粒度（比如把一个函数的多处修改分开）
• e ：手动编辑此块（高级用法，可删除某几行）
  这招在我处理一个包含 200 行修改的 config.py 时救了大命——其中只有 3 行是真正的配置变更，其余全是调试日志， git add -p 让我精准剔除噪音。

场景三：反选添加（处理意外污染）
假设你 git add . 后发现误加了 dist/ 目录（构建产物），但其他文件确实要提交：

git reset dist/          # 从暂存区移除 dist/
git add -u               # -u 参数只添加已跟踪文件的修改，忽略新增文件

git add -u 是 git add --update 的简写，它只扫描那些 Git 已知的文件（即之前 commit 过的），对 dist/ 这种从未提交过的目录视而不见，完美避开“误删”风险。

注意： .gitignore 不是“防火墙”，而是“免检通道”。它只告诉 Git “不要把匹配的文件加入暂存区”，但如果你手动 git add ignored-file.log ，Git 照样接受。所以 .gitignore 必须在首次 git add 前就配置好。我团队的初始化脚本强制检查 .gitignore 是否包含 node_modules/ , __pycache__/ , *.log , *.swp 等 12 类通用条目，缺失则阻断 git init 。

3.3 git commit ：写好提交信息，等于给未来自己写说明书

git commit -m "fix bug" 是新手坟墓。好的提交信息不是描述“做了什么”，而是回答“为什么做”和“如何验证”。遵循 Conventional Commits 规范 （社区事实标准）：

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

• <type> ： feat （新功能）、 fix （修复 bug）、 docs （文档）、 style （格式）、 refactor （重构）、 test （测试）、 chore （工具）；
• <scope> ：影响的模块，如 login , api , ui ；
• <subject> ：用祈使句、小写开头、不加句号，如 add password strength validation ；
• <body> ：详细说明动机、技术方案、影响范围（必填！）；
• <footer> ：关联 issue（如 Closes #123 ）或破坏性变更说明（ BREAKING CHANGE: ... ）。

真实案例对比：
❌ 差： git commit -m "update login"
✅ 好：

git commit -m "fix(login): prevent empty password submission" \
-m "Before: LoginForm allowed submit() even when password field was empty, causing 500 error on backend." \
-m "After: Added client-side validation using HTML5 required attribute and custom JS check. Backend validation remains as fallback." \
-m "Closes #456"

这样写的提交，半年后你查 git log --oneline | grep login ，一眼就知道这个提交解决了什么问题、是否影响线上、如何复现。我团队要求 CI 流水线强制校验提交信息格式，不合规则拒绝合并。

3.4 git pull ：不是“同步代码”，而是“安全合并远程变更”

git pull 常被等同于“更新代码”，但它的本质是 git fetch + git merge 的组合拳。危险就藏在 merge 这一步。假设你本地 main 分支有 1 个未推送提交，而远程 main 也有 1 个新提交：

# 你的本地状态：
A -- B (local main, your commit)
     \
      C (origin/main, team's new commit)

# 执行 git pull 后：
A -- B -- D (merged commit)
     \    /
      C

Git 自动创建一个“合并提交” D，把 B 和 C 的变更揉在一起。如果 B 和 C 修改了同一文件的同一行，就会触发 Merge conflict 。

更安全的替代方案： git pull --rebase
它把你的本地提交 B “重放”到远程最新提交 C 之后：

A -- C -- B' (rebased commit)

B' 是 B 的“克隆体”，内容相同但父提交变成了 C，历史变成线性，无合并提交。这需要两个前提：

1. 你的本地提交尚未 push （否则 rebase 会改写已公开的历史）；
2. 团队约定 main 分支只允许 fast-forward 合并（即禁止 merge 提交）。

实操心得：我在所有新成员的 .gitconfig 里预置 pull.rebase=true ，并配上注释：“避免无意义的 merge 提交，保持历史线性可读”。同时要求 PR 描述必须包含 git log --oneline origin/main..HEAD 的输出，确保 reviewer 能一眼看清本次 PR 引入了哪些提交。

3.5 git push ：推送前的最后防线，3 步确认法

git push 是协作的临门一脚，也是事故高发区。我总结出推送前的“3 步确认法”：

第一步：确认目标分支

git status  # 确保 On branch feature/login
git branch -v  # 查看本地分支追踪的远程分支，如 feature/login -> origin/feature/login

警惕 git push origin main 这种裸推——它不指定本地分支，容易推错。永远用 git push origin feature/login 明确指定。

第二步：确认推送内容

git log origin/feature/login..HEAD --oneline  # 查看将要推送的提交
git diff origin/feature/login..HEAD --stat     # 查看将要推送的文件变更统计

如果 --stat 显示 package-lock.json | 12000 + ，立刻停手——这说明你本地 npm install 生成了新锁文件，但团队约定锁文件由 CI 自动生成，此时应 git restore package-lock.json 并重新 npm ci 。

第三步：确认远程权限

git remote show origin  # 查看远程 URL 和推送权限

如果 URL 是 https://github.com/org/repo.git ，你有写权限；如果是 https://github.com/forker/repo.git （别人 fork 的），你只能推到自己的 fork，不能推到主仓库。我曾帮一位新人解决“Permission denied”问题，根源是他 git remote add origin 错误地指向了自己的 fork，而非团队主仓库。

注意： git push --force-with-lease 不是“暴力推送”，而是“有条件的覆盖”。它会检查远程分支的最新提交是否和你本地记录的一致，一致才覆盖，否则失败。这比 --force 安全百倍，是 rebase 后推送的黄金标准。我的 .gitconfig 中设为 push.default = current （推送当前分支到同名远程分支）和 push.followTags = true （自动推送关联 tag），减少人为失误。

4. 从崩溃到掌控：5 个高频灾难现场的急救指南

4.1 场景： git add 误加了敏感文件（如 .env ），还没 commit

这是最高频的“啊！我干了什么！”时刻。解决方案分三步：

Step 1：立即从暂存区移除，但保留工作区文件

git restore --staged .env  # Git 2.23+
# 或旧版：
git reset HEAD .env

--staged 参数确保只操作暂存区， .env 文件在工作区完好无损，你还能继续编辑它。

Step 2：永久阻止 Git 追踪该文件

echo ".env" >> .gitignore
git add .gitignore
git commit -m "chore: ignore .env file"

关键点： .gitignore 只对“未跟踪文件”生效。 .env 已被 add 过，Git 仍会监控它。所以必须 git add .gitignore 并提交，让 Git 知道“从此以后忽略它”。

Step 3：从历史中彻底擦除（如果已 commit 过）
若 .env 已被 git commit ，需 git filter-repo （官方推荐替代 filter-branch 的工具）：

pip install git-filter-repo
git filter-repo --path .env --invert-paths --force
git push --force origin --all

⚠️ 警告：此操作会重写所有提交哈希，必须通知所有协作者 git fetch && git reset --hard origin/main 重建本地仓库。仅在泄露风险极高时使用。

实操心得：我在所有项目模板中预置 .gitignore ，包含 *.env , *.key , config/local.* 等 20+ 条敏感路径，并用 git check-ignore -v .env 命令验证其生效。新成员入职第一课： git status 后，必须 git check-ignore -v * 扫描所有文件，确保无遗漏。

4.2 场景： git commit 提交了错误内容，且尚未 push

git commit --amend 是你的后悔药，但用法有讲究：

情况 A：只想修改提交信息

git commit --amend -m "fix(login): add password validation"

安全，无副作用。

情况 B：想修改提交内容（增删文件）

# 先修正工作区（如删掉误加的 debug.log）
rm debug.log
# 再把暂存区更新为当前工作区状态
git add -u
# 最后 amend
git commit --amend --no-edit  # --no-edit 保留原提交信息

关键： --no-edit 防止误改提交信息。如果连信息也要改，去掉此参数。

情况 C：想撤销整个提交（回到 git add 前状态）

git reset --soft HEAD~1  # 保留工作区和暂存区，只回退提交
# 或更彻底：
git reset --mixed HEAD~1  # 保留工作区，清空暂存区（默认模式）
# 或完全回滚：
git reset --hard HEAD~1   # 工作区、暂存区、提交全部撤销（慎用！）

--soft 最安全，适合“提交了但想重写内容”； --mixed （默认）适合“提交了但想重新选择文件”； --hard 是核按钮，仅在 git log 确认 HEAD~1 是你要的干净状态时使用。

注意： git commit --amend 会生成新提交哈希，如果已 push ，必须 git push --force-with-lease 覆盖。我团队禁用 --force ，所有 amend 后推送必须走 --force-with-lease ，CI 会拦截不合规的 force push。

4.3 场景： git pull 后出现 Merge conflict in src/App.js

冲突不是错误，是 Git 在说：“这两段修改逻辑上无法自动合并，请你人工裁定”。处理流程：

Step 1：定位冲突文件

git status  # 显示 Unmerged paths
# 或直接看文件内容，冲突标记长这样：
<<<<<<< HEAD
console.log("Login success");
=======
console.log("User logged in");
>>>>>>> 7a8b9c0

<<<<<<< HEAD 到 ======= 是你的修改， ======= 到 >>>>>>> 是拉取的远程修改。

Step 2：编辑文件，手动解决
删除所有 <<<<<<< , ======= , >>>>>>> 标记，保留最终想要的代码。例如：

console.log("User logged in successfully"); // 合并后的理想状态

Step 3：标记为已解决并提交

git add src/App.js  # 告诉 Git “这个文件的冲突已解决”
git commit -m "resolve merge conflict in App.js"

Git 会自动生成一个合并提交，包含两个父提交。

实操心得：VS Code 的 GitLens 插件能可视化显示冲突来源（谁在何时修改了哪行），比纯文本快 3 倍。我要求所有前端开发者安装，并在 PR 描述中截图冲突解决过程，作为代码审查的一部分。另外， git checkout --ours src/App.js （保留我的版本）或 git checkout --theirs src/App.js （保留远程版本）是快速解决简单冲突的快捷键，但务必先 git diff 确认差异。

4.4 场景： git push 被拒绝，提示 ! [rejected] main -> main (non-fast-forward)

这表示远程 main 分支有你本地没有的提交（比如同事刚推送了新代码），而你的推送会覆盖它。强行 --force 会丢失同事的工作！正确解法：

Step 1：拉取远程最新变更

git fetch origin  # 只下载对象，不合并

Step 2：将你的提交“重放”到远程最新基础上

git rebase origin/main

如果重放过程中出现冲突，按 4.3 节方法解决，然后 git add 冲突文件，再 git rebase --continue 。

Step 3：推送重放后的分支

git push --force-with-lease origin main

--force-with-lease 确保推送时远程 main 仍是 fetch 时的状态，防止同事在此期间又推送了新提交。

注意： rebase 会改写提交哈希，所以 git log 里你的提交会变成新的哈希。这是正常现象。我团队的 CI 流水线配置了 git config --global pull.rebase true ，让 git pull 默认执行 rebase ，从源头减少此类问题。

4.5 场景：完全搞乱了，想回到 git clone 后的纯净状态

当 git status 输出一片红色， git log 看不懂， git reflog 也晕头转向时，终极方案是“硬重置”：

Step 1：备份当前工作区（万不得已时救命）

tar -czf ~/backup-$(date +%s).tar.gz .  # 打包整个工作区

Step 2：彻底清理，回到最近一次 commit 的状态

git reset --hard HEAD      # 丢弃所有未 commit 的修改
git clean -fd              # -f 强制，-d 删除目录，清除所有 untracked 文件

git clean -fd 会删除 .gitignore 之外的所有文件，包括 node_modules/ 、 dist/ 等。执行前务必 git status 确认无重要 untracked 文件。

Step 3：如果连 commit 都错了，回退到指定提交

git reset --hard a1b2c3d   # a1b2c3d 是你想回到的提交哈希

git reflog 命令能查到所有 HEAD 的移动历史，比如 HEAD@{2}: checkout: moving from feature/login to main ，从中找到安全的哈希值。

实操心得：我给所有新成员的 shell 配置了 alias grs='git reset --hard && git clean -fd' （grs = git reset safe），并加上醒目警告：“此命令不可逆！执行前请 git status 并 tar -czf backup.tar.gz . ”。真正的高手不是不犯错，而是有可靠的逃生舱。

5. 超越命令：构建属于你的 Git 生产力系统

5.1 配置你的“个人 Git DNA”： .gitconfig 关键项

一个精心配置的 .gitconfig 能节省你每年上百小时。以下是经过 12 个项目验证的核心配置：

[user]
  name = Your Name
  email = your.email@company.com  # 用公司邮箱，确保贡献归属
[core]
  editor = code --wait  # VS Code 作为默认编辑器，--wait 确保 commit 信息输入完成才继续
  autocrlf = input      # Linux/macOS 用户设为 input，Windows 设为 true
  excludesfile = ~/.gitignore_global  # 全局忽略文件
[init]
  defaultBranch = main  # 初始化仓库时默认创建 main 分支
[pull]
  rebase = true         # pull 默认 rebase，保持历史线性
[push]
  default = current     # push 当前分支到同名远程分支
  followTags = true     # 自动推送关联的 tag
[alias]
  # 常用缩写
  co = checkout
  ci = commit
  st = status
  br = branch
  # 高效日志
  lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
  # 安全推送
  p = push --force-with-lease
  # 查看谁改了某行
  bb = blame -w -M -C

提示： git config --global alias.lg 命令可逐条添加。 lg 别名生成的图形化日志，能清晰看到分支分合，比 git log --oneline 信息量大 10 倍。我团队的代码审查规范要求：PR 描述必须包含 git lg -10 的输出截图。

5.2 用 git bisect 在千次提交中 5 分钟定位 Bug 根源

当一个 bug 在 main 分支上突然出现，而你不确定是哪次提交引入的， git bisect 是神技。流程如下：

Step 1：标记已知的“好”和“坏”状态

git bisect start
git bisect bad   # 当前 HEAD 是坏的
git bisect good v1.2.0  # 已知 v1.2.0 版本是好的

Step 2：Git 自动检出中间提交，你测试并标记

# Git 检出一个中间提交，你运行测试
npm test
# 如果测试失败，标记为 bad
git bisect bad
# 如果测试通过，标记为 good
git bisect good

Git 会不断二分，通常 10 次内就能定位到引入 bug 的提交。

Step 3：结束并清理

git bisect reset  # 回到原始分支

实操心得：我曾用 git bisect 在一个有 3200 次提交的仓库中，12 分钟定位到一个内存泄漏 bug——它源于一次看似无害的 lodash 版本升级。关键技巧：把测试自动化， git bisect run npm test 可全自动执行，你只需喝杯咖啡。

5.3 GitHub/GitLab PR 流程中的 Git 实战心法

Pull Request 不是 Git 命令，而是协作协议。高效 PR 的 Git 实践：

• 分支命名即契约 ： feature/user-profile-v2 、 hotfix/login-500-error 、 chore/update-ci-config 。名字要让 reviewer 一眼知道范围和意图；
• 提交粒度即文档 ：每个 git commit 应是一个原子性变更。 git commit -m "feat(profile): add avatar upload" 后，紧接着 git commit -m "test(profile): add avatar upload unit tests" ，而非合并成一个大提交；
• PR 描述即说明书 ：必须包含：
  • What ：解决了什么问题？
  • Why ：为什么用这个方案？（对比了哪些方案？）
  • How ：如何验证？（提供测试步骤、截图、日志）
  • Impact ：影响范围？（是否需要 DB 迁移？是否影响 API？）
  • Related ：关联的 issue、设计文档链接；
• Review 时关注 Git 历史 ：用 git log --oneline origin/main..HEAD 查看本次 PR 引入的所有提交，确保无 WIP 、 fix typo 等低质量提交。我团队的 CI 会自动拒绝包含 WIP 的提交。

注意： git cherry-pick 在跨分支紧急修复时极有用。例如 main 上发现高危漏洞，而修复代码在 dev 分支， git cherry-pick abc123 可把该提交“摘”到 main ，无需合并整个 dev 。但切记： cherry-pick 会产生新哈希，后续 merge dev 时 Git 会智能跳过该提交，避免重复。

5.4 终极防护：用 .gitattributes 解决换行符、二进制文件等隐形坑

.gitattributes 是 Git 的“元数据配置文件”，解决那些 git status 看不见的坑：

# 统一文本文件换行符为 LF（Unix 格式）
* text=auto eol=lf

# 明确标记二进制文件，避免 Git 尝试 diff（导致乱码）
*.png binary
*.jpg binary
*.pdf binary

# 对 JSON 文件启用语法感知 diff
*.json diff=json

# 对 package-lock.json 禁用 diff（内容太长，无意义）
package-lock.json -diff

# 对大型文件启用 Git LFS（需提前安装）
*.psd filter=lfs diff=lfs merge=lfs -text

实操心得： .gitattributes 应在项目初始化时就创建，并随 .gitignore 一起提交。我团队的模板仓库中，它和 README.md 一样是必备文件。 git check-attr -a . 命令可查看当前目录下所有文件的属性设置，是排查诡异行为的利器。

6. 我的 Git 成长时间线：从 rm -rf .git 到写这篇指南

第一次接触 Git 是在 2012 年，当时 git reset --hard 对我而言和 rm -rf .git 没区别——反正都得重 clone。我清楚记得在一家电商公司，为修复一个支付超时 bug，我 git checkout -b fix-timeout ，改完 git add . && git commit -m "fix" ， git push 却被拒绝。慌乱中 git push --force ，结果覆盖了同事刚合并的库存扣减逻辑，导致线上库存数据错乱。那次事故后，我花了整整两周，把 Pro Git 电子书逐行手敲一遍，不是为了背命令，而是理解每个命令背后的“状态机”。后来带团队，我坚持一个原则： 不教命令，只教场景 。新人入职第一天