很多刚进入团队开发的程序员，第一次听到 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，事情就不再只是你本地的事了。因为别人可能已经拉取了你的提交。
很多人刚开始用 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 就需要判断两边代码怎么放到一起。
如果两边改的是不同...