码云有个很好的学习git的东西:https://oschina.gitee.io/learn-git-branching/

笔记如下:

提交代码:commit

git commit

创建新分支

git branch bugfix

这样就创建了一个叫做bugfix的分支

切换分支

git checkout bugfix

切换到bugfix分支上面

创建分支并切换

git checkout -b bugfix

合并分支

在 Git 中合并两个分支时会产生一个特殊的提交记录,它有两个父节点。翻译成自然语言相当于:“我要把这两个父节点本身及它们所有的祖先都包含进来。”

合并前
git merge bugfix

首先,master 现在指向了一个拥有两个父节点的提交记录。假如从 master 开始沿着箭头向上看,在到达起点的路上会经过所有的提交记录。这意味着 master 包含了对代码库的所有修改。

  • 创建新分支 bugFix
  • 用 git checkout bugFix 命令切换到该分支
  • 提交一次
  • 用 git checkout master 切换回 master
  • 再提交一次
  • 用 git merge 把 bugFix 合并到 master

第二种合并分支的方法是 git rebase。Rebase 实际上就是取出一系列的提交记录,“复制”它们,然后在另外一个地方逐个的放下去。

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

git rebase master
git rebase bugfix

现在我们切换到了 master 上。把它 rebase 到 bugFix 分支上……

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

在提交树上移动

我们首先看一下 “HEAD”。 HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。

HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。

HEAD 通常情况下是指向分支名的(如 bugFix)。在你提交时,改变了 bugFix 的状态,这一变化通过 HEAD 变得可见。

分离的 HEAD 就是让其指向了某个具体的提交记录而不是分支名。在命令执行之前的状态如下所示:

HEAD -> master -> C1

HEAD 指向 master, master 指向 C1

git checkout C1

现在变成了

HEAD -> C1

相对引用

通过哈希值指定提交记录很不方便,所以 Git 引入了相对引用。这个就很厉害了!

使用相对引用的话,你就可以从一个易于记忆的地方(比如 bugFix 分支或 HEAD)开始计算。

相对引用非常给力,这里我介绍两个简单的用法:

  • 使用 ^ 向上移动 1 个提交记录
  • 使用 ~<num> 向上移动多个提交记录,如 ~3

首先看看操作符 (^)。把这个符号加在引用名称的后面,表示让 Git 寻找指定提交记录的父提交。

所以 master^ 相当于“master 的父节点”。

git checkout master^

master^^ 是 master 的第二个父节点

“~”操作符

如果你想在提交树中向上移动很多步的话,敲那么多 ^ 貌似也挺烦人的,Git 当然也考虑到了这一点,于是又引入了操作符 ~

该操作符后面可以跟一个数字(可选,不跟数字时与 ^ 相同,向上移动一次),指定向上移动多少次。

强制修改分支位置

使用相对引用最多的就是移动分支。可以直接使用 -f 选项让分支指向另一个提交。例如:

git branch -f master HEAD~3

上面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交。

你也可能喜欢

发表评论