git 命令(基础篇)的本质理解
主要命令
1. 提交，git commit
- 本质：创建一个节点（node），标志了当前位置（node）与以前的node存在不同之处，如下图中的 c0 <-- c1 <-- c2 等等
图中节点保留了上一次提交之后所做的改变
- 命令：
$ git commit -m "comments" ## comments 是对当前提交的注解，备注
- 补充：git commit 产生的节点会分配SHA 唯一的hash值，可以用git format-patch 命令提出。
## git 依据SHA值 (部分SHA值也是可以的，如前7位 ) 提取文件patch
$ git format-patch -M master ## 当前分支所有超前master的提交
$ git format-patch -s SHA值 ## 此SHA值提交以后的所有PATCH
$ git format-patch -1 SHA值 ## 此SHA值的提交patch
$ git format-patch -n ## 从master售前n个提交的内容
$ git format-patch -n SHA值 ## 从SHA值开始(含SHA值当次)之前的N次提交
2. 分支 ，git branch
-
本质：类似指针，指向最近提交的node。 不能理解为文件夹
上图表示 master 分支指向 c1 提交commit -
命令：
1. 创建分支
$ git branch new_branch ## 创建了分支名称为new_branch，工作指针停留在当前分支
2. 切换分支
$ git checkout new_branch ## 工作指针切换到已有分支new_branch
3. 创建分支
$ git checkout -b new_branch ## 创建了分支名称为new_branch，工作指针切换到新的分支
4. 浏览分支
$ git branch ## 浏览所有分支， 当前工作分支 前面会有 * 号
- 补充：分支不能理解为文件夹，
- 可以理解为虚拟文件夹
- 该虚拟文件夹中，存放了自分支创建以来所有的改变
- 该分支 commit之后，这个改变就固定下来（对应与 commit的节点）
- 多个分支合并（merge）是将多个分支不同的部分合并到其中的一个分支。
3. 分支 ，git merge
- 本质：在 Git 中合并两个分支时会产生一个特殊的提交记录，它有两个父节点。翻译成自然语言相当于：“我要把这两个父节点本身及它们所有的祖先都包含进来。”
合并前：
执行：
$ git checkout master ## 切换到要合并的分支
$ git merge bugFix ## 将 bugFix 分支合并到当前分支
合并后： 图中c4 是新产生的特殊记录（merge节点）
再把master 合并到bugFix分支：如下图
注意图中两个分支都指向同一个记录节点（上一次的merge节点c4）
-
命令：
-
补充：
4. 重指向 ，git rebase destination_branch
- 本质：git rebase。Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。
Rebase 的优势就是可以创造更线性的提交历史，这听上去有些难以理解。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。
背景：还是准备了两个分支；注意当前所在的分支是 bugFix（星号标识的是当前分支），我们想要把 bugFix 分支里的工作直接移到 master 分支上。移动以后会使得两个分支的功能看起来像是按顺序开发，但实际上它们是并行开发的。咱们这次用** git rebase ** 实现此目标。
$ git rebase master ## 把bugFix分支 rebase 到目标 master 分支上
效果如下图：
现在 bugFix 分支上的工作在 master 的最顶端，同时我们也得到了一个更线性的提交序列。
注意，提交记录 C3 依然存在（树上那个半透明的节点），而 C3' 是我们 Rebase 到 master 分支上的 C3 的副本。
现在唯一的问题就是 master 还没有更新，下面咱们就来更新它吧
$ git checkout master ## 切换到了 master 上。
$ git rebase bugFix ## 把当前分支 rebase 到目标 bugFix 分支上
由于 bugFix 继承自 master，所以 Git 只是简单的把 master 分支的引用向前移动了一下而已。
- 命令：
$ git rebase destination_branch ## 将当前的提交节点，移动到destination_branch 下一节点（新建）
- 补充：
5. HEAD
- 本质： HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。HEAD 通常情况下是指向分支名的（如 bugFix）。在你提交时，改变了 bugFix 的状态，这一变化通过 HEAD 变得可见。
比较下面2个图：
图1：（HEAD * 指向 master）
图2：（HEAD * 指向某次commit：SHA值 630ed6548）
6. 撤销， git reset HEAD & git revert HEAD
- 本质1： git reset 通过把分支记录回退几个提交记录来实现撤销改动。你可以将这想象成“改写历史”。git reset 向上移动分支，原来指向的提交记录就跟从来没有提交过一样。
如图 6.1：
执行命令：
$ git reset HEAD~1 ## HEAD 及分支， 从当前位置，向前回退一个节点
如下图 6.2：
漂亮! Git 把 master 分支移回到 C1；现在我们的本地代码库根本就不知道有 C2 这个提交了。
（注：在reset后， C2 所做的变更还在，但是处于未加入暂存区状态。）
- 本质2：虽然在你的本地分支中使用 git reset 很方便，但是这种“改写历史”的方法对大家一起使用的远程分支是无效！
为了撤销更改并分享给别人，我们需要使用 ** git revert **。
前面图 6.1 执行命令之后 ，如下图 6.3
执行命令：
$ git revert HEAD ## HEAD 及分支master， 从当前位置，向前下新建了一个节点 C2' , 本质上 C2' 是**抵消** C2的操作的。
注意：在我们要撤销的提交记录后面居然多了一个新提交！这是因为新提交记录 C2' 引入了更改 —— 这些更改刚好是用来撤销 C2 这个提交的。也就是说 C2' 的状态与 C1 是相同的。
revert 之后就可以把你的更改推送到远程仓库与别人分享啦。
