上周有朋友说团队新人不敢碰 Git，一听到 rebase 就心慌。我说现在根本不用怕——打开 Claude Code 或 Codex，用大白话告诉它你的需求，它会先跑 git status 列出状态，给计划，等你点头才动手。
朋友问："那我还学 Git 干嘛？"答案很明确：命令可以不背了，概念一个都不能少。搞懂了设计意图，命令就不再是黑魔法，而是一堆顺理成章的必然。具体的命令记不住没关系，收藏当手册用，概念和判断必须长在自己脑子里。
先建立四个基础认知
第一，Git 和 GitHub 不是一回事。Git 是装在你电脑上的版本控制工具，管"记录改动"，完全离线也能用。GitHub 是托管 Git 仓库的网站，管"把大家的仓库攒到一起"，提供讨论、审查、自动化等协作功能。前者是引擎，后者是车库加车队群。
第二，Git 是分布式的。每个人的本地仓库都是完整副本，历史、分支、标签全在手里，断网照样提交。分布式解决了集中式版本控制"服务器一挂全队瘫痪"的问题。
第三，Git 存的是快照，不是差异。每次提交，Git 把整个项目拍成一张完整快照存下来，没变的文件直接指向上一版的存档。这解释了为什么切分支只要一毫秒（只是创建指针）、为什么历史绝对可信（快照编号由内容计算得出）、为什么回退如此轻松（完整快照一直存在）。
第四，文件在 Git 眼里只有三个状态。已修改（改了但还没登记）、已暂存（用 git add 放进下一次提交的购物车）、已提交（改动安全地写进历史）。所有撤销操作都是在这三个状态之间倒腾。
安装与配置
macOS 用 Homebrew：brew install git。Windows 去 git-scm.com 下载安装包。Linux 用包管理器一条命令搞定。
装完配置身份：git config --global user.name 和 git config --global user.email。强烈建议加上几个顺手配置：中文文件名正常显示、pull 时用 rebase 保持线性历史、默认编辑器换成 VS Code。
跟 GitHub 通信建议用 SSH 密钥：ssh-keygen -t ed25519，公钥粘到 GitHub Settings → SSH keys，ssh -T git@github.com 看到 "Hi xxx! You've successfully authenticated" 就成了。
核心概念：四个区域加一条链路
四个区域是 Git 的骨架：
- 工作区：眼前的项目文件夹，改动的文件先落在这里
- 暂存区：像购物车，git add 把想提交的改动放进去，攒一波再结账
- 本地仓库：完整的历史存档，git commit 结算成永久记录
- 远程仓库：GitHub 上的共享副本，靠 push 和 pull 互通
暂存区让你拥有"挑着提交"的自由——同时改了五个文件，三个属于登录功能、两个属于修样式，分两次 add + commit，历史就干干净净各归各类。
那个指针叫 HEAD，它指向"你现在在哪"。所有 checkout、switch、reset 的本质都是挪这根指针。理解了指针，Git 的一切操作在脑子里就有了画面。
一条链路是团队协作的骨架：仓库 → 提交 → 分支 → 远程仓库 → Pull Request → 门禁（Code Review + CI/CD）。
基础操作：够用的那一小撮
日常 80% 的场景就这几个命令：git status（每天敲十几遍，做任何操作前先看一眼）、git diff（看未 add 的改动）、git diff --staged（看已 add 等着提交的改动）、git add .、git commit -m "说明"。
三个高频修补：git commit --amend 补上一次提交、git stash 存现场切分支、git blame 追溯某行代码是谁改的。
撤销操作按三状态分层：改动退一层用 restore，提交退一层用 reset，已经推出去的用 revert。git reset 有三个档位：--soft（撤提交，改动留暂存区）、--mixed（默认，改动退回工作区）、--hard（彻底丢弃）。
救命命令 git reflog 记录本地仓库的每一次 HEAD 移动——只要提交过，数据就在本地仓库里，丢的只是指针不是内容。
分支与合并：Git 的灵魂
创建分支只是生成一个指向某提交的可移动指针，一秒完成。合并分两种：快进合并（main 没有新提交，只是挪指针）和三方合并（两边都有新提交，找到共同祖先算到一起）。
冲突不吓人，它只是 Git 在说"两边改了同一个地方，我不知道听谁的"。VS Code 和 AI 工具现在都能可视化解决冲突。
再往深一层是 rebase——把你的提交摘下来重放到一个新的起点上。merge 保留真实历史但图会分叉，rebase 历史线性干净但会改写提交。业界约定：自己没推出去的本地提交随便 rebase，已经推到远程给别人看的提交，别动。
远程仓库与 GitHub：从单机到团队
git fetch 只是把远程最新数据下载到本地只读副本，代码不动；git pull 是 fetch + merge。稳妥的习惯是先 fetch 看一眼再决定。
推送被拒绝时，git pull --rebase 把本地提交挪到最新代码之上再 push。真正危险的是 git push --force，会无声覆盖队友的提交。要用它的安全版 git push --force-with-lease——远程有别人的新提交时会拒绝，而不是覆盖。
想让改动进 main，不是直接 push，而是发 Pull Request。PR 页面上团队逐行看代码、留评论、CI 自动跑测试，全过再点合并。
协作工作流：Feature Branch
掌握一个最主流的 Feature Branch 工作流就够：从最新 main 切出功能分支 → 开发小步提交 → 推到远程 → 发 PR 请人 review → 审查通过、CI 全绿、合并、删分支。
合并方式三种选择：Merge commit（保留完整历史）、Squash and merge（碎提交压成一个，大多数团队默认选这个）、Rebase and merge（线性又不丢提交）。小团队直接定死 Squash，省心。
开源项目走 Fork 工作流：fork 到自账号 → clone 开发 → 推上去 → 向原仓库发 PR。这个设计把"贡献的门槛"降到了零。
GitHub 组织协作：人多之后的规矩
分支保护：禁止直接 push 到 main、必须通过 PR、至少 1 人 approve、必须通过 CI 检查、禁止 force push 改写 main 历史。
CODEOWNERS：指定某些路径的改动必须由谁审查。支付模块的变更自动拉支付组的人进 review，规矩自动执行，不用人盯。
GitHub Actions：每次 push 和 PR 时自动跑测试和构建，绿灯了才轮到人说话。密钥放在仓库的 Secrets 里，Actions 运行时自动注入。
Issue 与 Projects：每个 PR 关联一个 Issue，分支名带 Issue 编号（如 feature/login-42），PR 描述写 Closes #42，合并时 Issue 自动关闭。
AI 时代的协作：跟 AI 怎么配合
给 AI 下指令，五件事交代到位：目标是什么、仓库和远程在哪、当前分支和状态、约束条件（权限、生产、是否允许改写历史）、验收标准和回滚方式。
AI 会先 git status 摸现场，给计划，分步执行，每步回读核验。它不会手抖敲错分支名，不会忘了加 --force-with-lease，也不会在凌晨三点犯困。
但四条边界必须人来守：分支归属、变更范围、权限边界、发布结果。凡涉及删除、force push、历史改写、生产发布，无论 AI 说得多有把握，必须人工确认后再执行。
AI 越强，这条铁律越值钱。工具替你省下的是敲命令的力气，替不了你的是对结果负责的位置。
最佳实践
小步提交，一次提交只干一件事。敏感信息不进仓库，.env、密钥、token 写进 .gitignore。勤拉勤推，每天开始先 pull，下班前 push。PR 控制尺寸，几百行的 PR 认真看，几千行的只能草草放行。main 永远可发布。
想起庄子在《外物》里的一句话："言者所以在意，得意而忘言。"语言是用来承载意思的，意思拿到了，语言就可以放下了。两千多年后拿来看 Git 和 AI 的关系，严丝合缝。
命令就是那个"言"，概念和结果才是"意"。以前学 Git 是抱着"言"不放，五十个命令背得滚瓜烂熟，遇到冲突照样傻眼。现在 AI 把"言"这一层整个接走了，你反而有机会直接去抓"意"——为什么要有分支、为什么变更要走 PR、为什么 main 值得守护。
指令可以交给 AI，概念、边界与结果，必须由人掌握。
