Git 分支

Git 分支

几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分

离开来，然后在不影响主线的同时继续工作。在很多版本控制系统中，这是个昂贵的过程，

常常需要创建一个源代码目录的完整副本，对大型项目来说会花费很长时间。

有人把Git 的分支模型称为“必杀技特性”，而正是因为它，将Git 从版本控制系统家

族里区分出来。Git 有何特别之处呢？Git 的分支可谓是难以置信的轻量级，它的新建操作

几乎可以在瞬间完成，并且在不同分支间切换起来也差不多一样快。和许多其他版本控制系

统不同，Git 鼓励在工作流程中频繁使用分支与合并，哪怕一天之内进行许多次都没有关

系

 

何谓分支

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

在Git 中提交时，会保存一个提交（commit）对象，它包含一个指向暂存内容快照的指

针，作者和相关附属信息，以及一定数量（也可能没有）指向该提交对象直接祖先的指针：

第一次提交是没有直接祖先的，普通提交有一个祖先，由两个或多个分支合并产生的提交则

有多个祖先。

 

假设在工作目录中有三个文件，准备将它们暂存后提交。暂存操作会对每一个文件计算校验和（SHA-1 哈希字串），然后把当前版本的文件快照保存到Git 仓库中（Git 使用blob 类型的对象存储这些快照），并将校验和加入暂存区域：

 

当使用git commit 新建一个提交对象前，Git 会先计算每一个子目录（本例中就是项目根目录）的校验和，然后在Git 仓库中将这些目录保存为树（tree）对象。之后Git 创建的提交对象，除了包含相关提交信息以外，还包含着指向这个树对象（项目根目录）的指针，如此它就可以在将来需要的时候，重现此次快照的内容了。

 

现在，Git 仓库中有五个对象：三个表示文件快照内容的blob 对象；一个记录着目录树

内容及其中各个文件对应blob 对象索引的tree 对象；以及一个包含指向tree 对象（根目录）的索引和其他提交信息元数据的commit 对象

 

Git 中的分支，其实本质上仅仅是个指向commit 对象的可变指针。Git

会使用master 作为分支的默认名字。在若干次提交后，你其实已经有了一个指向最后一次

提交对象的master 分支，它在每次提交的时候都会自动向前移动。

 

 

Git 又是如何创建一个新的分支的呢？答案很简单，创建一个新的分支指针。比如

新建一个testing 分支，可以使用git branch 命令：

$ git branch testing这会在当前commit 对象上新建一个分支指针

 

Git 是如何知道你当前在哪个分支上工作的呢？其实答案也很简单，它保存着一

个名为HEAD 的特别指针。

在Git 中，它是一个指向你正在工作中的本地分支的指针。运行git branch 命令，仅仅是建立了一个新的分支，但不会自动切换到这个分支中去

 

 

要切换到其他分支，可以执行git checkout 命令。我们现在转换到新建的testing 分

支：$ git checkout testing  这样HEAD 就指向了testing 分支

 

$ git checkout master这条命令做了两件事。它把HEAD 指针移回到master 分支，并把工作目录中的文件换成了master 分支所指向的快照内容。也就是说，现在开始所做的改动，将始于本项目中一个较老的版本。它的主要作用是将testing 分支里作出的修改暂时取消，这样你就可以向另

一个方向进行开发。

 

由于Git 中的分支实际上仅是一个包含所指对象校验和（40 个字符长度SHA-1 字串）

的文件，所以创建和销毁一个分支就变得非常廉价。说白了，新建一个分支就是向一个文件

写入41 个字节（外加一个换行符）那么简单，当然也就很快了。

 

 

基本的分支与合并

转换分支的时候最好保持一个清洁的工作区域。稍后会介绍几个绕过这种问题的办法（分别叫做stashing 和amending）

 

Git 会把工作目录的内容恢复为检出某分支时它所指向的那个commit 的快照。它会自动添加、删除和修改文件以确保目录的内容和你上次提交时完全一样。

 

git merge 命令来进行合并

合并时出现了“Fast forward”（快进）提示。由于当前master 分支所在的commit 是要并入的hotfix 分支的直接上游，Git 只需把指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支，那么Git 在合并两者时，只会简单地把指针前移，因为没有什么分歧需要解决，所以这个过程叫做快进（Fast forward）。

 

使用git branch 的-d 选项表示删除

 

特殊的commit 称作合并提交（mergecommit），因为它的祖先不止一个。

 

冲突的合并

有时候合并操作并不会如此顺利。如果你修改了两个待合并分支里同一个文件的同一部

分，Git 就无法干净地把两者合到一起。将得到类似下面的结果：

CONFLICT (content): Merge conflict in 文件名

Automatic merge failed; fix conflicts and then commit the result.

Git 作了合并，但没有提交，它会停下来等你解决冲突。要看看哪些文件在合并时发生冲

突，可以用git status 查阅：

任何包含未解决冲突的文件都会以未合并（unmerged）状态列出。Git 会在有冲突的文件

里加入标准的冲突解决标记，可以通过它们来手工定位并解决这些冲突

在解决了所有文件里的所有冲突后，运行git add 将把它们标记为已解决（resolved）。因为一旦暂存，就表示冲突已经解决。如果你想用一个有图形界面的工具来解决这些问题，不妨运行git mergetool，它会调用一个可视化的合并工具并引导你解决所有冲突

 

再运行一次git status 来确认所有冲突都已解决。

 

分支管理

git branch 命令不仅仅能创建和删除分支，如果不加任何参数，它会给出当前所有分支的清单

 

分支前的* 字符：它表示当前所在的分支

 

若要查看各个分支最后一次commit 信息，运行git branch -v

 

要从该清单中筛选出你已经（或尚未）与当前分支合并的分支，可以用--merge 和--no-merged 选项

 

用git branch --no-merged 查看尚未合并的工作：我们会看到其余还未合并的分支。因为其中还包含未合并的工作，用git branch -d 删除该分支会导致失败：如果你坚信你要删除它，可以用大写的删除选项-D 强制执行

 

分支式工作流程

长期分支

你可以同时拥有多个开放的分支，每个分支用于完成特定的任务，随着开发的推进，你可以随时把某个特性分支的成果并到其他分支中。

许多使用Git 的开发者都喜欢以这种方式来开展工作，比如仅在master 分支中保留完

全稳定的代码，即已经发布或即将发布的代码。与此同时，他们还有一个名为develop 或

next 的平行分支，专门用于后续的开发，或仅用于稳定性测试—— 当然并不是说一定要绝对稳定，不过一旦进入某种稳定状态，便可以把它合并到master 里。这样，在确保这些已完成的特性分支（短期分支，如前例的iss53）能够通过所有测试，并且不会引入更多错误之后，就可以并到主干分支中，等待下一次的发布。

 

某些大项目还会有个proposed（建议）或pu（proposed updates，建议更新）分支，它包含着那些可能还没有成熟到进入next或master 的内容。这么做的目的是拥有不同层次的稳定性：当这些分支进入到更稳定的水平时，再把它们合并到更高层分支中去。再次说明下，使用多个长期分支的做法并非必需，不过一般来说，对于特大型项目或特复杂的项目，这么做确实更容易管理。

 

特性分支

在任何规模的项目中都可以使用特性（Topic）分支。一个特性分支是指一个短期的，用来实现单一特性或与其相关工作的分支。

 

远程分支

远程分支（remote branch）是对远程仓库状态的索引。它们是一些无法移动的本地分

支；只有在进行Git 的网络活动时才会更新。远程分支就像是书签，提醒着你上次连接远

程仓库时上面各分支的位置。

我们用(远程仓库名)/(分支名) 这样的形式表示远程分支。

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

可以运行git fetch origin 来进行同步。该命令首先找到origin 是哪个服务器（本例为git.ourcompany.com），从上面获取你尚未拥有的数据，更新你本地的数据库，然后把

origin/master 的指针移到它最新的位置

 

推送

要想和其他人分享某个分支，你需要把它推送到一个你拥有写权限的远程仓库。你的本地

分支不会被自动同步到你引入的远程分支中，除非你明确执行推送操作。换句话说，对于无

意分享的，你尽可以保留为私人分支，而只推送那些协同工作的特性分支。

 

如果你有个叫serverfix 的分支需要和他人一起开发，可以运行git push (远程仓库名) (分支名)

 

跟踪分支

从远程分支检出的本地分支，称为跟踪分支(tracking branch)。跟踪分支是一种和远程

分支有直接联系的本地分支。在跟踪分支里输入git push，Git 会自行推断应该向哪个服

务器的哪个分支推送数据。反过来，在这些分支里运行git pull 会获取所有远程索引，并

把它们的数据都合并到本地分支中来。

 

在克隆仓库时，Git 通常会自动创建一个master 分支来跟踪origin/master。这正是

git push 和git pull 一开始就能正常工作的原因。

 

要为本地分支设定不同于远程分支的名字，只需在前个版本的命令里换个名字：

$ git checkout -b sf origin/serverfix

现在你的本地分支sf 会自动向origin/serverfix 推送和抓取数据了。

 

删除远程分支

git push[远程名] :[分支名]

 

衍合

把一个分支整合到另一个分支的办法有两种：merge（合并） 和rebase（衍合）。

衍合基础

最容易的整合分支的方法是merge 命令，它会把两个分支最新的快照（C3和C4）以及二者最新的共同祖先（C2）进行三方合并

 

你可以把在C3 里产生的变化补丁重新在C4 的基础上打一遍。在Git 里，这种操作叫做衍合（rebase）。有了rebase 命令，就可以把在一个分支里提交的改变在另一个分支里重放一遍。

如：$ git checkout experiment

$ git rebase master

它的原理是回到两个分支（你所在的分支和你想要衍合进去的分支）的共同祖先，提取你

所在分支每次提交时产生的差异（diff），把这些差异分别保存到临时文件里，然后从当前

分支转换到你需要衍合入的分支，依序施用每一个差异补丁文件。

 

合并结果中最后一次提交所指向的快照，无论是通过一次衍合还是一次三方合并，都是同样的快照内容，只是提交的历史不同罢了。衍合按照每行改变发生的次序重演发生的改变，而合并是把最终结果合在一起。

 

衍合的风险

永远不要衍合那些已经推送到公共仓库的更新。