设计哲学
Git是由林纳斯·托瓦兹（Linus Torvalds）于2005年创建的分布式版本控制系统，最初用于Linux内核的开发管理。与集中式版本控制系统（如SVN、CVS）不同，Git的每个工作副本都是完整的仓库，包含项目的完整历史记录。这种分布式架构使得开发者可以在本地进行完整的版本控制操作，无需持续连接中央服务器。
Git的设计深受文件系统与分布式数据库的启发，其底层是一个内容寻址的文件系统（Content-Addressable Filesystem），上层是版本控制系统的用户界面。Git将数据视为文件的快照流（stream of snapshots），而非基于文件的差异（delta-based）系统。每次提交时，Git会对当前所有文件制作快照并保存引用；对于未变化的文件，Git仅存储指向上次快照的链接。这种设计使Git的分支操作极为轻量快速。
Git的三种状态——已修改（Modified）、已暂存（Staged）和已提交（Committed）——构成了本地版本控制的基本流程。工作区（Working Directory）是实际文件的 checkout；暂存区（Staging Area / Index）是准备下次提交的文件快照列表；仓库（Repository / .git directory）是存储项目元数据和对象数据库的地方。文件在三种状态之间流转：编辑文件进入已修改状态，git add将修改加入暂存区，git commit将暂存内容永久保存到仓库历史。
底层对象模型
理解Git的底层对象模型是掌握Git高级操作的基础。Git的核心是一个键值对数据库，存储四种类型的对象：blob（文件内容）、tree（目录结构）、commit（提交信息）和tag（标签引用）。所有对象通过SHA-1哈希值（40位十六进制字符串）唯一标识和内容寻址。
Blob对象存储文件的内容（不包括文件名和元数据）。当文件内容相同时，无论文件名或路径如何，Git只存储一个blob对象。Tree对象存储目录结构，包含指向blob和子tree的引用及其模式、类型和文件名。一个tree对象对应文件系统中的一个目录。Commit对象包含指向顶层tree的指针、作者和提交者信息、时间戳、提交消息，以及零个或多个父提交的指针（普通提交有一个父提交，合并提交有多个父提交，初始提交没有父提交）。
Git的对象存储在.git/objects目录下，按哈希值的前两位作为子目录名，后38位作为文件名。这种存储方式在对象数量庞大时可能导致性能问题，因此Git会定期执行垃圾回收（git gc），将松散对象打包为packfile，并使用增量压缩节省空间。packfile存储完整的对象和基于差异的增量对象，通过偏移量引用，显著提升了存储和传输效率。
引用（References）是指向提交对象的指针，分为轻量级和附注式两种。分支（branch）是一种可移动的引用，随着新的提交自动向前移动。HEAD是一个特殊的引用，指向当前检出的分支或提交（分离HEAD状态）。标签（tag）是固定的引用，通常用于标记发布版本。远程引用（remote references）记录了远程分支的最后已知状态。
分支管理
分支是Git最强大的特性之一。在Git中，创建一个分支仅仅是创建一个指向当前提交的指针（约40字节的文件），切换分支则是移动HEAD指针并更新工作区文件。这与传统版本控制系统复制整个代码目录的做法截然不同，使得Git的分支操作几乎瞬间完成。
分支的创建通过git branch <branch-name>实现，切换通过git checkout <branch-name>或git switch <branch-name>（Git 2.23+引入的更清晰的命令）实现。创建并切换可以通过git checkout -b或git switch -c一步完成。删除已合并的分支使用git branch -d，强制删除未合并分支使用git branch -D。
分支策略是团队协作的规范基础。Git Flow是一种经典的分支模型，定义了五类分支：master（生产分支，仅包含已发布的代码）、develop（开发分支，集成所有开发中的功能）、feature/*（功能分支，从develop创建，完成后合并回develop）、release/*（发布分支，从develop创建，用于发布前的测试和修复，完成后合并到master和develop）、hotfix/*（热修复分支，从master创建，用于紧急修复生产问题，完成后合并到master和develop）。
GitHub Flow是更轻量的分支模型，仅使用master分支和feature分支。所有开发在feature分支上进行，通过Pull Request（PR）进行代码审查后合并到master。这种模型适合持续部署的团队，简化了分支管理的复杂性。Trunk-Based Development（主干开发）则更为激进，所有开发者直接向主干（trunk/master）提交小的、频繁的变更，通过功能开关（Feature Toggles）控制未完成功能的可见性。
合并与变基
合并（Merge）是将不同分支的修改整合到一起的操作。Git支持两种合并方式：快进合并（Fast-Forward Merge）和三路合并（Three-Way Merge）。快进合并发生在目标分支是自当前分支创建以来没有新提交的情况下，Git直接将目标分支指针向前移动到源分支的最新提交，不创建新的合并提交。三路合并发生在两个分支都有新提交时，Git找到两个分支的共同祖先（base），比较三个版本（base、目标分支HEAD、源分支HEAD）的差异，自动合并修改，并创建一个新的合并提交（merge commit），该提交有两个父提交。
合并冲突发生在两个分支对同一文件的同一区域进行了不同的修改，Git无法自动决定采用哪个版本。冲突文件会被标记为未合并状态，文件中包含冲突标记（<<<<<<<、=======、>>>>>>>），分别标示当前分支的修改、分隔符和对方分支的修改。开发者需要手动编辑文件，保留期望的代码，删除冲突标记，然后git add标记冲突已解决，最后完成合并提交。
变基（Rebase）是另一种整合分支修改的方式。它将当前分支的提交"移动"到目标分支的最新提交之上，仿佛这些提交是在目标分支的最新状态上重新进行的。变基通过找到两个分支的共同祖先，提取当前分支的独有提交，在目标分支上逐个"重放"这些提交。变基的结果是一个线性的提交历史，没有合并提交，历史更加整洁。但变基会重写提交历史（生成新的提交对象，拥有新的SHA-1值），因此不应在已推送到共享仓库的提交上执行变基，以免造成协作者的混乱。
交互式变基（git rebase -i）提供了强大的历史编辑能力。它允许在重放提交时执行多种操作：pick（保留提交）、reword（修改提交消息）、edit（暂停以修改提交内容）、squash（将提交合并到前一个提交）、fixup（类似squash但丢弃提交消息）、drop（删除提交）、reorder（调整提交顺序）。交互式变基是清理本地开发历史、合并琐碎提交、修正历史错误的利器。
远程协作
远程仓库（Remote Repository）是托管在网络上的项目副本，团队成员通过推送（Push）和拉取（Pull/Fetch）与远程仓库同步代码。git remote命令管理远程仓库的引用，git remote -v查看已配置的远程仓库及其URL。origin是克隆远程仓库时默认的远程仓库名称。
git fetch从远程仓库下载本地缺失的提交和引用，更新远程跟踪分支（如origin/main），但不合并到当前分支。git pull是git fetch后接git merge的快捷方式，将远程分支的修改合并到当前分支。git push将本地提交上传到远程仓库，更新远程分支指针。推送可能被拒绝（rejected），通常是因为远程仓库有本地没有的提交，此时需要先拉取并合并远程修改。
Pull Request（PR）或Merge Request（MR）是代码审查和协作的核心工作流。开发者完成功能开发后，将本地分支推送到远程仓库，然后在代码托管平台（GitHub、GitLab、Bitbucket等）上发起PR，请求将功能分支合并到目标分支。PR提供了代码差异对比、评论讨论、自动化检查（CI/CD流水线、代码规范检查）和审批流程，是保障代码质量的重要机制。
fork工作流是开源项目常用的协作模式。贡献者fork（复制）官方仓库到自己的账户下，在fork的仓库中自由开发，通过PR向官方仓库提交修改。这种模式使官方仓库的维护者能够完全控制哪些修改被合并，同时允许任何人为项目做出贡献。
历史操作
Git提供了丰富的工具查看和操作提交历史。git log查看提交历史，支持多种格式化选项：--oneline（单行简洁显示）、--graph（图形化显示分支合并历史）、--decorate（显示分支和标签名）、--all（显示所有分支的历史）。git log的筛选选项包括：-n（限制显示数量）、--since/--until（按时间筛选）、--author（按作者筛选）、--grep（按提交消息筛选）、-- path（按修改的文件路径筛选）。
git diff查看工作区、暂存区和提交之间的差异。git diff（不带参数）查看工作区与暂存区的差异；git diff --staged（或--cached）查看暂存区与最新提交的差异；git diff HEAD查看工作区与最新提交的差异；git diff commit1 commit2查看两个提交之间的差异。
撤销操作是日常开发中频繁使用的功能。git restore（Git 2.23+）用于撤销工作区的修改（git restore <file>）或取消暂存（git restore --staged <file>）。git reset用于移动HEAD指针和修改暂存区。--soft模式仅移动HEAD，不修改暂存区和工作区；--mixed模式（默认）移动HEAD并重置暂存区，保留工作区修改；--hard模式移动HEAD并重置暂存区和工作区，丢弃所有修改（需谨慎使用）。git revert通过创建新的提交来撤销指定提交的修改，是安全的公共历史撤销方式，因为它不修改已有历史。
git stash将未提交的修改（包括暂存和未暂存的）保存到一个栈中，使工作区恢复干净状态。这在需要临时切换到其他分支处理紧急任务时非常有用。git stash pop恢复最近的stash并删除它，git stash apply恢复但不删除，git stash list查看stash列表，git stash drop删除指定stash。
工作流规范
良好的Git工作流规范能够显著提升团队协作效率和代码可追溯性。提交消息规范（Commit Message Convention）是最基础的规范之一。Angular规范是广泛采用的提交消息格式：type(scope): subject，其中type包括feat（新功能）、fix（修复）、docs（文档）、style（格式调整）、refactor（重构）、perf（性能优化）、test（测试）、chore（构建/工具）。规范的提交消息使自动生成CHANGELOG、版本号（基于语义化版本控制）和代码审查变得更加高效。
.gitignore文件定义了Git应当忽略的文件模式。应当忽略的内容包括：依赖目录（node_modules/）、构建产物（dist/、build/）、操作系统文件（.DS_Store、Thumbs.db）、IDE配置（.idea/、.vscode/）、环境变量文件（.env、.env.local）、日志文件（*.log）等。忽略已跟踪的文件需要先从索引中移除（git rm --cached），再添加到.gitignore。
Git钩子（Hooks）是在特定Git事件发生时自动执行的脚本，存储在.git/hooks目录下。常用的钩子包括：pre-commit（提交前执行，常用于运行代码检查）、commit-msg（提交消息编辑后执行，常用于验证提交消息格式）、pre-push（推送前执行，常用于运行测试）。Husky是管理Git钩子的流行工具，它将钩子配置纳入版本控制，使团队成员共享相同的钩子设置。
大型仓库的性能优化策略包括：浅克隆（git clone --depth 1，仅克隆最近的历史）、部分克隆（git clone --filter，跳过大型文件）、稀疏检出（sparse-checkout，仅检出部分目录）、Git LFS（Large File Storage，将大文件存储在单独服务器，仓库中仅保存指针）。单一代码库（Monorepo）的管理工具（如Nx、Turborepo、Rush）在大型项目中协调多个包的构建、测试和发布流程。