作者：CodeCrafter
Git 在现代软件工程里，扮演的角色已经远远超出了一个“代码备份工具”。它是一种规范、一种纪律，是团队协作的底层协议，也是项目质量和稳定性的第一道防线。
你两小时学会的，是 add, commit, push, pull。这相当于学会了开车时的“油门、刹车、方向盘”。你确实能把车开上路。
但那些冗长的教程在教什么？
- 交通规则：公司的分支模型是什么？
master/main分支受保护，不能直接push，必须提Pull Request（或者叫Merge Request）。feature 分支命名规范是feature/JIRA-123-user-login。 - 复杂路况处理：代码写一半，线上出了个紧急 bug 怎么处理？（
git stash）两个同事改了同一个文件的同一行，提交的时候冲突了怎么办？（merge conflict） - 事故处理与追责：上个版本发布后，发现有个隐藏很深的 bug，是从哪个提交引入的？（
git bisect）手一抖，把刚写好的一天代码给reset --hard弄丢了，怎么找回来？（git reflog） - 驾驶技巧与美学：你提交的
commit记录，是一条清晰的“开发用户登录功能”、“修复密码加密bug”，还是一堆无意义的“update”、“fix”、“111”？前者能让同事和半年后的你自己快速定位问题，后者就是一坨屎山。怎么把一串凌乱的提交记录整理成一条干净的线？（git rebase -i） - 团队配合：你的功能分支远远落后于主分支，是直接
merge主干，形成一个难看的“气球”合并，还是rebase到主干最新，保持一条线性的提交历史？这背后是merge和rebase两种哲学的博弈，也是很多公司面试会问到的问题。
你看，这些东西，跟“用 Git 保存代码”这个核心功能已经偏离了，但它们全都是企业级项目开发的日常。你一个人写代码，岁月静好。一旦进入一个 5 人、10 人甚至上百人的团队，你每一次不规范的 push，都可能给别人带来大麻烦，甚至搞挂整个项目。
那些三五十集的教程，就是在掰开了、揉碎了，把这些血淋淋的场景教给你。它们不是在教你怎么用锤子，是在教你怎么成为一个合格的、专业的、让人放心的建筑工人。
当然，我完全同意你的观点，很多教程太学院派了，上来就讲底层 blob、tree、commit 对象，讲 SHA-1 哈希，把人直接劝退。这就像教开车，非要从内燃机的四冲程原理讲起，没必要。
所以，我今天不讲原理，不搞那些花里胡哨的，就按你说的，搞一套“邪修速成大法”。不求你成为 Git 布道师，只求你在公司里游刃有余，不坑队友，还能在关键时刻秀一把操作，解决别人解决不了的问题。
作者：CodeCrafter
Git 邪修速成心法：场景驱动实战 #
忘掉那些孤立的命令，我们只看场景。遇到什么问题，用什么招式。
第一重：闭关自修（单人模式） #
这是你的“两小时速成”阶段，也是一切的基础。
- 场景：你自己开了个项目，或者在本地练习。
- 心法：稳扎稳打，步步为营。
这个阶段的核心就是四个命令：
git add .：把你当前目录所有改动（新增、修改、删除）都放进一个叫“暂存区”的篮子里。这个“.”代表所有文件，你也可以指定具体文件，比如git add README.md。git commit -m "你的提交信息"：给篮子里的东西拍个快照，贴上标签。-m后面的信息至关重要，是你给未来自己留下的路标。请务必写清楚这次提交干了什么，比如“feat: 完成用户注册接口”或“fix: 修复短信验证码发送失败问题”。别写“update”或者“123”，不然你就是在给自己埋雷。git push：把你的快照记录推送到远程仓库（比如 GitHub、GitLab）。git pull：从远程仓库拉取最新的记录，跟本地同步。
这个阶段，你只需要保证一件事：小步提交。一个功能点、一个 bug 修复，做完了，测试通过了，立刻 add + commit。不要攒一周的代码再一次性提交。小步提交能让你的“后悔药”更精确。
第二重：初入江湖（团队协作基础） #
你入职了新公司，开始参与团队项目。
- 场景：从零开始加入一个项目，或者开发一个新功能。
- 心法：先拉后推，另起炉灶。
- 克隆项目：
git clone [仓库地址]这没啥好说的，把你司的项目代码从远程服务器完整地复制一份到你本地。 - 创建自己的分支：
git checkout -b feature/user-profile这是团队协作的铁律！永远不要，永远不要，永远不要在 main（或 master、develop）主分支上直接写代码！ 你的所有工作，都应该在一个专门为你这个功能或 bug 修复创建的分支上进行。checkout -b是一个组合命令，意思是创建一个名为feature/user-profile的分支，并立刻切换过去。分支名最好带上前缀，比如feature/、fix/、hotfix/，后面跟上具体内容，清晰明了。 - 在自己的分支上愉快地玩耍：
在这个叫
feature/user-profile的分支上，你可以随便用第一重的add、commit。你的所有操作都跟主分支无关，跟你的同事无关，你在自己的小世界里是绝对安全的。 - 推送你的分支：
git push origin feature/user-profile当你这个分支的功能做得差不多了，想让同事看到，或者想在远程仓库备份一下，就用这个命令把它推上去。origin是你远程仓库的默认名字。第一次推送一个新分支，Git 可能会提示你用一个更完整的命令，按它说的复制粘贴就行。 - 同步主干的最新进展：
在你开发功能的时候，你的同事们也在
main分支上合并了他们的新代码。为了避免你的代码和大家脱节太久，你需要经常把main分支的最新内容同步到你的功能分支上。 这里，第一个分水岭出现了：用merge还是rebase？
- 新手/简单粗暴版：
git merge main先git checkout main，然后git pull保证你的本地main是最新的。再git checkout feature/user-profile切回你的分支，最后执行git merge main。 这个操作会把main分支的新提交和你分支的提交合并在一起，并生成一个新的“合并提交”。优点是简单直接，完全保留了历史记录。缺点是如果合并频繁，你的提交历史会变得非常乱，充满了各种“Merge branch ‘main’ into …”的提交，像一张蜘蛛网。 - 进阶/推荐使用版：
git rebase main同样，先保证本地main是最新的。然后切到你的功能分支，执行git rebase main。rebase（变基）这个词很唬人，但你可以这么理解：它会暂时把你在这个分支上的所有commit“拔”出来，存到一边；然后，把你的分支“根部”移动到main分支的最新点；最后，再把你刚才那些commit一个一个地“重新”应用上去。 最终效果是，你的分支看起来就像是“基于最新的 main 分支开发出来的”，提交历史是一条干净的直线，没有丑陋的合并记录。 这是目前绝大多数追求代码质量的团队强制要求的操作。
注意：rebase 过程中也可能出现冲突（conflict），需要你手动解决。解决完冲突后，用 git add . 标记为已解决，然后执行 git rebase --continue 继续变基过程。如果搞砸了，可以用 git rebase --abort 放弃这次变基，回到初始状态。
血泪教训：永远不要对一个已经推送到远程，并且别人也在用的公共分支（比如 main）进行 rebase 操作！ 因为 rebase 会改写提交历史，你把它 force push 上去之后，所有基于旧历史的同事都会在 pull 的时候遇到毁灭性的打击。rebase 一般只在自己的私人分支上用。
第三重：亡羊补牢（后悔药大全） #
写代码没有不犯错的。关键是犯了错，得知道怎么优雅地弥补。
- 场景：代码提交后，发现各种问题。
- 心法：胆大心细，善用时光机。
1、卧槽，commit 信息写错了！/ 刚提交完发现漏了个文件！
招式：git commit --amend
这个命令可以“修正”你上一次的提交。
如果只是改信息，它会弹出一个编辑器让你重新编辑 commit message。
如果漏了文件，先 git add [漏掉的文件]，然后再执行 git commit --amend，它会把新加的文件和上次提交的内容合并成一个全新的 commit，替换掉旧的那个。
注意：这个操作也改写了历史，如果你的旧 commit 已经 push 了，那么修正后需要 git push --force 强制推送。请确保这个分支只有你一个人在用。
2、这几个 commit 太零碎了，我想把它们合并成一个。
招式：git rebase -i [基准commit]
-i 代表 interactive（交互式）。这是 rebase 的大杀器。
比如，你的分支上有 5 个提交，你想把后面 3 个合并起来。你可以找到这 3 个提交之前的那个 commit 的哈希值（或者用 HEAD~3 表示倒数第三个），然后执行 git rebase -i HEAD~3。
Git 会弹出一个编辑器，列出这 3 个 commit：
pick f7f3f6d feat: add user avatar upload
pick 310154e fix: fix avatar resize issue
pick a5f4a0d refactor: optimize image compression
你想把这三个合并成一个，就把后面两个的 pick 改成 squash 或者 s：
pick f7f3f6d feat: add user avatar upload
s 310154e fix: fix avatar resize issue
s a5f4a0d refactor: optimize image compression
保存退出后，Git 会让你重新编辑一个新的 commit message，把这三次的修改合并成一次提交。这招在给团队 Pull Request 之前，用来整理自己的提交历史，显得你非常专业。
3、完了，这个功能做错了，想撤销最近的 3 次提交。
招式：git reset --hard [目标commit]
reset 是真正的时光机，但也极其危险。它有三种模式：
--soft：仅仅移动HEAD指针，你的代码和暂存区都还在。相当于“我反悔了这次提交，但代码我还要，想重新commit”。--mixed（默认）：移动HEAD指针，并清空暂存区。你的代码还在工作目录里，但需要重新add。--hard：移动HEAD指针，清空暂存区，并且把你的工作目录也恢复到目标状态。这意味着，你这 3 次提交所做的所有代码改动，全部丢失！
所以，git reset –hard 是终极武器，用之前请三思。通常只在本地分支，且确定这些代码就是垃圾时才用。
4、啊！我刚才 reset –hard 把不该删的代码给删了！人生无望了！
招式：git reflog
这是 Git 给你留的最后一道保险。reflog（引用日志）记录了你本地仓库 HEAD 指针的每一次移动。
你执行 git reflog，会看到一个列表，类似：
a5f4a0d HEAD@{0}: reset: moving to HEAD~3
c489da7 HEAD@{1}: commit: refactor: optimize image compression
...
这里记录了你刚才那次该死的 reset 操作。c489da7 就是你 reset 之前的那个 commit。你只需要执行 git reset --hard c489da7，恭喜你，代码又回来了！
reflog 是纯本地的，不会被 push。它就像飞机的黑匣子，记录了你所有的危险操作，是你本地仓库的守护神。
5、一个已经 push 到 main 分支的提交，发现有 bug，需要撤销。
招式：git revert [问题commit]
前面说了，公共分支不能 reset，不能 rebase。那怎么撤销呢？用 revert。
revert 不会删除历史，而是会创建一个新的 commit，这个新 commit 的内容，刚好是把那个问题 commit 的修改给反向抵消掉。
比如，问题 commit 是增加了一行代码，那么 revert 就会生成一个删掉这行代码的新 commit。
这样做的好处是，历史记录是向前走的，没有被篡改，对于所有协作者来说都是安全的。这是在公共分支上纠错的唯一正确姿势。
第四重：神乎其技（高阶操作） #
掌握了这些，你已经超越了 90% 的开发者。
1、代码写一半，老板突然让我去改个紧急 bug！
场景：你在 feature-A 分支上改了 5 个文件，但还没到可以 commit 的程度。这时线上 main 分支出了个 bug，需要你立刻修复。
招式：git stash
stash 就像一个临时储物柜。
git stash：把你当前工作目录和暂存区里所有未提交的修改，全部打包存起来。你的工作区会瞬间变得干干净净，就像刚clone下来一样。- 然后你就可以放心大胆地
git checkout main，git pull，git checkout -b hotfix/bug-123，去改 bug。 - 改完 bug，合并到
main，发布上线… 一系列操作搞定后。 - 你回到自己原来的分支
git checkout feature-A。 git stash pop：把你之前存起来的修改再原封不动地取出来。你又可以继续之前未完成的工作了。
2、隔壁分支有个 commit 写得特别好，我想把它“偷”到我这个分支来。
场景：同事在 feature-B 分支上写了一个牛逼的工具函数，你也需要用，但你又不想把整个 feature-B 分支都 merge 过来。
招式：git cherry-pick [目标commit的哈希值]
cherry-pick（摘樱桃）就是让你精准地从别的分支上，把某一个或某几个 commit“复制”到你当前的分支上。
这在修复线上 bug 时特别有用。你可能在 hotfix 分支上修复了 bug，然后需要把这个修复 commit 同步到 develop 分支和下一个版本的 release 分支，用 cherry-pick 就非常干净利落。
3、线上出了 bug，但我不知道是哪个 commit 引入的！
场景：一周前发了个版本，今天才收到用户反馈，某个功能坏了。这一周里 main 分支有上百个 commit，怎么快速定位元凶？
招式：git bisect
bisect（二分查找）是 Git 里的破案神器。
git bisect start：开始破案。git bisect bad：告诉 Git，当前这个commit是有问题的。git bisect good [某个没问题的commit]：告诉 Git，比如上个版本的tagv1.2.0 是没问题的。 接下来，Git 会自动帮你 checkout 到这一好一坏两个commit中间的那个commit。然后你就在这个版本上测试，如果还是有问题，就输入git bisect bad；如果没问题，就输入git bisect good。 Git 会不断地在剩余的commit范围里进行二分查找，每次都跳到中间位置让你测试。通常，对于 100 个commit，你只需要测试 7 次左右（log₂100 ≈ 6.64），就能精准定位到引入 bug 的第一个commit。 找到之后，git bisect reset结束破案，回到原来的分支。 这比你一个一个commit去checkout测试，效率高了不知道多少倍。能熟练使用bisect的人，在团队里绝对是“大神”级别的存在。
回到最初的问题：Git 教程为什么那么繁杂？
因为从“能用”到“会用”，再到“精通”，中间隔着的是无数个真实的、复杂的、甚至会让你半夜惊醒的工程场景。你一个人玩，add commit push 足矣。但只要你身处团队，你对 Git 的理解深度，就直接决定了你的协作效率和工程素养。
那些教程不是让你一口气看完的，它们是字典，是手册。你今天没遇到冲突，merge conflict 那一章对你就是天书。等你哪天真的遇到了，抓耳挠腮半小时也搞不定的时候，你再回头去看，就会觉得字字珠玑。
我的这套“邪修心法”，核心思想就是问题驱动。别去背命令，去理解场景。把这些场景刻在脑子里，下次遇到类似情况，你自然就知道该用什么招式。
最后，推荐几个我认为无法替代的优质资源：
- Learn Git Branching：这是一个交互式的 Git 学习网站（搜
learngitbranching.js.org）。它把 Git 的分支、rebase、cherry-pick等操作全部可视化了，你敲的每一个命令，都能立刻看到图形化的变化。对于理解rebase这种抽象操作，有奇效。这是我推荐给所有新人的第一站，比看任何视频都管用。 - Pro Git：这本书是 Git 的官方圣经，免费在线阅读。当你对某个命令的细节、某个参数的作用有疑问时，去查它。它不适合从头读到尾，但适合当做一本权威词典来用。
- 公司的 Git 规范文档：如果你的公司有，请务必逐字逐句精读。里面沉淀的都是你所在团队的最佳实践和血泪教训，比任何外部教程都更有针对性。我这里强烈推荐这份字节内部的git手册Git零基础实战手册.pdf（纯free，自由获取），结合了大厂协作流程和真实事故案例写成的系统教程。