Git分支

Git分支

分支简介

Git 保存的不是文件的变化或者差异，而是一系列不同时刻的 快照 。

在进行提交操作时，Git 会保存一个提交对象(commit object)。 知道了 Git 保存数据的方式，我们可以很自然的想到——该提交对象会包含一个指向暂存内容快照的指针。 但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。 首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象， 而由多个分支合并产生的提交对象有多个父对象，

为了更加形象地说明，我们假设现在有一个工作目录，里面包含了三个将要被暂存和提交的文件。暂存操作会 为每一个文件计算校验和(使用我们在 起步 中提到的 SHA-1 哈希算法)，然后会把当前版本的文件快照保存到Git 仓库中 (Git 使用 blob 对象来保存它们)，最终将校验和加入到暂存区域等待提交:

$ git add README test.rb LICENSE

当使用 git commit 进行提交操作时，Git 会先计算每一个子目录(本例中只有项目根目录)的校验和， 然后在 Git 仓库中这些校验和保存为树对象。随后，Git 便会创建一个提交对象， 它除了包含上面提到的那些信息外，还包含指向这个树对象(项目根目录)的指针。 如此一来，Git 就可以在需要的时候重现此次保存的快照。

现在，Git 仓库中有五个对象:三个 blob 对象(保存着文件快照)、一个 树 对象 (记录着目录结构和 blob 对 象索引)以及一个 提交 对象(包含着指向前述树对象的指针和所有提交信息)。

image-20200801203920438.png

做些修改后再次提交，那么这次产生的提交对象会包含一个指向上次提交对象(父对象)的指针。

2.png

Git 的分支，其实本质上仅仅是指向提交对象的可变指针。 Git 的默认分支名字是 master。 在多次提交操作之 后，你其实已经有一个指向最后那个提交对象的 master 分支。 master 分支会在每次提交时自动向前移动。

Git 的 master 分支并不是一个特殊分支。 它就跟其它分支完全没有区别。 之所以几乎每一个仓库都有master分支，是因为git init命令默认创建它，并且大多数人都懒得去改动它。

3.png

分支创建:

$ git branch testing

这会在当前所在的提交对象上创建一个指针。

4.png

那么，Git 又是怎么知道当前在哪一个分支上呢? 也很简单，它有一个名为 HEAD 的特殊指针。 请注意它和许多其它版本控制系统(如 Subversion 或 CVS)里的 HEAD 概念完全不同。 在 Git中，它是一个指针，指向当前所在的<u style="box-sizing: border-box;">本地分支</u>(译注:将 HEAD 想象为当前分支的别名)。 在本例中，你仍然在master 分支上。 因为 git branch 命令仅仅 创建 一个新分支，并不会自动切换到新分支中去。在本例中，你仍然在master 分支上。 因为 git branch 命令仅仅 创建 一个新分支，并不会自动切换到新分支中去。

5.png

分支切换:

要切换到一个已存在的分支，你需要使用 git checkout 命令。 我们现在切换到新创建的 testing 分支去:

$ git checkout testing

这样 HEAD 就指向 testing 分支了。

6.png

那么，这样的实现方式会给我们带来什么好处呢? 现在不妨再提交一次:

$ vim test.rb
$ git commit -a -m 'made a change'

7.png

HEAD 一直指向本地当前所在分之，可以说是当前分之的别名，而 在当前分之有新记录提交后，testing当前分之会指向最新的提交对象；而mater 等其他分支则还指向提交之前指向的对象。

如图所示，你的testing分支向前移动了，但是master分支却没有，它仍然指向运行git checkout时所指的对象。 这就有意思了，现在我们切换回 master 分支看看:

$ git checkout master

8.png

这条命令做了两件事。 一是使 HEAD 指回 master 分支，二是将工作目录恢复成 master 分支所指向的快照内容。 也就是说，你现在做修改的话，项目将始于一个较旧的版本。 本质上来讲，这就是忽略 testing 分支所做的修改，以便于向另一个方向进行开发。

分支切换会改变你工作目录中的文件

在切换分支时，一定要注意你工作目录里的文件会被改变。 如果是切换到一个较旧的分支，你的工作目录会恢复到该分支最后一次提交时的样子。 如果 Git 不能干净利落地完成这个任务，它将禁止切换分支。

我们不妨再稍微做些修改并提交:

  $ vim test.rb 
  $ git commit -a -m 'made other changes'

现在，这个项目的提交历史已经产生了分叉。 因为刚才你创建了一个新分支，并切换过去进行了一些工作，随后又切换回 master 分支进行了另外一些工作。 上述两次改动针对的是不同分支:你可以在不同分支间不断地来回切换和工作，并在时机成熟时将它们合并起来。 而所有这些工作，你需要的命令只有branch、checkout 和 commit。

9.png

由于 Git 的分支实质上仅是包含所指对象校验和(长度为 40 的 SHA-1 值字符串)的文件，所以它的创建和销毁都异常高效。 创建一个新分支就相当于往一个文件中写入 41 个字节(40 个字符和 1 个换行符)，如此的简单能不快吗?

这与过去大多数版本控制系统形成了鲜明的对比，它们在创建分支时，将所有的项目文件都复制一遍，并保存到一个特定的目录。 完成这样繁琐的过程通常需要好几秒钟，有时甚至需要好几分钟。所需时间的长短，完全取决于项目的规模。 而在 Git 中，任何规模的项目都能在瞬间创建新分支。 同时，由于每次提交都会记录父对象，所以寻找恰当的合并基础(译注:即共同祖先)也是同样的简单和高效。 这些高效的特性使得 Git 鼓励开发人员频繁地创建和使用分支。

创建新分支的同时切换过去

通常我们会在创建一个新分支后立即切换过去，这可以用一条命令搞定。

git checkout -b <newbranchname> 

分支的新建与合并

新建分支

首先，我们假设你正在你的项目上工作，并且在 master 分支上已经有了一些提交。

10.png

现在，你已经决定要解决你的公司使用的问题追踪系统中的 #53 问题。 想要新建一个分支并同时切换到那个分 支上，你可以运行一个带有-b参数的git checkout命令:

新建分支 iss53 并立即切换过去

$ git checkout -b iss53

等价于：

$ git branch iss53
$ git checkout iss53

11.png

你继续在 #53 问题上工作，并且做了一些提交。 在此过程中，iss53 分支在不断的向前推进，因为你已经检出 到该分支 (也就是说，你的 HEAD 指针指向了 iss53 分支)

 $ vim index.html 
  $ git commit -a -m 'added a new footer [issue 53]'

12.png

现在你接到那个电话，有个紧急问题等待你来解决。 有了 Git 的帮助，你不必把这个紧急问题和 iss53 的修改混在一起， 你也不需要花大力气来还原关于 53# 问题的修改，然后再添加关于这个紧急问题的修改，最后将这个修改提交到线上分支。 你所要做的仅仅是切换回 master 分支。

但是，在你这么做之前，要留意你的工作目录和暂存区里那些还没有被提交的修改， 它可能会和你即将检出的分支产生冲突从而阻止 Git 切换到该分支。 最好的方法是，在你切换分支之前，保持好一个干净的状态。 有一些方法可以绕过这个问题(即，暂存(stashing) 和 修补提交(commit amending))

$ git checkout master

这个时候，你的工作目录和你在开始 #53 问题之前一模一样，现在你可以专心修复紧急问题了。 请牢记:当你切换分支的时候，Git 会重置你的工作目录，使其看起来像回到了你在那个分支上最后一次提交的样子。 Git 会自动添加、删除、修改文件以确保此时你的工作目录和这个分支最后一次提交时的样子一模一样。

接下来，你要修复这个紧急问题。 我们来建立一个 hotfix 分支，在该分支上工作直到问题解决:

$ git checkout -b hotfix
$ vim index.html
$ git commit -a -m 'fixed the broken email address'

13.png

你可以运行你的测试，确保你的修改是正确的，然后将 hotfix 分支合并回你的 master 分支来部署到线上。 你可以使用git merge命令来达到上述目的:

 $ git checkout master
  $ git merge hotfix

由于你想要合并的分支 hotfix 所指向的提交 C4 是你所在的提交 C2 的直接后继， 因此 Git 会直接将指针向前移动。换句话说，当你试图合并两个分支时， 如果顺着一个分支走下去能够到达另一个分支，那么 Git 在合并两者的时候， 只会简单的将指针向前推进(指针右移)，因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进(fast-forward)”。

14.png

关于这个紧急问题的解决方案发布之后，你准备回到被打断之前时的工作中。 然而，你应该先删除 hotfix 分支，因为你已经不再需要它了 —— master 分支已经指向了同一个位置。 你可以使用带 -d 选项的 git branch 命令来删除分支:

$ git branch -d hotfix

现在你可以切换回你正在工作的分支继续你的工作，也就是针对 #53 问题的那个分支(iss53 分支)。

  $ git checkout iss53
  $ vim index.html
  $ git commit -a -m 'finished the new footer [issue 53]'

15.png

你在 hotfix 分支上所做的工作并没有包含到 iss53 分支中。 如果你需要拉取 hotfix 所做的修改，你可以使用git merge master命令将master分支合并入iss53分支，或者你也可以等到iss53分支完成其使命，再将其合并回 master 分支。

分支的合并

假设你已经修正了 #53 问题，并且打算将你的工作合并入 master 分支。 为此，你需要合并 iss53 分支到master 分支，这和之前你合并 hotfix 分支所做的工作差不多。 你只需要检出到你想合并入的分支，然后运行git merge命令:

$ git checkout master
$ git merge iss53

这和你之前合并 hotfix 分支的时候看起来有一点不一样。 在这种情况下，你的开发历史从一个更早的地方开始分叉开来(diverged)。 因为，master 分支所在提交并不是 iss53 分支所在提交的直接祖先，Git 不得不做一些额外的工作。 出现这种情况的时候，Git 会使用两个分支的末端所指的快照(C4 和 C5)以及这两个分支的公共祖先(C2)，做一个简单的三方合并。

16.png

和之前将分支指针向前推进所不同的是，Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提 交指向它。 这个被称作一次合并提交，它的特别之处在于他有不止一个父提交。

17.png

遇到冲突时的分支合并

有时候合并操作不会如此顺利。 如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们。 如果你对 #53 问题的修改和有关 hotfix 分支的修改都涉及到同一个文件的同一处，在合并它们的时候就会产生合并冲突:

此时 Git 做了合并，但是没有自动地创建一个新的合并提交。 Git 会暂停下来，等待你去解决合并产生的冲突。你可以在合并冲突后的任意时刻使用git status命令来查看那些因包含合并冲突而处于未合并(unmerged)状态的文件:

任何因包含合并冲突而有待解决的文件，都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记，这样你可以打开这些包含冲突的文件然后手动解决冲突。 出现冲突的文件会包含一些特殊区段，看起来像下面这个样子:

 <<<<<<< HEAD:index.html
  <div id="footer">contact : email.support@github.com</div>
  =======
  <div id="footer">
   please contact us at support@github.com
  </div>
  >>>>>>> iss53:index.html

在你解决了所有文件里的冲突之后，对每个文件使用 git add 命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件，Git 就会将它们标记为冲突已解决。

你可以再次运行git status来确认所有的合并冲突都已被解决:

如果你对结果感到满意，并且确定之前有冲突的的文件都已经暂存了，这时你可以输入git commit来完成合并提交。

分支管理

git branch 命令不只是可以创建与删除分支。 如果不加任何参数运行它，会得到当前所有分支的一个列表:

$ git branch
    iss53
  * master
    testing

注意 master 分支前的 * 字符:它代表现在检出的那一个分支(也就是说，当前 HEAD 指针所指向的分支)。这意味着如果在这时候提交，master 分支将会随着新的工作向前移动。 如果需要查看每一个分支的最后一次提交，可以运行git branch -v命令:

$ git branch -v
    iss53   93b412c fix javascript issue
  * master  7a98805 Merge branch 'iss53'
    testing 782fd34 add scott to the author list in the readmes

--merged 与 --no-merged 这两个有用的选项可以过滤这个列表中已经合并或尚未合并到当前分支的分支。如果要查看哪些分支已经合并到当前分支，可以运行git branch --merged:

$ git branch --merged
    iss53
    * master 

因为之前已经合并了 iss53 分支，所以现在看到它在列表中。 在这个列表中分支名字前没有 * 号的分支通常可以使用git branch -d删除掉;你已经将它们的工作整合到了另一个分支，所以并不会失去任何东西。

查看所有包含未合并工作的分支，可以运行git branch --no-merged:

$ git branch --no-merged
testing

这里显示了其他分支。 因为它包含了还未合并的工作，尝试使用 git branch -d 命令删除它时会失败:

$ git branch -d testing
  error: The branch 'testing' is not fully merged.
  If you are sure you want to delete it, run 'git branch -D testing'.

你总是可以提供一个附加的参数来查看其它分支的合并状态而不必检出它们。 例如，尚未合 并到 master 分支的有哪些?

$ git checkout testing
             $ git branch --no-merged master
               topicA
               featureB

这个命令比较有意思可以在当前分之查看其他分支未合并到查看分支或已合并到查看分支的分支信息

长期分支

许多使用 Git 的开发者都喜欢使用这种方式来工作，比如只在 master 分支上保留完全稳定的代码——有可能仅仅是已经发布或即将发布的代码。 他们还有一些名为 develop 或者 next 的平行分支，被用来做后续开发或者测试稳定性——这些分支不必保持绝对稳定，但是一旦达到稳定状态，它们就可以被合并入 master 分支了。 这样，在确保这些已完成的主题分支(短期分支，比如之前的 iss53 分支)能够通过所有测试，并且不会引入更多 bug 之后，就可以合并入主干分支中，等待下一次的发布。

事实上我们刚才讨论的，是随着你的提交而不断右移的指针。 稳定分支的指针总是在提交历史中落后一大截，而前沿分支的指针往往比较靠前。

18.png 19.png

你可以用这种方法维护不同层次的稳定性。 一些大型项目还有一个 proposed(建议) 或 pu: proposedupdates(建议更新)分支，它可能因包含一些不成熟的内容而不能进入 next 或者 master 分支。 这么做的目的是使你的分支具有不同级别的稳定性;当它们具有一定程度的稳定性后，再把它们合并入具有更高级别稳定性的分支中。 再次强调一下，使用多个长期分支的方法并非必要，但是这么做通常很有帮助，尤其是当你在一个非常庞大或者复杂的项目中工作时。

主题分支

主题分支对任何规模的项目都适用。 主题分支是一种短期分支，它被用来实现单一特性或其相关工作。

考虑这样一个例子，你在 master 分支上工作到 C1，这时为了解决一个问题而新建 iss91 分支，在 iss91 分支上工作到 C4，然而对于那个问题你又有了新的想法，于是你再新建一个 iss91v2 分支试图用另一种方法解决那个问题，接着你回到 master 分支工作了一会儿，你又冒出了一个不太确定的想法，你便在 C10 的时候新建一个 dumbidea 分支，并在上面做些实验。 你的提交历史看起来像下面这个样子:

20.png

请牢记，当你做这么多操作的时候，这些分支全部都存于本地。 当你新建和合并分支的时候，所有这一切都只 发生在你本地的 Git 版本库中 —— 没有与服务器发生交互。

远程分支

远程引用是对远程仓库的引用(指针)，包括分支、标签等等。

21.png

如果你在本地的 master 分支做了一些工作，在同一段时间内有其他人推送提交到 git.ourcompany.com并且更新了它的 master 分支，这就是说你们的提交历史已走向不同的方向。 即便这样，只要你保持不与origin 服务器连接(并拉取数据)，你的 origin/master 指针就不会移动。

22.png

如果要与给定的远程仓库同步数据，运行git fetch <remote>命令(在本例中为git fetch origin)。这个命令查找 “origin” 是哪一个服务器(在本例中，它是 git.ourcompany.com)， 从中抓取本地没有的数据，并且更新本地数据库，移动 origin/master 指针到更新之后的位置。

23.png

拉取固定分支最新代码到本地 git fetch teaming

24.png 25.png

拉取固定分支最新代码到本地 git fetch teaming

推送

当你想要公开分享一个分支时，需要将其推送到有写入权限的远程仓库上。 本地的分支并不会自动与远程仓库 同步——你必须显式地推送想要分享的分支。 这样，你就可以把不愿意分享的内容放到私人分支上，而将需要和 别人协作的内容推送到公开分支。

如果希望和别人一起在名为serverfix的分支上工作，你可以像推送第一个分支那样推送它。运行git push <remote> <branch>:

拉取

当 git fetch 命令从服务器上抓取本地没有的数据时，它并不会修改工作目录中的内容。 它只会获取数据然后让你自己合并。 然而，有一个命令叫作 git pull 在大多数情况下它的含义是一个 git fetch 紧接着一个git merge 命令。 如果有一个像之前章节中演示的设置好的跟踪分支，不管它是显式地设置还是通过 clone或checkout命令为你创建的，git pull都会查找当前分支所跟踪的服务器与分支，从服务器上抓取数据然后尝试合并入那个远程分支。

变基

在 Git 中整合来自不同分支的修改主要有两种方法:merge 以及 rebase。 在本节中我们将学习什么是“变基”，怎样使用“变基”，并将展示该操作的惊艳之处，以及指出在何种情况下你应避免使用它。

变基的基本操作

请回顾之前在 分支的合并 中的一个例子，你会看到开发任务分叉到两个不同分支，又各自提交了更新。

26.png

之前介绍过，整合分支最容易的方法是 merge 命令。 它会把两个分支的最新快照(C3 和 C4)以及二者最近的 共同祖先(C2)进行三方合并，合并的结果是生成一个新的快照(并提交)。

27.png

其实，还有一种方法:你可以提取在 C4 中引入的补丁和修改，然后在 C3 的基础上应用一次。 在 Git 中，这种操作就叫做 变基(rebase)。 你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。

在这个例子中，你可以检出 experiment 分支，然后将它变基到 master 分支上:

 $ git checkout experiment
 $ git rebase master

它的原理是首先找到这两个分支(即当前分支 experiment、变基操作的目标基底分支 master) 的最近共同祖先 C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件， 然后将当前分支指向目标基底 C3, 最后以此将之前另存为临时文件的修改依序应用。 (译注:写明了 commit id，以便理解，下同)

28.png

现在回到 master 分支，进行一次快进合并。

$ git checkout master
$ git merge experiment

29.png

更有趣的变基例子

在对两个分支进行变基时，所生成的“重放”并不一定要在目标分支上应用，你也可以指定另外的一个分支进行应用。 就像 从一个主题分支里再分出一个主题分支的提交历史 中的例子那样。 你创建了一个主题分支server，为服务端添加了一些功能，提交了 C3 和 C4。 然后从 C3 上创建了主题分支 client，为客户端添加了一些功能，提交了 C8 和 C9。 最后，你回到 server 分支，又提交了 C10。

30.png

假设你希望将 client 中的修改合并到主分支并发布，但暂时并不想合并 server 中的修改， 因为它们还需要经过更全面的测试。这时，你就可以使用git rebase命令的--onto选项，选中在client分支里但不在server 分支里的修改(即 C8 和 C9)，将它们在 master 分支上重放:

$ git rebase --onto master server client

以上命令的意思是:“取出 client 分支，找出它从 server 分支分歧之后的补丁， 然后把这些补丁在master 分支上重放一遍，让 client 看起来像直接基于 master 修改一样”。这理解起来有一点复杂，不过效果非常酷。

31.png

现在可以快进合并 master 分支了。(如图 快进合并 master 分支，使之包含来自 client 分支的修改):

$ git checkout master
$ git merge client

32.png

接下来你决定将 server 分支中的修改也整合进来。 使用 git rebase <basebranch> <topicbranch> 命令可以直接将主题分支 (即本例中的 server)变基到目标分支(即 master)上。 这样做能省去你先切换到server 分支，再对其执行变基命令的多个步骤。

$ git rebase master server

如图 将 server 中的修改变基到 master 上 所示，server 中的代码被“续”到了 master 后面。

33.png

然后就可以快进合并主分支 master 了:

$ git checkout master
$ git merge server