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                                     ## 浏览所有分支， 当前工作分支 前面会有 * 号

• 补充：分支不能理解为文件夹，

1. 可以理解为虚拟文件夹
2. 该虚拟文件夹中，存放了自分支创建以来所有的改变
3. 该分支 commit之后，这个改变就固定下来（对应与 commit的节点）
4. 多个分支合并（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 之后就可以把你的更改推送到远程仓库与别人分享啦。