标签
写这个 Git 系列，一开始并不是想做一份“命令大全”。
因为 Git 命令真的太多了。
add、commit、branch、merge、rebase、reset、pull、fetch……如果一上来就背命令，新手很容易越学越乱。
但我后来发现，真正让人卡住的，往往不是某个命令本身，而是这些问题：
main 上开发？.gitignore 写了却不生效？所以这个系列真正想讲的，不只是 Git 怎么用，而是 Git 背后的开发...
很多刚进入团队开发的程序员，第一次听到 Pull Request，都会有点迷糊。
代码不是已经 git push 上去了吗？
为什么还要发 PR？
PR 是不是就是“提交代码”？
Reviewer 又到底在看什么？
一句话说清楚：
Pull Request 不是提交代码，而是请求团队审查并合并代码。
它真正解决的问题不是“代码怎么传上去”，而是“这段代码能不能进入主分支”。
Pull Request，简称 PR，中文常叫“拉取请求”或“合并请求”。
在 GitHub 里通常叫 Pull Request。
在 GitLab 里通常叫 Merge Request。
名字...
很多程序员第一次遇到 Git 冲突，心里都会一紧。
终端里突然出现：
CONFLICT
Automatic merge failed; fix conflicts and then commit the result.
再打开文件，看到一堆奇怪标记：
<<<<<<< HEAD
=======
>>>>>>> feature/login
一瞬间，仿佛项目已经失控。
但其实，Git 冲突并不是灾难。它只是在提醒你：
同一块代码，两边都改了，Git 不知道该听谁的，需要你来决定。
这篇文章我们不讲复杂理论，直接用实战方式讲清楚：冲突...
很多程序员第一次听到 git rebase，心里都会有点发怵。
因为它不像 git merge 那样直观。
Merge 像是“把两条分支合到一起”，而 Rebase 听起来像是在“重写历史”。
更可怕的是，你可能还听过一句劝告：
不懂 Rebase，千万别乱用。
这话没错，但也容易让人错过一个非常好用的工具。
Rebase 的核心价值其实很简单：让提交历史更干净。
如果你理解了它在做什么，就会发现它不是洪水猛兽，而是一个能让团队协作更清爽的 Git 神器。
rebase 直译是“重新设置基底”。
听起来有点...
很多程序员刚学 Git 时。
都会觉得这几个命令特别像：
git pull
git fetch
git merge
尤其是 pull。
很多人每天都在用：
git pull origin main
但真问一句：
“pull 到底做了什么？”
很多人其实答不上来。
于是团队协作里，经常出现：
最后只能开始：
git stash
git reset
git reflog
现场像灾难片。
问题的根源其实很简单：
很多人会用 Git，但并不理解 Git。
这篇文章，我们就彻底讲清楚：
最让人后背发凉的 Git 场景，往往不是 commit 错了。
而是你已经把错误提交 push 到远程仓库了。
比如：
git push origin main
按下回车后才发现：
这时候很多人的第一反应是：
git reset --hard HEAD~1
git push --force
先别急。
如果代码已经 push，事情就不再只是你本地的事了。因为别人可能已经拉取了你的提交。
刚 commit 完，突然发现代码还没整理好。
变量名有点乱，测试也没补，甚至还有几行临时调试代码。
这时候你可能想做一件事：
把刚才那次 commit 撤回来，但代码先留着。
如果这次提交还没有 push 到远程仓库，恭喜你，这是 Git 最好补救的阶段。
这篇我们只讲一个核心问题：
git reset 到底怎么用，
尤其是 --soft、--mixed、--hard 三种模式有什么区别。
本地 commit 出错，其实并不可怕。
因为代码还没有进入公共历史，通常不会影响别人。你可以根据自己的需要，把最近一次 commit 撤回来，然后重新...
刚提交完代码，你突然发现一件很尴尬的事：
commit message 写错了。
或者更糟一点：
代码提交了，README 忘记加了。
这时候很多人的第一反应是慌，甚至想立刻执行：
git reset --hard
先别急。
如果你的代码只是刚 commit，还没有 push 到远程仓库，这种问题其实非常好处理。Git 给我们准备了一颗很常用的“后悔药”：git commit --amend。
它的作用很简单：
修改最近一次 commit。
注意，是“最近一次”。这也是它好用但不能乱用的原因。
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 就需要判断两边代码怎么放到一起。
如果两边改的是不同...
假设你现在要开发一个功能：
手机号登录。
标准流程不是直接开写，而是先同步主分支。
git checkout main
git pull origin main
这一步很重要。
如果你的 main 已经过时，后面合并时更容易出现冲突。先拉最新代码，等于从一个干净、最新的起点出发。
接着，创建功能分支：
git checkout -b feature/login
这行命令做了两件事：
feature/login现在你就可以放心开发登录功能了，比如：
开发过程中，不建议把所有修改攒到最后一次性提交。...