一、Git的基本构成
Git 是一种分布式版本控制系统，其核心思想是"内容寻址文件系统"，这意味着它以一种高效、不可变的方式存储数据。从底层原理来看，Git 的所有操作都围绕着四种核心对象：blob （存储文件内容）、tree （表示目录结构）、commit （记录提交元数据）和 tag（用于标记特定提交）。
当你执行 git add 时，Git 会为每个修改的文件生成一个 blob 对象，并将其内容哈希值记录在暂存区 （index）文件中。接着，git commit 会依据暂存区的内容，创建一个 tree 对象来表示当前目录快照，然后生成一个commit 对象，这个对象包含了指向 tree 对象的哈希值、作者信息、提交信息以及其父提交的哈希，从而形成一个不可变的提交链。这个链条就是我们所看到的项目历史。
二、Git 的工作区、暂存区与仓库
理解 Git ，必须先理清它管理的三个区域：工作区 、暂存区 和本地仓库。
工作区 是你实际编写代码的目录，其中的文件可能处于未跟踪、已修改或已暂存状态。暂存区 （Staging Area）则是一个中间地带，它允许你精确地选择哪些文件或哪些修改应该被包含在下一次提交中。你使用 git add 命令将工作区的修改转移到暂存区，这个操作并不会立即创建提交，而是准备好一个待提交的"快照"。最后，git commit 将暂存区的内容保存到本地仓库，生成一个永久的提交对象，并更新当前分支的指针使其指向这个新提交。这种三区模型给了开发者极大的灵活性，可以精细地管理每一次提交的内容。
三、Merge 与 Rebase 的项目应用与区别
在多人协作中，git merge 和 git rebase 是两种截然不同的分支合并策略。Merge 通过创建一个新的合并提交"来整合两个分支，它完整地保留了分支分叉和合并的历史，形成一个非线性的、树状的提交图。这种方式简单、安全，特别适合在团队协作中集成已共享的分支，因为它不会改变已有的提交历史，避免了潜在的冲突和混乱。
而 Rebase 则是一种 "历史重写"的操作，它将你的本地提交"移动"到目标分支的末尾，从而创建一个线性的、干净的提交历史。Rebase 适用于个人在推送到远程之前整理本地分支，以保持提交记录的简洁， 但切记不要对已共享的公共分支执行 rebase，否则会造成历史分歧，引发协作灾难。
一个最佳实践是：在个人本地分支上，用 rebase 同步公共分支的最新代码，保持自己分支的整洁；在将功能分支合并到公共分支时，使用 git merge --no-ff，强制创建一个合并提交作为"里程碑"，清晰地标记一个完整功能的集成点，这极大地增强了历史的可读性，并为日后回滚提供了方便。
四、Git 常用命令与实战场景
掌握 Git 的工作流，离不开对常用命令的熟练运用。
git clone 用于从远程仓库克隆项目到本地。日常开发中，我们通常会使用 git checkout -b 创建并切换到新的功能分支。
在完成工作后，git add . 和 git commit -m 用于将修改提交到本地仓库。为了同步远程更新，我们会使用 git pull，它其实是 git fetch 和 git merge 的组合，拉取远程更新并自动合并到本地分支。
如果需要撤销操作，git reset 是一个强大的工具，它有 --soft、--mixed 和 --hard 三种模式，可以让你在不同程度上撤销提交，但要小心使用 --hard，因为它会永久删除工作区修改。
git status : 查看工作区和暂存区的状态，了解哪些文件已修改、已暂存或未跟踪。git log : 查看提交历史，可以配合 --oneline 、--graph 等参数来简化输出或以图形方式展示分支历史。git diff : 对比文件差异，git diff 查看工作区与暂存区的差异，git diff --staged 查看暂存区与最新提交的差异。git reflog : 这个命令至关重要，它记录了你本地仓库中所有 HEAD 指针的变动历史，可以被视为 Git 的"后悔药" 。无论你执行了 reset、rebase 还是其他任何操作，只要 HEAD 移动了，git reflog 就会记录下来。当你错误地执行了 git reset --hard 并删除了重要提交时，你可以通过 git reflog 找到之前的 HEAD 状态，并使用 git reset HEAD@{...} 来恢复。
在 Android Studio 中，这些命令都有对应的图形化界面操作，使得 Git 管理变得更加直观。例如，通过 VCS 菜单，你可以轻松地启用版本控制、提交代码、推送到远程仓库，甚至通过右键菜单执行撤销操作，这些都极大地简化了 Git 的学习曲线，让开发者可以更高效地进行版本控制。