分类
最让人后背发凉的 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 直译是“重新设置基底”。
听起来有点...
很多程序员第一次遇到 Git 冲突，心里都会一紧。
终端里突然出现：
CONFLICT
Automatic merge failed; fix conflicts and then commit the result.
再打开文件，看到一堆奇怪标记：
<<<<<<< HEAD
=======
>>>>>>> feature/login
一瞬间，仿佛项目已经失控。
但其实，Git 冲突并不是灾难。它只是在提醒你：
同一块代码，两边都改了，Git 不知道该听谁的，需要你来决定。
这篇文章我们不讲复杂理论，直接用实战方式讲清楚：冲突...
很多刚进入团队开发的程序员，第一次听到 Pull Request，都会有点迷糊。
代码不是已经 git push 上去了吗？
为什么还要发 PR？
PR 是不是就是“提交代码”？
Reviewer 又到底在看什么？
一句话说清楚：
Pull Request 不是提交代码，而是请求团队审查并合并代码。
它真正解决的问题不是“代码怎么传上去”，而是“这段代码能不能进入主分支”。
Pull Request，简称 PR，中文常叫“拉取请求”或“合并请求”。
在 GitHub 里通常叫 Pull Request。
在 GitLab 里通常叫 Merge Request。
名字...
写这个 Git 系列，一开始并不是想做一份“命令大全”。
因为 Git 命令真的太多了。
add、commit、branch、merge、rebase、reset、pull、fetch……如果一上来就背命令，新手很容易越学越乱。
但我后来发现，真正让人卡住的，往往不是某个命令本身，而是这些问题：
main 上开发？.gitignore 写了却不生效？所以这个系列真正想讲的，不只是 Git 怎么用，而是 Git 背后的开发...