Git 笔记系列（五）—— Git常用命令-Branch

时间	更新备注
2018-03-01	新建文章
2018-06-08	整理补充
2019-01-18	更新链接
2020-08-09	补充

引言

几乎所有的版本控制系统都以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。在很多版本控制系统中，这是一个略微低效的过程——常常需要完全创建一个源代码目录的副本。对于大项目来说，这样的过程会耗费很多时间。

Git 处理分支的方式可谓是难以置信的轻量，创建新分支这一操作几乎能在瞬间完成，并且在不同分支之间的切换操作也是一样便捷。与许多其它版本控制系统不同，理解和精通Git 分支，你便会意识到 Git 是如此的强大而又独特，并且从此真正改变你的开发方式。

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

Git 的分支也非常轻量。它们只是简单地指向某个提交纪录 —— 仅此而已。所以许多 Git 爱好者传颂：”早建分支！多用分支！”这是因为即使创建再多分的支也不会造成储存或内存上的开销，并且按逻辑分解工作到不同的分支要比维护那些特别臃肿的分支简单多了。

分支的收益

功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支，而不是在master分支上。这个隔离可以方便多个开发者在各自的功能上开发而不会弄乱主干代码。另外，也保证了master分支的代码一定不会是有问题的，极大有利于集成环境。
功能开发隔离也让pull requests工作流成为可能， pull requests工作流能为每个分支发起一个讨论，在分支合入正式项目之前，给其它开发者有表示赞同的机会。另外，如果你在功能开发中有问题卡住了，可以开一个pull requests来向同学们征求建议。这些做法的重点就是，pull requests让团队成员之间互相评论工作变成非常方便！

Git分支的本质

分支图一览

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

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

Git 的分支，其实本质上仅仅是指向提交对象的可变指针。 Git 的默认分支名字是 master。在多次提交操作之后，你其实已经有一个指向最后那个提交对象的 master 分支。它会在每次的提交操作中自动向前移动。
Git 的 “master” 分支并不是一个特殊分支。它就跟其它分支完全没有区别。之所以几乎每一个仓库都有 master 分支，是因为 git init 命令默认创建它，并且大多数人都懒得去改动它。

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

HEAD指针

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

HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。
HEAD 通常情况下是指向分支名的（如 bugFix）。在你提交时，改变了指向分支的状态，这一变化通过 HEAD 变得可见。

HEAD 是当前分支引用的指针，它总是指向该分支上的最后一次提交。这表示 HEAD 将是下一次提交的父结点。通常，理解 HEAD 的最简方式，就是将它看做你的上一次提交的快照。

查看HEAD指针

可以通过以下命令查看HEAD指针

$ cat .git/HEAD
$ git symbolic-ref HEAD

ref: refs/heads/master

分离的 HEAD

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

HEAD 指向 master， master 指向 C1

1	$ git checkout C1

现在变成了

HEAD -> C1

那么这会造成HEAD分离。这是非常危险的，如果你接着添加新的提交，然后切换到别的分支之后就没办法回到之前添加的这些提交。因此，在为分离的HEAD添加新的提交的时候你应该创建一个新的分支。

让分支指向另一个提交

可以直接使用 -f 选项让分支指向另一个提交。例如:

1	git branch -f master HEAD~3

上面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交。这里以 HEAD 作为参考坐标

注意，移动的节点（commits）数是沿着制定分支进行的。

分支创建

Git 创建分支

# 创建本地分支
git branch  <branch-name>
# 创建并且切换到该分支
git checkout -b  <branch-name>
# 创建远程分支
git push <远程主机名> <本地分支名>:<远程分支名>

Git 是怎么创建新分支的呢？很简单，它只是为你创建了一个可以移动的新的指针。比如，创建一个 testing 分支，你需要使用 git branch 命令：

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

新建本地分支，追踪本地分支

1	git checkout --track origin/trackingRemoteBranch

Git 是怎么创建新分支的呢？很简单，它只是为你创建了一个可以移动的新的指针。比如，创建一个 testing 分支，你需要使用 git branch 命令：

1	$ git branch testing

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

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

分支删除

删除本地分支

1
2
3

git branch -d <branchname>
#    -d, --delete          delete fully merged branch
#    -D                    delete branch (even if not merged)

删除远程分支

1 2	git branch -r -d origin/<originBranch> git push origin :<originBranch>

分支查看

查看所有远程分支

1 2	git branch -r git branch -rv

查看所有的本地和远程分支

1	git branch -av

-a 代表所有分支
-a 代表所有分支 + 每个分支的last commit

分支切换

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

1	$ git checkout testing

这样 HEAD 就指向 testing 分支了。

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

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

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

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

1	$ git checkout master

临时性分支

Git里比较强大的以前就是对于分支的管理，在初始化Git的时候，Git会默认创建一条名为master的分支，俗称”主分支”，其实和分支并无不同，在日常开发的过程，master默认是版本开发完成的release分支，然而在迭代开发的过程中，可能有新的功能需求插入以及Bug的修复，这时候，为了保证代码的整洁和功能的完整性，需要开辟新的分支进行管理和开发。一般来说，分支的命名如下：

版本主分支——“Master”
开发分支——“Develop”
功能需求分支——“Feature”
bug修改完善分支——“Fixbug”
预发布分支——“Release”

首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

开发分支：主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。

功能分支：它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

预发布分支：它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。

对于分支开发的详细列表，可以根据自己团队的需求进行合适的调整，这里放上A successful Git branching model的分支开发参考图：

远程分支

远程分支（remote branch）是对远程仓库中的分支的索引。它们是一些无法移动的本地分支；只有在 Git 进行网络交互时才会更新。远程分支就像是书签，提醒着你上次连接远程仓库时上面各分支的位置。

我们用 (远程仓库名)/(分支名) 这样的形式表示远程分支。比如我们想看看上次同 origin 仓库通讯时 master 分支的样子，就应该查看 origin/master 分支。如果你和同伴一起修复某个问题，但他们先推送了一个 iss53 分支到远程仓库，虽然你可能也有一个本地的 iss53 分支，但指向服务器上最新更新的却应该是 origin/iss53 分支。

如果你从远端服务器克隆，Git 会自动为你将此远程仓库命名为 origin，并下载其中所有的数据，建立一个指向它的 master 分支的指针，在本地命名为 origin/master，但你无法在本地更改其数据。接着，Git 建立一个属于你自己的本地 master 分支，始于 origin 上 master 分支相同的位置，你可以就此开始工作

如果你在本地 master 分支做了些改动，与此同时，其他人向 git.ourcompany.com 推送了他们的更新，那么服务器上的 master 分支就会向前推进，而与此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的 origin/master 指针仍然保持原位不会移动（见下图）。

在本地工作的同时有人向远程仓库推送内容会让提交历史开始分流

可以运行 git fetch origin 来同步远程服务器上的数据到本地。该命令首先找到 origin 是哪个服务器（本例为 git.ourcompany.com），从上面获取你尚未拥有的数据，更新你本地的数据库，然后把 origin/master 的指针移到它最新的位置上（见下图）。

git fetch 命令会更新本地数据库中的 remote 索引，指向origin/master的索引和最新的服务器的索引保持同步。

建立追踪关系

新建一个分支，与指定的远程分支建立追踪关系使用命令：

1	$ git branch --track [branch] [remote-branch]

git branch -u upstream/foo
Or, if local branch foo is not the current branch:

git branch -u upstream/foo foo
Or, if you like to type longer commands, these are equivalent to the above two:

git branch --set-upstream-to=upstream/foo

git branch --set-upstream-to=upstream/foo foo
As of Git 1.7.0:

git branch --set-upstream foo upstream/foo

Make an existing Git branch track a remote branch? - Stack Overflow

远程分支的补充

远程分支就是本地分支push到服务器上
提交分支数据到远程服务器

1 2	git push origin <local_branch_name>:<remote_branch_name>

例如：

1	git push origin dev:dev

一般当前如果不在该分支时，使用这种方式提交。如果当前在 dev 分支下，也可以直接提交

git push

分支的合并

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

举个栗子

任何因包含合并冲突而有待解决的文件，都会以未合并状态标识出来。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

这表示 HEAD 所指示的版本(也就是你的 master 分支所在的位置，因为你在运行 merge 命令的时候已经检出到了这个分支)在这个区段的上半部分(======= 的上半部分)，而 iss53 分支所指示的版本在 ======= 的下半部分。为了解决冲突，你必须选择使用由 ======= 分割的两部分中的一个，或者你也可以自行合并这些内容。例如，你可以通过把这段内容换成下面的样子来解决冲突:

1
2
3

 <div id="footer">
please contact us at email.support@github.com
</div>

上述的冲突解决方案仅保留了其中一个分支的修改，并且 <<<<<<< , ======= , 和 >>>>>>> 这些行被完全删除了。在你解决了所有文件里的冲突之后，对每个文件使用git add命令来将其标记为冲突已解决。一旦暂存这些原本有冲突的文件，Git 就会将它们标记为冲突已解决。

撤消合并

假设现在在一个特性分支上工作，不小心将其合并到 master 中，现在提交历史看起来是这样:

修复引用

如果这个不想要的合并提交只存在于你的本地仓库中，最简单且最好的解决方案是移动分支到你想要它指向的地方。大多数情况下，如果你在错误的git merge后运行git reset --hard HEAD~，这会重置分支指向所以它们看起来像这样:

reset –hard通常会经历三步:

移动 HEAD 指向的分支。在本例中，我们想要移动 master 到合并提交(C6)之前所在的位置。
使索引看起来像 HEAD。
使工作目录看起来像索引。

这个方法的缺点是它会重写历史，在一个共享的仓库中这会造成问题的。用简单的话说就是如果其他人已经有你将要重写的提交，你应当避免使用 reset。如果有任何其他提交在合并之后创建了，那么这个方法也会无效; 移动引用实际上会丢失那些改动。

还原提交

如果移动分支指针并不适合你，Git 给你一个生成一个新提交的选项，提交将会撤消一个已存在提交的所有修改。Git 称这个操作为 “还原”，在这个特定的场景下，你可以像这样调用它:

1 2	$ git revert -m 1 HEAD [master b1d8379] Revert "Merge branch 'topic'"

-m 1标记指出“mainline”需要被保留下来的父结点。当你引入一个合并到HEAD(git merge topic)，新提交有两个父结点:第一个是 HEAD(C6)，第二个是将要合并入分支的最新提交(C4)。在本例中，我们想要撤消所有由父结点 #2(C4)合并引入的修改，同时保留从父结点 #1(C4)开始的所有内容。

新的提交 ^M 与 C6 有完全一样的内容，所以从这儿开始就像合并从未发生过，除了“现在还没合并”的提交依
然在 HEAD 的历史中。

常见的分支命令

查看分支列表

1	$ git branch

新建分支

1	$ git branch new_branch_name

切换到分支

1	$ git checkout branch_name

合并支分支到master主分支

1	$ git merge branch_name

删除分支

1	$ git branch -d branch_name

查看远程分支

1	$ git branch -r

查看所有分支

1	$ git branch -a

参考

3.1 Git 分支 - 分支简介