1. git reflog：你的终极“后悔药” 💊

什么是 git reflog？

git reflog (Reference Log) 是一个记录你本地仓库中 HEAD 和分支指针所有移动历史的命令。简单来说，你在本地执行的每一次 commit、reset、checkout、merge 等操作，都会被 reflog 静静地记录下来。它就像一个飞行记录仪，忠实地记下了你的每一次“变道”和“拐弯”。

它为什么被称为“后悔药”？

因为 Git 的很多“破坏性”操作（如 git reset --hard）看似删除了提交，但 reflog 仍然保留着这些提交的踪迹。只要提交曾经存在于你的本地仓库，reflog 就能帮你找到它。这使得 reflog 成为了你在搞砸仓库时的终极救星。

如何使用？

想象一下，你不小心执行了 git reset --hard HEAD~3，丢掉了最近的 3 个重要提交。你的 git log 里已经看不到它们了，你心急如焚。

救援步骤：

1. 保持冷静，召唤 reflog：

$ git reflog
7fde3ab HEAD@{0}: reset: moving to HEAD~3
a1b2c3d HEAD@{1}: commit: 添加了用户认证功能
d4e5f6g HEAD@{2}: commit: 修复了支付页面的一个bug
h7i8j9k HEAD@{3}: commit: 完成了首页UI重构
...

你会看到一个列表，HEAD@{1}、HEAD@{2}、HEAD@{3} 正是你刚刚“丢失”的三个提交！

1. 找到“灾难”发生前的状态：
   在这个例子中，a1b2c3d (即 HEAD@{1}) 是你执行 reset 前的最新状态。
2. 吃下“后悔药”，恢复仓库：
   使用 git reset 命令，将你的分支指针指回那个正确的提交。

git reset --hard a1b2c3d

或者使用 reflog 的引用：

git reset --hard HEAD@{1}

搞定！ 你丢失的提交又回来了。reflog 只存在于你的本地仓库，不会通过 push 同步到远程，所以它纯粹是你个人的安全网。

---

2. 交互式变基 (git rebase -i)：提交历史的“美容师” ✂️

什么是交互式变基？

git rebase -i (-i 代表 interactive) 是一个强大的工具，它允许你像编辑文本一样，去修改、合并、删除、重排一系列尚未推送到公共分支的提交。

为什么要用它？

在一个功能开发过程中，我们可能会有很多零碎的提交，比如 "fix typo", "WIP", "add console log" 等。这些提交对于最终的功能来说是噪音。在合并到主分支前，使用交互式变-基可以将这些零碎的提交整理成一个或几个逻辑清晰、描述准确的提交，保持主干历史的干净和可读性。

如何使用？

假设你的分支有 3 个需要整理的提交。

1. 启动交互式变基：
   你想整理最近的 3 个提交，可以执行：

git rebase -i HEAD~3

1. 进入编辑模式：
   Git 会打开一个文本编辑器，显示如下内容：

pick h7i8j9k 完成了首页UI重构
pick d4e5f6g 修复了一个小bug
pick a1b2c3d 添加了用户认证功能

# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# ...

1. 执行操作：
   根据你的需求修改这个文件。

• • 合并提交 (squash/fixup)：你想把后两个提交合并到第一个里。

pick   h7i8j9k 完成了首页UI重构
squash d4e5f6g 修复了一个小bug
fixup  a1b2c3d 添加了用户认证功能 # fixup会直接丢弃这个提交的信息

保存退出后，Git 会让你为这个新的、合并后的提交编写一个新的 commit message。

• • 修改提交信息 (reword)：

reword h7i8j9k 完成了首页UI重构
pick   d4e5f6g 修复了一个小bug
pick   a1b2c3d 添加了用户认证功能

保存退出后，Git 会让你重新编辑 h7i8j9k 的提交信息。

• • 调整提交顺序：
    直接在编辑器里调整行的顺序即可。

pick a1b2c3d 添加了用户认证功能
pick h7i8j9k 完成了首页UI重构
pick d4e5f6g 修复了一个小bug

黄金法则：永远不要对已经推送到公共分支（如 main 或 develop）的提交进行 rebase 操作！ 因为它会重写历史，导致协作者的仓库陷入混乱。请只在你的私有特性分支上使用。

---

3. git cherry-pick：精准“采摘”提交 🍒

什么是 git cherry-pick？

cherry-pick 允许你选择任意一个分支上的某一个或几个提交，然后将它们作为新的提交应用到你当前所在的分支上。

我该在什么场景下使用它？

1. 紧急修复 (Hotfix)：develop 分支上一个紧急的 bug 修复提交，需要立即应用到 main 分支上，但 develop 分支的其他功能还不能发布。
2. 功能移植：你正在开发 feature-A 分支，其中一个提交实现了一个通用工具函数，现在 feature-B 分支也需要这个函数，但你不想合并整个 feature-A。
3. 提交错分支：你不小心在 main 分支上做了一个本该属于 feature-X 的提交。

如何使用？

假设 develop 分支有一个 commit e4a9a2c 修复了一个重要 bug，你想把它应用到 main 分支。

# 1. 切换到目标分支
git checkout main

# 2. 执行 cherry-pick，传入你想“采摘”的 commit 哈希值
git cherry-pick e4a9a2c

Git 会在 main 分支上创建一个新的提交，其内容与 e4a9a2c 完全相同，但会有一个新的 commit 哈希值。

---

4. git blame & git bisect：问题排查双雄 🔍

git blame：代码“追责”与上下文溯源

git blame 的作用是逐行显示一个文件的内容，并标注每一行代码最后是由谁、在哪次提交中修改的。

• 用途：它的目的不是为了“指责”某人，而是为了快速找到能提供最多信息的人。当你看到一行难以理解的代码时，git blame 能帮你迅速定位到当初修改它的开发者，以便你向他请教设计意图。
• 用法：

git blame path/to/your/file.js

输出会是这样：

^a1b2c3d (John Doe  2023-01-15 10:30:00 +0800 1) const a = 1;
d4e5f6g  (Jane Smith 2023-03-20 14:00:00 +0800 2) if (a > 0) {
...

git bisect：二分查找定位 Bug

当你的项目出现了一个 Bug，但你只知道在某个旧版本（比如 v1.0）是好的，而当前版本 (HEAD) 是坏的，中间有上百个提交，如何快速找到引入 Bug 的那个提交？git bisect 就是为此而生的。

• 原理：它使用二分查找法，自动在“好”与“坏”的提交之间切换，每次都让你测试当前版本，然后你告诉它是 good 还是 bad。这个过程会不断缩小范围，直到精确定位到第一个引入问题的提交。
• 用法：

# 1. 开始二分查找
git bisect start

# 2. 标记当前版本是坏的
git bisect bad

# 3. 标记一个已知的、没有问题的旧版本是好的
git bisect good v1.0

# 4. Git 会自动切换到中间的一个提交，然后你进行测试...
#    测试后，如果这个版本是好的，就输入：
git bisect good
#    如果还是坏的，就输入：
git bisect bad

# 5. 重复第4步，直到 Git 告诉你 "xxxx is the first bad commit"

# 6. 结束查找，返回到你之前的分支
git bisect reset

---

5. Git LFS：在 Git 中优雅地管理大文件 🏗️

Git 的核心设计不适合处理大型二进制文件（如设计稿、视频、数据集、编译好的库）。每次修改，Git 都会存储一个完整的副本，导致仓库体积急剧膨胀，clone 和 pull 变得异常缓慢。

Git LFS (Large File Storage) 是一个 Git 扩展，它将大文件本身存储在远程服务器（如 GitHub LFS）上，而在你的 Git 仓库中只保留一个轻量级的“指针”文件。

• 工作流程：

1. 1. 安装 LFS: git lfs install (只需在你的机器上执行一次)。
   2. 追踪文件类型: 在你的仓库中，告诉 LFS 需要管理哪些类型的文件。

git lfs track "*.psd"   # 追踪所有 .psd 文件
git lfs track "assets/videos/*.mp4" # 追踪特定目录下的视频

1. 1. 提交 .gitattributes 文件: 上一步会生成或修改 .gitattributes 文件，务必将它提交到仓库中。

git add .gitattributes

1. 1. 正常使用 Git: 之后你就可以像平常一样 git add, commit, push 那些大文件了。LFS 会在后台自动将大文件上传到 LFS 服务器，而 Git 只提交指针。

---

6. Git Hooks：你的自动化流程机器人 🎣

什么是 Git Hooks？

Git Hooks 是在 Git 执行特定事件（如 commit、push、receive）时自动触发的自定义脚本。它们存放在每个仓库的 .git/hooks 目录下。

如何使用它来做自动化操作？

你可以利用 Hooks 来强制执行团队规范、运行自动化测试、检查代码格式等。

• 最常见的例子：pre-commit 钩子
  这个钩子在 Git 生成提交对象之前运行。你可以用它来：

• • 检查代码格式：运行 prettier 或 eslint --fix，确保提交的代码符合规范。
  • 运行单元测试：确保你的提交没有破坏任何现有功能。
  • 检查敏感信息：防止意外提交 API 密钥等。

• 如何创建一个 pre-commit 钩子？

1. 1. 进入 .git/hooks 目录。
   2. 创建一个名为 pre-commit 的文件 (去掉 .sample 后缀)。
   3. 赋予它可执行权限：chmod +x pre-commit。
   4. 在文件中写入你的脚本（例如，一个 shell 脚本）：

#!/bin/sh
echo "Running pre-commit hook: Checking code style..."

# 运行 linter，--quiet 参数让它只在有错误时输出
npm run lint -- --quiet

# $? 是上一个命令的退出状态码。如果非0，说明 linter 失败。
if [ $? -ne 0 ]; then
 echo "Linter failed. Aborting commit."
 exit 1 # 退出状态码为1，会阻止本次提交
fi

echo "Code style is clean. Proceeding with commit."
exit 0

为了方便团队统一管理 Hooks，通常会使用 husky 或 pre-commit 这类工具，它们能将 Hooks 的配置写在 package.json 或配置文件中，让团队成员 npm install 后自动启用。

---

总结

掌握了这些高级技巧，你手中的 Git 就不再只是一个版本控制工具，而是一把能够精雕细琢代码历史、高效排查问题、实现流程自动化的瑞士军刀。记住，强大的工具需要谨慎使用，尤其是像 rebase 这样会改写历史的命令。在实践中不断探索，你将能更加自信和从容地驾驭任何复杂的 Git 工作流。