打个比方，Git 现在早就不是那个只会 add 和 commit 的小工具了。就在 2024 年 5 月，Git 官方发布了 2.45.0 版本，这版本在性能和大型仓库管理上又往前迈了一大步。咱们做全栈的，平时不仅要写业务，还得维护构建脚本、处理 CI/CD，如果不把这几个核心特性玩明白，遇到代码丢了或者历史乱了的情况，真就只能抓瞎。
很多新手喜欢无脑提交，导致 Git 历史里全是 "fix bug"、"test" 这种垃圾信息。在团队协作里，这简直是灾难。交互式 Rebase (git rebase -i) 就是用来整理这些烂摊子的。
假设你在本地开发新功能，提交了三次，但其中两次其实可以合并，还有一次写错了描述。
执行后，Git 会弹出一个编辑器，内容大概长这样：
注意：这时候你可以把 pick 改成 squash (或者简写 s) 来合并提交，或者改成 reword (或者 r) 来修改提交信息。比如你想把后两个合并到第一个里，就改成：
保存退出后，Git 就会把这三个提交合并成一个，历史瞬间清爽。这在你准备提 MR (Merge Request) 给老大看的时候，绝对能加分。
这绝对是全栈工程师必须掌握的"救命技能"。打个比方，git reflog 就是记录你的 HEAD 指针每一次变动的日志。哪怕你用了 git reset --hard 把代码搞没了，只要本地仓库没删，Reflog 里就有记录。
我之前就踩过坑，有一次脑子抽了，想回退代码，直接 git reset --hard HEAD~5，结果把同事刚合并的提交给干掉了。当时冷汗都下来了，后来就是靠 Reflog 找回来的。
输出可能长这样：
看到没？def5678 就是那个被我误删的提交。找回它只需要一行命令：
现在的趋势是 Mono-Repo 越来越多，一个仓库几个 G 那是常事。如果你还在用老方法 git clone，那网速慢点能下一天。Git 2.45.0 对部分克隆（Partial Clone）的支持已经非常成熟了。
其实，部分克隆就是先只把提交历史拉下来，文件内容等你真正用到的时候再去服务器拉。这对于前端全栈项目，尤其是包含大量 node_modules 缓存或者历史构建产物的仓库，简直是神技。
📖 学习建议：如果你公司的项目特别大，或者你只是想看看某个老项目的代码逻辑，不需要编译运行，强烈建议开启部分克隆。这能省下你喝好几杯咖啡的时间。
---
聊完工具，咱们得聊聊"规矩"。代码是写给人看的，协作流程也是。以前大家都在用 Git Flow，觉得那是正统，但现在 Trunk-Based Development (主干开发) 的声音越来越大，尤其是配合 CI/CD 的时候，那效率简直飞起。
传统的 Git Flow 有个 develop 分支，有个 master 分支，还有各种 feature、release、hotfix 分支。听起来很严谨对吧？但在实际开发中，特别是全栈项目，经常会出现 feature/login 开发了两周，最后合并的时候跟 develop 产生几百个冲突，解冲突解到想吐。
不过，Git Flow 也不是一无是处。对于那种发布周期固定、版本号管理严格的项目（比如客户端软件），它依然很稳。
现在社区里（特别是 2024 年的技术趋势）更推崇主干开发。可以这么理解，就是大家都在 main 或者 master 这条主干上玩。你拉个短分支（比如只活几个小时），写完代码立马提 PR 合进去。
这种模式极度依赖 分支保护规则 和 自动化测试。如果你没有完善的单元测试和 E2E 测试，主干分分钟被你玩崩。
除了公司内部的协作，如果你要参与开源项目，那 Forking Workflow 是绕不过去的。这其实是一种特殊的分布式工作流。
🔧 实战技巧：不管用哪种流，一定要在仓库里配置好 .gitignore 和 Commit Message 规范。现在社区都在推 Conventional Commits，比如 feat:, fix:, chore:，这不仅能让历史清晰，还能配合工具自动生成 ChangeLog。别再写 "update code" 这种提交了，老大看了会想打人的。
---
作为全栈工程师，你肯定遇到过这种场景：正在 dev 分支写新功能写到一半，突然线上（Production）炸了，必须马上切过去修。或者，你在 A 分支写的一个 Bug 修复，B 分支也需要，但不想把整个 A 分支都合过去。这时候，那些基础命令就不够用了。
git cherry-pick 简直是神器。可以这么理解，它就是把这个分支的某个提交，"复制"一份应用到当前分支。
比如你在 feature-A 分支修了一个通用的 Bug，提交哈希是 a1b2c3d。这时候 feature-B 也有这个 Bug，你不想把 feature-A 还没写完的代码全合过去，那就用 Cherry-pick。
如果没冲突，这就完事了。如果有冲突，解决完记得：
这个太常用了。你正在 feature 分支改得热火朝天，突然老板说线上有个紧急问题要处理。你现在的代码还没写完，不能提交，咋办？
核心要点：git stash 默认只保存被 Git 追踪的文件（tracked files）。如果你新建了一个文件还没 add 过，它是不会帮你保存的。这时候得加个 -u 参数：git stash push -u -m "包含新文件"。
这绝对是高级用法。假设你发现现在的代码有个 Bug，但你知道上周还是好的。这一周可能有几十个提交，你总不能一个个 reset 回去试吧？git bisect 就是干这个的。
它会通过二分法，让你在"好"和"坏"的提交之间快速定位到第一个引入 Bug 的提交。
Git 会自动帮你跳到中间的那个提交。这时候你运行一下测试或者启动项目看看有没有 Bug。
git bisect badgit bisect good重复几次后，Git 会告诉你：a1b2c3d is the first bad commit。这时候你就知道是谁搞的鬼了。
💡 经验总结：bisect 配合自动化测试脚本简直无敌。你可以写一个脚本，让 Git 自动跑测试来判断好坏，完全不用人工干预：
git bisect run npm test。这在排查那些隐藏很深的回归测试 Bug 时，能省下大把摸鱼时间。
---
现在的全栈项目越来越复杂，可能前端、后端、CI 脚本、文档都在一个仓库里，这就是 Mono-Repo。或者，你的项目依赖了另一个独立的 Git 仓库。这时候，普通的 clone 和 pull 就不太够用了，得用点高级架构手段。
简单来说，git submodule 就是在一个 Git 仓库里嵌套另一个 Git 仓库。这在你引用第三方库，或者把公共组件单独抽离成仓库时很有用。
比如你的主项目依赖一个自己写的 UI 组件库：
实际案例提醒：Submodule 这东西挺容易让人迷糊的。你在主项目里改了子模块的文件，如果不进到子模块目录去提交，主项目只会记录一个子模块的版本号变更。千万别在子模块里随便 git reset --hard，很容易导致主项目引用的指针乱掉。
在 Mono-Repo 里，一个仓库可能有 frontend、backend、infra 三个大目录。你是个前端，只想改前端代码，不想把后端那几个 G 的依赖和代码都拉下来占硬盘，怎么办？用 Sparse Checkout。
Git 2.45.0 对这部分功能优化得很好，用起来很顺手。
这时候你 ls 一下，发现只有 frontend 文件夹和 README.md，世界瞬间清净了。
现在社区里关于 Mono-Repo 的讨论热度很高，像 Turborepo、Nx 这些工具，都是为了解决 Mono-Repo 里的构建缓存和任务编排问题。
虽然 Git 本身不直接提供构建优化，但配合这些工具，体验会很好。特别是 Rust 实现的 Git (gitoxide) 也在发展中，未来可能会让大仓库的操作速度有质的飞跃。
📖 学习建议：如果你的团队规模不大，千万别盲目上 Mono-Repo。Submodule 和 Mono-Repo 带来的维护成本很高，尤其是权限管理和 CI 配置。只有当你真的需要跨项目共享代码，且这些代码耦合度极高时，才考虑这种架构。不然，还是老老实实拆成多个微服务仓库，用包管理器（npm/pip/maven）来关联依赖，省心多了。
说到团队协作，尤其是那种几十号人甚至上百号人的大厂项目，光会敲代码是不够的，你还得保证代码库是安全的，而且流程是自动化的。其实，你不能指望每个人都能自觉地把代码写得漂漂亮亮的，也不能保证每个提交都是本人操作的。这一节咱们就来聊聊怎么给 Git 加上“防盗门”和“自动化流水线”。
你有没有想过，如果有人冒充你的邮箱往仓库里提交了代码怎么办？在 Git 里，默认只检查邮箱，这太容易伪造了。这时候就需要 GPG (GNU Privacy Guard) 签名了。
现在安全是头等大事，特别是 2024 年以后，大家对软件供应链安全的重视程度到了新高度。很多大厂和开源社区（比如 Linux Kernel）都强制要求提交必须签名。Git 2.45.0 对签名相关的支持也更完善了。
值得留意的是，签名是为了证明这个提交确实是你本人推送的，而不是哪个黑客黑了你的账号乱搞的。
怎么搞？首先你得生成一把 GPG 钥匙：
生成完了，你得告诉 Git 用哪个钥匙。先列出你的钥匙：
你会看到类似 sec rsa4096/3AA5C34371567BD2 2024-01-01 [SC] 这样的输出，那个 3AA5C34371567BD2 就是你的 Key ID。
然后配置到 Git 里：
以后你再 git commit，就会自动用你的私钥签名了。别人拉代码的时候，可以用你的公钥验证这个提交确实是你发的。
📌 要点提醒：如果你用的是 GitHub 或者 GitLab，记得去 Settings 里把你的 GPG 公钥上传上去。这样平台就会显示那个漂亮的 Verified 绿标，看起来专业多了。
Hooks 这玩意儿简直是懒人福音。它能在特定的 Git 事件（比如 commit, push）发生前后，自动执行你写的脚本。
举个例子，你是不是受够了队友提交那种 fix bug 或者 asdf 这种垃圾 Commit Message？咱们可以用 commit-msg Hook 来强制规范。
在你的项目根目录下，进入 .git/hooks 文件夹。你会看到一堆 .sample 文件。咱们新建一个叫 commit-msg 的文件（没有后缀），内容如下：
然后记得给它加执行权限：chmod +x .git/hooks/commit-msg。
这时候你再试试提交一个 git commit -m "随便写写"，Git 直接给你报错，根本提交不上去。这比人工 Code Review 严多了。
🔧 实战技巧：虽然本地 Hook 很好用，但 .git/hooks 目录默认是不被推送到远程仓库的。如果你想团队统一规范，建议使用 husky 这种工具（前端项目常用）或者把 Hook 脚本放在项目根目录，通过 Makefile 或者安装脚本统一初始化。
咱们再聊聊时髦的。2024 年到 2026 年，最大的趋势就是 AI 辅助代码审查。
以前咱们 git diff 完了，还得自己盯着看哪里写错了。现在不一样了，很多 Git 托管平台（像 GitLab、GitHub 以及新兴的 Forgejo）都开始集成 AI 能力。
比如，你可以写一个 Hook 或者在 CI/CD 流水线里，调用 AI 的 API 来分析你的 Diff。
虽然咱们自己写个完整的 AI 审查很难，但思路是这样的：
简单来说，这就是把你的代码改动丢给大模型，让它帮你看看有没有逻辑漏洞、有没有明显的空指针异常，甚至帮你生成 Commit Message。
⚡ 效率提示：如果你不想自己搭，可以试试 GitHub 的 Copilot Chat 或者一些 IDE 插件，它们现在都能直接读取你的 Git Diff 并给出建议。这在处理大型 Mono-Repo 时特别有用，能帮你快速定位问题。
---
面试的时候，Git 绝对是必考题。很多新手一听到 git reset 就哆嗦，分不清 --hard 和 --soft，或者搞不懂 merge 和 rebase 到底该用哪个。作为一个实战经验无数的老司机，今天咱们就掰开了揉碎了讲讲这些高频题。
面试官问你：git reset --hard, --soft, --mixed 有啥区别？
换个角度看，这三个命令都是用来“回退”版本的，区别在于回退后，你之前的代码改动去哪了。
咱们假设现在有三个提交：A -> B -> C。你当前在 C。
--soft (软回退)：- 它只动 HEAD 指针，不动暂存区（Staging Area），也不动工作区。
- 效果：你从 C 回到了 B，但是 C 的改动都还在暂存区里（就像已经 git add 了）。
- 场景：你刚提交完 C，突然发现 Commit Message 写错了，或者漏了几个文件。这时候用 git reset --soft HEAD~1，把提交撤销，改动还在暂存区，改改再提交就行。
--mixed (默认模式)：- 它动 HEAD 指针，也动暂存区，但是不动工作区。
- 效果：你回到了 B，C 的改动还在你的文件夹里，但是没被 git add（变成了未追踪状态）。
- 场景：你提交完了，觉得这代码写得一团糟，想重新来过，但还没烂到要删掉重写的地步。
--hard (硬回退)：- 这是核弹级别的。它动 HEAD，动暂存区，也动工作区。
- 效果：直接回到 B，C 的所有改动瞬间消失，仿佛从未存在过。
- 场景：代码写崩了，完全不想保留，想彻底回到某个干净的状态。
来看个代码演示，演示一下怎么用 --hard 以及怎么救回来（Reflog 的威力）：
📌 要点提醒：没事别乱用 git reset --hard，除非你确定那些改动是垃圾。如果不确定，用 git revert 更安全，因为它不会修改历史，而是新增一个“反向提交”。
这是面试必问的，也是团队协作里最容易吵架的地方。
git merge (合并)：- 原理：把两个分支的最新快照和它们共同祖先做一个三方合并，产生一个新的 Merge Commit。
- 结果：历史记录是非线性的，像一棵树一样，有很多分叉。
- 优点：安全。它不改变现有的提交历史，只是新增。
- 缺点：如果你一天 merge 十几次，Git 历史图就像一坨意大利面，根本看不懂。
git rebase (变基)：- 原理：把当前分支的提交“挪”到目标分支的最新提交后面。
- 结果：历史记录是线性的，看起来特别清爽。
- 优点：历史干净，没有多余的 Merge Commit。
- 缺点：危险！它改写了历史。如果你在公共分支（比如 main）上 rebase，别人拉代码就会出大问题。
咱们实操一下，看看区别：
🔧 实战技巧：记住一句话——不要对已经推送到远程的公共分支做 Rebase。只在你自己的本地功能分支上用 Rebase 整理历史。如果你要把 feature 合进 main，推荐先在 main 上 git pull --rebase 保持本地最新，然后再 Merge 或者 Rebase 你的 feature 分支。
2024 年的趋势里，大家也越来越讨论 Trunk-Based Development（主干开发），这种模式下大家几乎都是 rebase 然后直接合入主干，不再用复杂的 Git Flow，这对 Rebase 的操作要求更高，但也更高效。
---
写了这么多，咱们其实一直在围绕一个核心目标转：怎么让一群人既能愉快地写代码，又不会把仓库搞成一团浆糊。作为一个写了 5 年代码、踩过无数 Git 坑的工程师，我想最后啰嗦几句，帮大家把这些碎片化的知识点串成一个完整的体系。
可以这么理解，Git 只是个工具，怎么用取决于团队规范。以前大家都迷信 Git Flow，搞什么 develop, release 分支，复杂的要死。现在 2024 年了，风向变了。
现在的趋势是 Trunk-Based Development 或者简化版的 Feature Branch Workflow。大家都在自己的分支上开发，频繁地往 main 或者 master 里合。为了让历史看起来清爽，我强烈建议大家养成 Rebase 的习惯。
配合 Conventional Commits（约定式提交）规范，你的提交信息应该是 feat:, fix:, chore: 这种格式。这不仅仅是为了好看，更是为了自动化。你可以配合 git hooks 或者 CI 工具，自动根据 Commit Message 生成 Changelog，甚至自动发布版本号。
现在的软件供应链攻击太猖獗了。如果你还在裸奔提交代码，真的要小心了。
咱们不能只盯着命令行那几行字。
git reflog 是你最好的朋友。当你面对一个不知道谁引入的 Bug 时，别一个个 Commit 去翻，用 git bisect。这两个命令能拯救你的职业生涯。gitoxide 的项目很火，它是用 Rust 重写的 Git。虽然现在还没完全替代官方 Git，但它展示了未来的方向——更快、更安全。如果你维护的是像 Linux 内核或者超大型 Mono-Repo，这种性能提升是巨大的。构建一个现代化的协作体系，不需要一步到位。你可以从这几步开始：
pre-commit Hook，跑一下代码格式化（比如 prettier 或 gofmt），保证提交上去的代码风格一致。wip (work in progress) 了，用 git stash 暂存你的工作，那是专业的做法。Git 是个神器，但也挺反人类。多练多经验之谈，你会发现其实也就那么回事儿。祝你代码永远没冲突，Commit 永远能 Push 上去！