分类
很多人学 Git 时，最先记住的命令是：
git add .
git commit -m "fix bug"
git push
可一旦项目真正开始协作，你会发现：
真正有价值的，不是“怎么提交代码”，而是“怎么理解代码为什么变成现在这样”。
这时候，git log 就开始变得重要了。
它不是一串无聊的提交记录。 它更像项目的“时间机器”。
你能从里面看到：
很多高级开发者排查问题时，第一反应不是打开 IDE，而是先看 git log。
很多人第一次学 Git 分支时，都会觉得它像一种“黑魔法”。
明明：
更离谱的是：
git checkout dev
短短一秒钟，整个项目居然就“变了”。
于是很多人开始背命令：
git branch
git checkout
git merge
git rebase
命令会用了。
但心里始终有个疑问：
Git 分支，到底是什么？
这篇文章，我们不聊复杂源码，也不讲晦涩概念。
只做一件事：
用人话，真正理解 Git 分支的工作原理。
看完之后，你会明白：
很多刚学 Git 的人，都会这样写代码：
git checkout main
git pull
git coding...
git push
看起来很顺手，问题也往往来得很突然。
某一天，你会发现：同事的代码被覆盖了，半成品功能进了主分支，一个小 Bug 影响了整个项目。更麻烦的是，出了问题之后，很难快速回滚。
这就是团队开发里很少直接在 main 分支写代码的原因。
更常见的做法是：
一个功能，一个 feature 分支。
比如团队同时开发几个功能：
main
├── feature/...假设你现在要开发一个功能：
手机号登录。
标准流程不是直接开写，而是先同步主分支。
git checkout main
git pull origin main
这一步很重要。
如果你的 main 已经过时，后面合并时更容易出现冲突。先拉最新代码，等于从一个干净、最新的起点出发。
接着，创建功能分支：
git checkout -b feature/login
这行命令做了两件事：
feature/login现在你就可以放心开发登录功能了，比如：
开发过程中，不建议把所有修改攒到最后一次性提交。...
Feature 分支开发完成后，最终要合并回 main。
最简单的情况是这样的：
main: A -> B
feature: -> C -> D
如果 main 在这期间没有新提交，合并通常很顺利：
git merge feature/login
Git 可能直接做一次 Fast Forward，也就是快进合并。
但现实里很少这么安静。
你开发登录功能时，别人可能已经往 main 合并了新代码：
main: A -> B -> E
feature: -> C -> D
这时再合并，Git 就需要判断两边代码怎么放到一起。
如果两边改的是不同...
刚提交完代码，你突然发现一件很尴尬的事：
commit message 写错了。
或者更糟一点：
代码提交了，README 忘记加了。
这时候很多人的第一反应是慌，甚至想立刻执行：
git reset --hard
先别急。
如果你的代码只是刚 commit，还没有 push 到远程仓库，这种问题其实非常好处理。Git 给我们准备了一颗很常用的“后悔药”：git commit --amend。
它的作用很简单：
修改最近一次 commit。
注意，是“最近一次”。这也是它好用但不能乱用的原因。
刚 commit 完，突然发现代码还没整理好。
变量名有点乱，测试也没补，甚至还有几行临时调试代码。
这时候你可能想做一件事：
把刚才那次 commit 撤回来，但代码先留着。
如果这次提交还没有 push 到远程仓库，恭喜你，这是 Git 最好补救的阶段。
这篇我们只讲一个核心问题：
git reset 到底怎么用，
尤其是 --soft、--mixed、--hard 三种模式有什么区别。
本地 commit 出错，其实并不可怕。
因为代码还没有进入公共历史，通常不会影响别人。你可以根据自己的需要，把最近一次 commit 撤回来，然后重新...
最让人后背发凉的 Git 场景，往往不是 commit 错了。
而是你已经把错误提交 push 到远程仓库了。
比如：
git push origin main
按下回车后才发现：
这时候很多人的第一反应是：
git reset --hard HEAD~1
git push --force
先别急。
如果代码已经 push，事情就不再只是你本地的事了。因为别人可能已经拉取了你的提交。
很多程序员刚学 Git 时。
都会觉得这几个命令特别像：
git pull
git fetch
git merge
尤其是 pull。
很多人每天都在用：
git pull origin main
但真问一句：
“pull 到底做了什么？”
很多人其实答不上来。
于是团队协作里，经常出现：
最后只能开始：
git stash
git reset
git reflog
现场像灾难片。
问题的根源其实很简单：
很多人会用 Git，但并不理解 Git。
这篇文章，我们就彻底讲清楚：
很多程序员第一次听到 git rebase，心里都会有点发怵。
因为它不像 git merge 那样直观。
Merge 像是“把两条分支合到一起”，而 Rebase 听起来像是在“重写历史”。
更可怕的是，你可能还听过一句劝告：
不懂 Rebase，千万别乱用。
这话没错，但也容易让人错过一个非常好用的工具。
Rebase 的核心价值其实很简单：让提交历史更干净。
如果你理解了它在做什么，就会发现它不是洪水猛兽，而是一个能让团队协作更清爽的 Git 神器。
rebase 直译是“重新设置基底”。
听起来有点...