git分支

Git 分支

几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。

Git 的分支非常轻量。它们只是简单地指向某个提交纪录——仅此而已。所以许多 Git 爱好者会念叨：

早点建分支！经常建分支！

创建分支没有储存或内存上的开销，所以按逻辑分解工作比维护单一的代码树要简单。

同时使用分支和提交时，我们会看到两者如何配合。现在，只要记住使用分支其实就是在说：“我想包含本次提交及所有的父提交记录。”

举例  ：建立分支 ： git branch  newImage

   

提交 ：  git commit ： 

master分支前进了，但 newImage 分支没有哇！这是因为我们没有“在”这个新分支上，这也是为什么星号（*）只在 master 上。

使用如下命令告诉 Git 我们想要切换到新的分支

git checkout [name]

这可以让我们在提交修改之前切换到新的分支。

并 git commit ：

我们已经知道怎么提交和使用分支了。接下来要学的一招是如何合并两个不同分支的工作。这让我们可以新建一个分支，在其上开发新功能，然后合并回主线。

git merge 是我们要学习的合并工作的第一个方法。合并产生一个特殊的提交记录，它包含两个唯一父提交。有两个父提交的提交记录本质上是：“我想把这两个父提交本身及它们的父提交集合都包含进来。”

当前有两个分支：各有一个唯一的提交。这意味着没有一个分支包含我们对代码库的所有修改。让我们合并这两个分支来解决这个问题。

我们要把 bugFix 合并到 master

git merge bugFix :

master 现在指向一个拥有两个父提交的提交记录。假如从 master 开始沿着箭头向上游走，在到达起点的路上会经过所有的提交记录。这说明有master 包含了对代码库的所有修改。

现在我们把 master 分支合并到 bugFix 吧。

git checkout bugFix； git merge master ：

因为 bugFix 分支在 master 分支的下游，Git 什么都不用做，只是简单地把 bugfix 分支移动到 master 指向的提交记录。

现在所有的提交记录的颜色都是一样的啦，这表明每一个分支都包含了代码库的所有修改！走起！

Rebasing 是在分支之间合并工作的第二种方法。Rebasing 就是取出一系列的提交记录，"复制"它们，然后把在别的某个地方放下来。

虽然听上去难以理解，rebasing 的优势是可以创造更线性的提交历史。假如只允许使用 rebasing，代码库的提交日志/历史会更好看。

这里，还是有两个分支；注意当前分支是 bugFix（看那颗星）

我们想要把 bugFix 里面的工作直接移到 master 分支上。使用这个方法，两个分支的功能看起来像是按顺序开发，实际上它们是平行开发的。

用 git rebase实现此目标

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

注意，提交记录 C3 仍然存在（阴影的那货就是你了，还看什么看），而我们已经将 C3 复制到了 master。

现在唯一的问题是 master 分支还没有更新…… 下面就来更新它吧

现在，切换到  master  分支。接下来就把它 rebase 到 bugFix  吧……

因为 master 是 bugFix 的下游，所以 git 只把master 分支的记录前移到 bugFix 上。