很多程序员刚学 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，事情就不再只是你本地的事了。因为别人可能已经拉取了你的提交。
很多人刚开始用 Codex 时，都会遇到一个问题：
它确实能写代码，但有时候写出来的风格不像我的项目。
比如你的项目用 pnpm，它却用了 npm；你们约定提交前要跑 lint，它忘了；你希望它少做大重构，它却顺手改了一堆无关文件。
这不是 Codex 不聪明，而是它还不知道你的团队习惯。
所以，想让 Codex 真正变成“懂项目的编码搭档”，第一步不是疯狂提 prompt，而是给它写清楚：这个项目有哪些规则。
在 Codex 里，最重要的规则通常有两类：
AGENTS.md.codex/rules/*.rules这篇文章重点讲前者，也...
刚 commit 完，突然发现代码还没整理好。
变量名有点乱，测试也没补，甚至还有几行临时调试代码。
这时候你可能想做一件事：
把刚才那次 commit 撤回来，但代码先留着。
如果这次提交还没有 push 到远程仓库，恭喜你，这是 Git 最好补救的阶段。
这篇我们只讲一个核心问题：
git reset 到底怎么用，
尤其是 --soft、--mixed、--hard 三种模式有什么区别。
本地 commit 出错，其实并不可怕。
因为代码还没有进入公共历史，通常不会影响别人。你可以根据自己的需要，把最近一次 commit 撤回来，然后重新...
新手如何使用 Codex：从安装到第一次改代码
你有没有遇到过这种场景：接手一个陌生项目，文件很多，逻辑绕来绕去，光是搞懂入口就要半天？
这正是 Codex 适合出场的地方。简单说，Codex 是 OpenAI 的 AI 编程助手，可以帮你阅读代码、修改文件、运行命令、解释报错，甚至在云端帮你完成一个开发任务。本文会带你从安装、登录到第一次使用，快速跑通 Codex 的基本流程。
Codex 可以理解为一个“会看项目的 AI 程序员搭档”。
它不只是回答“这段代码是什么意思”，还可以进入你的代码仓库，理解文件结构，根据你的需求修改代码，并生成可 review 的变更...
刚提交完代码，你突然发现一件很尴尬的事：
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现在你就可以放心开发登录功能了，比如：
开发过程中，不建议把所有修改攒到最后一次性提交。...
很多刚学 Git 的人，都会这样写代码：
git checkout main
git pull
git coding...
git push
看起来很顺手，问题也往往来得很突然。
某一天，你会发现：同事的代码被覆盖了，半成品功能进了主分支，一个小 Bug 影响了整个项目。更麻烦的是，出了问题之后，很难快速回滚。
这就是团队开发里很少直接在 main 分支写代码的原因。
更常见的做法是：
一个功能，一个 feature 分支。
比如团队同时开发几个功能：
main
├── feature/...很多人第一次学 Git 分支时，都会觉得它像一种“黑魔法”。
明明：
更离谱的是：
git checkout dev
短短一秒钟，整个项目居然就“变了”。
于是很多人开始背命令：
git branch
git checkout
git merge
git rebase
命令会用了。
但心里始终有个疑问：
Git 分支，到底是什么？
这篇文章，我们不聊复杂源码，也不讲晦涩概念。
只做一件事：
用人话，真正理解 Git 分支的工作原理。
看完之后，你会明白：