Quick Start
快速开始
先用几个低风险命令建立对分支、提交和同步的直觉。
初始化仓库
了解 git init、git clone、身份配置和默认分支。
git clone repo-url暂存与提交
理解工作区、暂存区和提交历史的三层关系。
git add . && git commit同步远端
掌握 fetch、pull、push 与本地分支的协同方式。
git fetch originBest Practices
最佳实践
减少历史污染和冲突成本。
保持提交小而明确
每次提交只表达一个意图，便于 review、回滚和 cherry-pick。
优先 fetch，再决定 merge 或 rebase
先获取远端状态，再显式选择同步策略，比默认 pull 更可控。
危险操作前先看 reflog
reset、rebase、force push 之前确认可恢复路径，降低误操作损失。
Git Internals
底层原理
把命令行为和对象模型对应起来。
对象数据库
blob、tree、commit 如何组合成可追踪的历史图。
引用与 HEAD
分支、本地标签、远端跟踪分支都是指向提交的引用。
可恢复性
reflog 与 gc 机制决定对象什么时候还能被找回。
Reference
命令参考路线
把高频命令整理成渐进式学习路径。
clone
拉取仓库并建立本地副本。
add
把改动加入暂存区。
commit
生成新的提交对象。
rebase
重写提交基底并整理历史。
FAQ
常见问题
基于 Git 官方文档与官方书中的高频问题整理出一组上手最常见的答疑。
`git pull` 会先执行 fetch，再把上游分支整合进当前分支。官方文档说明它可以走 `--ff-only`、`--rebase`、`--no-rebase` 或 `--squash` 等不同路径，所以结果取决于你的命令参数和 `pull.rebase`、`pull.ff` 等配置。想减少意外，最稳妥的习惯仍然是先 fetch，再明确决定是 merge 还是 rebase。
官方手册把区别讲得很明确：`--soft` 只移动 HEAD，保留暂存区和工作区；`--mixed` 会把暂存区重置到目标提交，但保留工作区改动；`--hard` 会同时改写 HEAD、暂存区和工作区。也就是说，真正危险的是 `--hard`，因为它会直接覆盖当前文件状态。
很多时候可以。Git 官方在 `git reset` 文档里专门说明了 `ORIG_HEAD` 和 reflog 的用途：reset、merge、pull 这类操作通常会留下可回溯的引用。只要对象还没被垃圾回收清理掉，通常都能先通过 reflog 找到原来的提交，再决定是新建分支还是回退引用。
Git Docs
教程材料已经进入 content/ 内容源。
继续浏览文档库，或者把更多 Git 主题接进同一套 MDX 渲染体系。