git 命令(基础篇)的本质理解

主要命令

1. 提交,git commit

  • 本质:创建一个节点(node),标志了当前位置(node)与以前的node存在不同之处,如下图中的 c0 <-- c1 <-- c2 等等

    git 命令(基础篇)的本质理解

图中节点保留了上一次提交之后所做的改变

  • 命令:
$ 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。 不能理解为文件夹

    git 命令(基础篇)的本质理解

    上图表示 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 命令(基础篇)的本质理解

执行:

$ git checkout master       ## 切换到要合并的分支
$ git merge bugFix ## 将 bugFix 分支合并到当前分支

合并后: 图中c4 是新产生的特殊记录(merge节点)

git 命令(基础篇)的本质理解

再把master 合并到bugFix分支:如下图

git 命令(基础篇)的本质理解

注意图中两个分支都指向同一个记录节点(上一次的merge节点c4)

  • 命令:

  • 补充:

4. 重指向 ,git rebase destination_branch

  • 本质:git rebase。Rebase 实际上就是取出一系列的提交记录,“复制”它们,然后在另外一个地方逐个的放下去。

Rebase 的优势就是可以创造更线性的提交历史,这听上去有些难以理解。如果只允许使用 Rebase 的话,代码库的提交历史将会变得异常清晰。

背景:还是准备了两个分支;注意当前所在的分支是 bugFix(星号标识的是当前分支),我们想要把 bugFix 分支里的工作直接移到 master 分支上。移动以后会使得两个分支的功能看起来像是按顺序开发,但实际上它们是并行开发的。咱们这次用** git rebase ** 实现此目标。

git 命令(基础篇)的本质理解

$ git rebase master     ## 把bugFix分支  rebase 到目标 master 分支上

效果如下图:

git 命令(基础篇)的本质理解

现在 bugFix 分支上的工作在 master 的最顶端,同时我们也得到了一个更线性的提交序列。

注意,提交记录 C3 依然存在(树上那个半透明的节点),而 C3' 是我们 Rebase 到 master 分支上的 C3 的副本。

现在唯一的问题就是 master 还没有更新,下面咱们就来更新它吧

$ git checkout master         ## 切换到了 master 上。
$ git rebase bugFix ## 把当前分支 rebase 到目标 bugFix 分支上

由于 bugFix 继承自 master,所以 Git 只是简单的把 master 分支的引用向前移动了一下而已。

git 命令(基础篇)的本质理解

  • 命令:
$  git rebase destination_branch      ## 将当前的提交节点,移动到destination_branch 下一节点(新建)
  • 补充:

5. HEAD

  • 本质: HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。HEAD 通常情况下是指向分支名的(如 bugFix)。在你提交时,改变了 bugFix 的状态,这一变化通过 HEAD 变得可见。

比较下面2个图:

图1:(HEAD * 指向 master)

git 命令(基础篇)的本质理解

图2:(HEAD * 指向某次commit:SHA值 630ed6548)

git 命令(基础篇)的本质理解

6. 撤销, git reset HEAD & git revert HEAD

  • 本质1: git reset 通过把分支记录回退几个提交记录来实现撤销改动。你可以将这想象成“改写历史”。git reset 向上移动分支,原来指向的提交记录就跟从来没有提交过一样。

    如图 6.1:

    git 命令(基础篇)的本质理解

执行命令:

$  git reset HEAD~1         ## HEAD 及分支, 从当前位置,向前回退一个节点

如下图 6.2:

git 命令(基础篇)的本质理解

漂亮! Git 把 master 分支移回到 C1;现在我们的本地代码库根本就不知道有 C2 这个提交了。

(注:在reset后, C2 所做的变更还在,但是处于未加入暂存区状态。)

  • 本质2:虽然在你的本地分支中使用 git reset 很方便,但是这种“改写历史”的方法对大家一起使用的远程分支是无效!

    为了撤销更改并分享给别人,我们需要使用 ** git revert **。

前面图 6.1 执行命令之后 ,如下图 6.3

执行命令:

$  git revert HEAD         ## HEAD 及分支master, 从当前位置,向前下新建了一个节点 C2' , 本质上 C2' 是**抵消** C2的操作的。

git 命令(基础篇)的本质理解

注意:在我们要撤销的提交记录后面居然多了一个新提交!这是因为新提交记录 C2' 引入了更改 —— 这些更改刚好是用来撤销 C2 这个提交的。也就是说 C2' 的状态与 C1 是相同的。

revert 之后就可以把你的更改推送到远程仓库与别人分享啦。

上一篇:Ionic3 创建应用(Android)


下一篇:章节三、6-Getters-Setters和this关键字part02