Git 知识体系总览
mindmap root((Git 知识体系)) 基础概念 仓库 Repository 本地仓库 远程仓库 裸仓库 Bare 工作区 Working Directory 暂存区 Staging Area 提交 Commit SHA-1 哈希 提交信息 父提交 分支 Branch HEAD 指针 主分支 main/master 标签 Tag 轻量标签 附注标签 常用命令 本地操作 初始化与克隆 init clone 暂存与提交 add commit rm mv 查看状态 status log diff show 远程操作 push pull fetch remote 管理 分支操作 branch 创建删除 checkout switch merge 快进合并 Fast-forward 三方合并 Three-way 冲突解决 rebase 变基原理 交互式 rebase -i rebase vs merge 高级操作 暂存 Stash stash save/push stash pop/apply stash list/drop 拣选 Cherry-pick 单提交拣选 多提交拣选 二分查找 Bisect bisect start/bad/good 自动化 bisect run 提交日志 Reflog reflog 查看 恢复丢失提交 撤销错误操作 重写历史 commit --amend rebase -i 压缩/编辑/删除 filter-branch / filter-repo 子模块 Submodule 工作流 Git Flow 长期分支 main/develop 特性分支 feature 发布分支 release 热修复分支 hotfix 适用场景 版本化产品 GitHub Flow 单一主分支 main 特性分支 + PR 持续部署 适用场景 SaaS/Web 应用 Trunk Based Development 单一主干 trunk 短期特性分支 特性开关 Feature Flag 适用场景 高频持续交付 协作 Fork 模式 上游仓库 Upstream 个人 Fork 同步上游变更 Pull Request / Merge Request 创建 PR 代码审查 Review 合并策略 Merge/Squash/Rebase Code Review 审查要点 评论与讨论 批准与变更请求 Issue 追踪 创建与管理 Issue 标签 Label 里程碑 Milestone 关联提交与 PR
本思维导图覆盖 Git 知识体系的五大核心领域：
- 基础概念：理解 Git 的内部模型（工作区 → 暂存区 → 仓库）是掌握所有命令的前提。Commit、Branch、Tag 构成了 Git 的数据结构基础。
- 常用命令：按本地操作、远程操作、分支操作三类组织。
merge与rebase是整合变更的两种核心方式，理解其差异对日常开发至关重要。 - 高级操作：
stash用于临时保存工作现场，cherry-pick用于精确选取提交，bisect用于定位引入 Bug 的提交，reflog是恢复丢失数据的最后手段。 - 工作流：Git Flow 适合有固定发布周期的项目，GitHub Flow 适合持续部署的 Web 应用，Trunk Based Development 适合追求极致交付频率的团队。
- 协作：Fork + PR 是开源协作的标准模式，Code Review 保障代码质量，Issue 追踪管理需求与缺陷。
Git 不是一组需要背诵的命令，而是一套记录工程历史的对象模型。命令只是操作这个模型的入口。理解工作区、暂存区、提交、分支和远程引用，后面遇到冲突、回滚、变基、丢提交时才不会慌。
什么是版本控制
版本控制系统（VCS）是一种记录文件内容变化，以便将来查阅特定版本修订情况的系统。
本地版本控制系统
本地 VCS 采用数据库记录文件的历次更新差异，通过在硬盘上保存补丁集来重建各版本文件内容。
graph TD A[文件数据库] --> B[版本1] B --> C[版本2] C --> D[版本3]
集中化的版本控制系统
集中化 VCS（CVCS）采用单一服务器保存所有修订版本，协作者通过客户端连接服务器拉取或提交更新，解决了多人协作问题，但存在中央服务器单点故障的风险。
graph LR C[中央服务器] --> D[开发者A] C --> E[开发者B]
分布式版本控制系统
分布式 VCS（DVCS）中每个节点都拥有仓库的完整镜像，不存在中心节点故障或数据丢失问题，还可以与多个远端仓库交互，灵活设定协作流程。
graph LR S[远程仓库] --> A[开发者A本地] S --> B[开发者B本地]
Git 简史
2005 年，Linus Torvalds 为 Linux 内核开发创建了 Git。它的设计目标是速度快、设计简单、强力支持非线性开发（成千上万个并行分支）、完全分布式，以及能高效管理超大规模项目。如今的 Git 已成为使用最广泛的版本控制系统，在保持高度易用的同时依然保留着初期设定的目标。
Git 的核心特性
直接记录快照，而非差异比较
Git 将每次提交视为完整快照。每次提交时，Git 对所有文件创建快照并保存索引；未修改的文件不会重新存储，而是保留指针指向之前存储的版本。Git 对待数据更像是一个快照流。
近乎所有操作本地执行
由于 Git 是分布式版本控制系统，绝大多数操作只需访问本地文件资源，不存在网络延迟，操作瞬间完成。
保证数据完整性
Git 中所有数据在存储前都用 SHA-1 散列计算校验和，以哈希值索引而非文件名。这意味着不可能在 Git 不知情时更改任何文件或目录内容。
# SHA-1 哈希示例
24b9da6552252987aa493b52f8696cd6d3b00373一般只添加数据
Git 一般只添加数据，所以你很难执行任何不可逆操作，或者让 Git 以任何方式清除数据。
三种状态与三个区域
graph LR W[工作区] -->|git add| S[暂存区] S -->|git commit| R[Git仓库]
Git 有三种状态，你的文件可能处于其中之一：已修改（modified）、已暂存（staged） 和 已提交（committed）。
- 已修改：修改了文件，但还没保存到数据库中
- 已暂存：对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中
- 已提交：数据已经安全地保存在本地数据库中
这会让你的 Git 项目拥有三个阶段：工作区（Working Directory）、暂存区（Staging Area） 以及 Git 目录（Repository）。
- 工作区：从项目的某个版本独立提取出来的内容，放在磁盘上供你使用或修改
- 暂存区：保存了下次将要提交的文件列表信息
- Git 目录：Git 用来保存项目的元数据和对象数据库的地方
Git 的基本工作流程如下：
- 在工作区中修改文件（已修改）
- 将你下次想要提交的更改选择性地暂存，这样只会将更改的部分添加到暂存区（已暂存）
- 提交更新，找到暂存区的文件，将快照永久性存储到 Git 目录（已提交）
首次配置
Git 初次使用需要设置身份信息。它不是装饰字段，而会写进每一次提交，成为协作历史的一部分。
用户信息
务必设置用户名和邮件地址，因为每一个 Git 提交都会使用这些信息，并写入到每一次提交中。
git config --global user.name <user-name>
git config --global user.email <[email protected]m>查看配置
// 所有 Git 配置
git config --list
// 检查 Git 的某一项配置
git config <key>获取帮助
git help <verb>
git <verb> --help
man git-<verb>
// 简明的帮助文件
git <verb> -h使用原则
先看状态，再做动作：git status 是进入仓库后的第一反应。它告诉你当前分支、暂存区、工作区和远程关系。
提交是历史单位，不是保存按钮：一次提交应该表达一个可理解的变化。太大的提交难审查，太碎的提交难复盘。
暂存区是选择器：git add 不是简单“保存”，而是在选择下一次提交要包含哪些变化。善用暂存区，才能写出干净历史。
Git 的可恢复性来自对象和引用：多数误操作可以通过 reflog、分支、标签或远程引用找回。真正危险的是在不了解后果时改写共享历史。