Git 总览

Git 管理的是文件快照及其提交关系。以订单导出为例：开发者同时修改了导出逻辑和调试日志，可以只暂存导出逻辑，形成可审查提交；同事修改权限后，双方再合并并验证。提交、共享、评审、部署是不同动作，Git 本身不会替代测试或发布系统。

先分清三个问题

准备交付哪些内容？ 工作区是当前文件，暂存区是下一次提交候选。修改文件后执行 add，随后继续编辑，并不会自动更新已暂存内容。提交前同时看 git diff 和 git diff --staged，才能区分留下的工作与要交付的工作。

这些修改依赖哪段历史？ 分支只是提交引用，合并和变基改变的是提交关系。分支不会复制一套独立目录；需要同时打开两个版本时用 worktree。共享分支上有人继续开发后，改写提交会改变他们依赖的历史，应优先新增提交或 revert。

远端现在是什么状态？ origin/main 是本地远程跟踪引用，不是实时查询。先 fetch 再比较；push 成功说明远程引用更新，不代表评审、CI 或部署已经完成。

按任务选择页面

现在遇到的问题	阅读入口	可以得到什么
不清楚 add 与 commit 到底记录哪份文件	核心概念	工作区、暂存区、对象与引用的关系
需要安装、提交、查看差异或暂存工作	日常命令	可复制操作及各命令的输入范围
两人同时修改，需要同步或解决冲突	分支与合并、协作流程	merge/rebase/cherry-pick 的判断与评审闭环
需要拆提交、写评审描述	提交规范	围绕一个意图组织变更
误提交、误删、需要撤销公共变更	撤销与恢复	按工作区、索引、引用和共享历史选择操作
仓库克隆慢、历史大、依赖多	对象库与大型仓库、仓库组织	Partial/Sparse/LFS 与多仓库边界
密钥误提交或需要权限治理	安全与仓库治理	先撤销凭据，再评估历史和传播范围
需要定位回归、并行检出或版本标签	进阶操作、生态工具	bisect、worktree、Hooks 与平台能力
需要自建持续集成和发布	GitLab CI/CD	托管、Runner、权限和发布边界
希望连续学习	视频系列	分集主题与配套阅读路径

一次日常提交

下面假设已有本地功能分支、远程名为 origin，并配置了正确上游；src/order-export.ts 替换为实际文件。先确认范围，再提交，避免把日志或凭据混入。

git status -sb
git diff -- src/order-export.ts
git add -p -- src/order-export.ts
git diff --staged
git commit -m "fix(export): 修复空结果导出"
git fetch origin
git status -sb

fetch 后检查目标分支的变化，再按协作约定 merge 或 rebase 并测试，最后 push。不要把固定的 pull --rebase 当成所有分支的无条件前置步骤；更新本地 main 时通常用 pull --ff-only，发生分叉就停下来理解历史。

能力验证

入门阶段应能解释“文件改了两次、只 add 一次，commit 会记录哪次”，并用暂存差异核实。协作阶段应能在临时仓库制造一次冲突，完成合并或取消，说明处理后需要验证的业务行为。

维护阶段应能从已知提交找回文件，在误操作后用新分支保护仍可找到的提交，并区分 Git bundle、工作区文件和 LFS 对象的备份范围。具体演练见相应细节页，不在总览重复所有命令。

常见误区

操作习惯	容易遗漏什么	判断办法
每次直接 add 整个目录	未跟踪文件、调试修改、无关配置	先检查状态，按文件或补丁暂存
新建分支就认为改动已备份	分支只保护提交引用	未提交内容另存、stash 或临时提交
用工作区干净判断已交付	ignored 文件、未推送提交、平台检查	分别核对状态、远程引用与 CI
把 force-with-lease 当成绝对保护	默认租约依赖本地跟踪引用	共享分支先协调，必要时核对明确预期 OID
合并成功就认为功能正确	自动合并也可能产生业务错误	验证权限、导出结果与失败路径