Git 核心原理与基础使用详解（上）

工作机制：

• 创建 Git 版本库时，Git 会自动创建一个唯一的 master 分支，以及指向 master 的一个指针叫 HEAD。
• 对 work area 修改的文件执行 git add 命令时，暂存区目录树的文件索引会被更新。
• 执行提交操作 git commit 时，master 分支会做相应更新，暂存区的目录树才会被真正写到版本库中。

3.4 添加文件

在包含 .git 的目录下新建文件，可使用 git add 将文件添加到暂存区：

• 添加一个或多个文件：git add [file1] [file2] ...
• 添加指定目录：git add [dir]
• 添加当前目录下所有文件改动：git add .

再使用 git commit 将暂存区内容添加到本地仓库：

• 提交全部内容：git commit -m "message"
• 提交指定文件：git commit [file1] [file2] ... -m "message"

注意：-m 选项后的 message 由用户自己完成，用于记录提交细节。

查看历史提交记录：git log 若嫌输出信息太多，可加上 --pretty=oneline 参数。 每次提交的 commit id 是一个 SHA1 计算出来的十六进制数字。

3.5 查看 .git 文件

.git 目录结构解析：

1. index：暂存区，git add 后会更新该内容。
2. HEAD：默认指向 master 分支的一个指针。
3. refs/heads/master：文件里保存当前 master 分支的最新 commit id。
4. objects：包含了创建的各种版本库对象及内容，存放了 Git 维护的所有修改。

查找 object 时需将 commit id 分成两部分，前 2 位是文件夹名称，后 38 位是文件名称。可使用 git cat-file 命令来查看版本库对象的内容。

3.6 添加文件—场景二

若新增了两个文件 file4 和 file5，但未对 file5 执行 git add，则 git commit 时只会提交 file4。如需提交 file5，需再次 add 并 commit。

3.7 修改文件

Git 跟踪并管理的是修改，而非文件。例如新增一行、删除一行、更改字符等均为修改。

查看当前仓库状态：git status 显示暂存区和工作区文件的差异：git diff [file] 查看版本库和工作区文件的区别：git diff HEAD -- [file]

3.8 版本回退

执行 git reset 命令用于回退版本，语法格式为：

git reset [--soft | --mixed | --hard] [HEAD]

• --mixed（默认）：将暂存区的内容退回为指定提交版本内容，工作区文件保持不变。
• --soft：工作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
• --hard：将暂存区与工作区都退回到指定版本。切记工作区有未提交的代码时不要使用该命令，因为未提交的代码会丢失。

HEAD 说明：

• 可直接写成 commit id。
• HEAD 表示当前版本。
• HEAD^ 上一个版本，HEAD^^ 上上一个版本。
• 也可用 ~ 数字表示，如 HEAD~1 表示上一个版本。

若清屏导致 commit 展示信息消失，可使用 git reflog 命令补救，该命令用来记录本地的每一次命令。

3.9 撤销修改—情况一

针对工作区的代码，还没有 add。 使用 git checkout -- [file] 命令让工作区的文件回到最近一次 add 或 commit 时的状态。注意命令中的 -- 很重要，不可省略。

3.10 撤销修改—情况二

已经 add，但没有 commit。 使用 git reset 回退暂存区的内容，工作区文件保持不变。随后丢弃工作区的修改。

3.11 撤销修改—情况三

已经 add，并且也 commit 了。 使用 git reset --hard HEAD^ 回退到上一个版本。前提是尚未把本地版本库推送到远程。

3.12 删除文件

在 Git 中，删除也是一个修改操作。 若直接在工作区删除文件，需使用 git rm 将文件从暂存区和工作区中删除，并且 commit。 若误删，可使用 git checkout -- [file] 恢复。

4. 分支管理

4.1 理解分支

分支就是科幻电影里的平行宇宙。在版本回退里，每次提交，Git 都把它们串成一条时间线，这条时间线就可以理解为一个分支。截止到目前，只有一条时间线，即 master 分支。

HEAD 严格来说不是指向提交，而是指向 master，master 才是指向提交的，所以 HEAD 指向的就是当前分支。

4.2 创建、切换、合并分支

1. 创建分支：git branch dev
2. 切换分支：git checkout dev 切换到 dev 分支后，HEAD 指向 dev。在 dev 分支下修改并提交后，切回 master 分支，发现新内容不见了，因为 master 的提交点并未改变。
3. 合并分支：git merge dev 将 dev 分支合并到当前分支。Fast-forward 代表'快进模式'，直接把 master 指向 dev 的当前提交。

4.3 删除分支

合并完成后，dev 分支若无用可删除。注意如果当前正处于某分支下，就不能删除当前分支。 命令：git branch -d dev

4.4 合并冲突

在实际分支合并时，可能会遇到代码冲突。 Git 会用 <<<<<<<, =======, >>>>>>> 来标记出不同分支的冲突内容。此时必须手动调整冲突代码，并再次提交修正后的结果。

4.5 分支模式

通常合并分支时，如果可能，Git 会采用 Fast forward 模式。但这会导致分支历史信息丢失。 Git 支持强制禁用 Fast forward 模式，使用 --no-ff 参数。这样在 merge 时会生成一个新的 commit，从分支历史上可以看出分支信息。

4.6 分支策略

实际开发中的基本原则：

• master 分支应该是稳定的，仅用来发布新版本，平时不能在上面干活。
• 干活都在 dev 分支上，dev 分支是不稳定的。到某个时候（如 1.0 版本发布），再把 dev 分支合并到 master 上。
• 团队成员每个人都有自己的分支，时不时往 dev 分支上合并。

4.7 Bug 分支

假如正在开发中发现 master 上有 bug，需要修复。 每个 bug 都可以通过一个新的临时分支来修复，修复后合并分支，然后删除临时分支。 若当前工作区有未提交的代码，可使用 git stash 命令将当前工作区信息进行储藏。 恢复现场：git stash pop（恢复的同时会把 stash 也删了）。 建议在自己分支上先合并 master，再让 master 去合并自己的分支，以便在本地解决冲突。

4.8 删除临时分支

每添加一个新功能，最好新建一个 feature 分支，开发完成后合并，最后删除该 feature 分支。 若中途停止开发，可使用 git branch -d 删除分支。

分支的实际用途： 假设准备开发一个新功能，需要两周完成。第一周写了 50% 的代码，如果立即提交，不完整的代码库会影响他人；如果等写完再提交，存在丢失每天进度的风险。有了分支，可以在自己的分支上干活，想提交就提交，直到开发完毕后一次性合并到原来的分支上，既安全又不影响别人工作。