我们公司的软件产品迭代采用的是scrum敏捷开发流程，代码使用git进行版本管理。在新人最初的几次开发任务中，我对于git的使用也仅限于一些基本的命令，包括：add、commit、rebase、cherry-pick、push、checkout等等。
直到有一天，我发现远程分支上存在着一些历史feature分支，这对于我这个初入职场的小白来说还是有些好奇：feature分支在本地建立不就行了吗？为何还需要推送到远程仓库？
带着这一些列的疑问，我仔细研究了一些我们基于gerrit的code review流程，终于明白了为何会有feature远程分支。这一切都与git的分支模型有关。
期间，我在一个英文博客上看到了一篇关于git分支模型的介绍，看完后觉得不错，对其进行简要地整理，以呈现给大家。

分权集中

下图中心的仓库，是我们建立并在使用的仓库，具有分支模型，其通常会被认为是“真正的中心仓库”。然而，事实上，其仅仅是被认为是中心仓库而已，因为git作为一个分布式版本控制系统（DVCS），在技术层面并不存在哪个仓库是中心仓库。而这个被认为是“中心”的仓库，我们更愿意称之为origin，这个名字对于所有git用户都是很熟悉的。

每个开发者都会从origin进行pull或向其进行push操作。但是除了与origin具有push-pull关系之外，开发者们还可能从其他同级的伙伴那里pull最新的改动，从而形成一个sub team。比如，对于两个以上的开发者，在过早地向origin推送开发进展之前，其可以开辟一个新的feature分支来共同工作。如上图所示，存在着这样几个开发小组：Alice & Bob，Alice & David，Clair & David。

从技术角度而言，这仅仅意味着Alice定义了一个远程仓库，名字是Bob，其指向了Bob的仓库，反之亦然，仅此而已。

主分支

归根到底，开发模型也受到了上述思想的影响。在中心仓库中，在其无限的生命周期中，始终存在着两条主分支：

• master
• develop

大家对origin上的master分支应该并不陌生。而另一个与之平行的分支，我们称之为develop分支。

origin/master：在这个分支上，源代码的HEAD指针的指向始终都是就绪/可发布的产品状态。

origin/develop：在这个分支上，源代码的HEAD指针的指向始终都是下一个版本的产品状态。

当develop分支的源代码到达某一个可发布的稳定点时，所有的改动都应该合并到master分支，然后打上版本的tag标签。

因此，每次将改动合并至master分支时，意味着一个新版本的诞生。我们往往对这个过程控制得非常严格。所以每次master分支上有commit时，我们都应该使用git hook脚本来自动编译、发布软件至产品服务器上。

支持分支

与主分支master、develop相邻的则是各种支持分支，用于帮助团队成员之间进行平行开发，跟踪功能，准备产品发布以及帮助修复在线产品的一些Bug。与主分支不同，这些分支总是具有有限的生命周期，因为它们最终都是要被删除的。

我们可能用到的几种不同的支持分支：

• Feature分支
• Release分支
• Hotfix分支

上述的每一个分支都具有特定的目的，并且必须遵守严格的规则。比如：哪些分支可以是它们的源头分支，哪些分支必须是它们的合并目标。

当然，从技术角度来说，这些分支并没有什么特殊之处。所谓的分支类型只是我们根据如何使用它们而进行分类的。

Feature分支

规则：

可以源自develop分支
必须合并到develop分支
命名：除master，develop，release-*，hotfix-*之外

Feature分支（也称：topic分支）用来为即将发布的版本或更远的版本开发新的feature。当开发一个新的功能的时候，我们不知道这个功能会被纳入哪个目标版本。Feature分支的本质就是，只要该功能处于开发阶段，feature分支就会存在，并最终会被合并至develop分支（以确保将新功能添加到即将发布的版本中）或者丢弃（在实验失败的情况下）。

Feature分支通常只存在与开发者自己的仓库中，而不是origin。

创建feature分支

当开始开发一个新的功能时，需要从develop主分支中开辟一个新分支。

1

$ git checkout -b myfeature develop //表示切换到一个新的分支“myfeature”

将完成的功能纳入develop

完成的功能可以合并至develop分支，以加入即将发布的版本之中。

1
2
3
4

$ git checkout develop  //切换至develop分支
$ git merge --no-ff myfeature //
$ git branch -d myfeature   //删除myfeature分支
$ git push origin develop

–no-ff选项会在合并分支时创建一个新的commit对象，即使合并可以是一次fast-forward操作。这可以避免丢失feature分支的历史存在信息，并将该feature分支上的所有commit放在在一起。

如上图所示，相比较而言，后面一种情况是不可能从git历史记录中看到哪些提交对象一起实现了一个功能，你必须手动读取所有日志信息。在后一种情况下，恢复整个功能（即一组提交）是非常困难的，而如果使用了–no-ff选项，则很容易实现。

当然，这会创建一些空的commit对象，但收益远大于成本。

Release分支

规则

可以源自develop分支
必须合并到develop分支和master分支
命名：release-*

Release分支用于支持准备新的产品版本，它们允许对版本进行小错误修复和元数据准备（版本号，构建日期等）。通过在Release分支上进行所有这些工作，develop分支会被清理以接收下一个大版本的功能。

当develop分支达到了新版本的期望状态时，即可从develop分支开辟新的release分支。当然，必须要等到所有待发布的功能合并至develop分支之后才可以。

正是在release分支的开始，即将发布的版本会被分配版本号。直到这一刻起，develop分支“下一个版本”的改动。但是“下一个版本”会变为0.3还是1.0，需要等到release分支开始才知道。这是在release分支开始时，由版本规则决定的。

创release分支

Release分支从develop分支创建而来。例如，1.1.5版本是当前的产品版本，我们即将有一个大的版本。develop已经为“下一个版本”准备就绪了，并且我们已经决定这将成为1.2版本（而不是1.1.6或2.0）。所以我们开辟一个分支，并予以相应的版本号。

1
2
3

$ git checkout -b release-1.2 develop å
$ ./bump-version.sh 1.2 
$ git commit -a -m "Bumped version number to 1.2"

结束release分支

当release分支的状态已经准备好成为y一个真正的版本，需要完成一些操作。首先，将release分支合并至master分支（master上的每一个commit都是一个新的版本）。然后，master上的commit必须被打上标签，以便参考历史版本。最后，将在release分支上作出的改动合并到develop分支上，以便未来的版本还包含这些错误修复。

1
2
3
4
5
6
7
8
9
10

// step 1
$ git checkout master å
$ git merge --no-ff release-1.2
// step 2
$ git tag -a 1.2
// step 3
$ git checkout develop
$ git merge --no-ff release-1.2
// 完成后，我们可以将release分支删除
$ git branch -d release-1.2

Hotfix分支

规则

可以源自develop分支
必须合并到develop分支和master分支
命名：hotfix-*

Hotfix分支与release分支非常相似，其也是用于为新的产品版本做准备，尽管是计划之外的。它们是对发布版本的不良状态作出的回应。当产品版本中的一个关键bug必须要被修复时，可以从master分支上相应的tag标签中开辟一个hotfix分支。

Hotfix分支的本质是可以使develop分支上的工作得以继续，而另外有人进行bug修复。

创建hotfix分支

Hotfix分支从master分支创建而来。例如，1.2版本是当前产品的版本号，正在在线运行，由于服务器bug出现了一些问题。但是develop分支上的改动还不稳定。我们需要开辟一个hotfix分支来进行bug修复。

1
2
3
4
5

$ git checkout -b hotfix-1.2.1 master
$ ./bump-version.sh
$ git commit -a m "Bumped version number to 1.2.1"
// 修复bug并commit
$ git commit -m "Fixed server production problem"

结束hotfix分支

当完成bug修复之后，hotfix分支需要合并到master分支，当然也需要合并至develop分支，这与release分支是非常相似的。

1
2
3
4
5
6
7
8
9

// step 1: 合并至master，打上版本标签
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1
// step 2: 合并至develop
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1
// step 3: 删除hotfix分支
$ git branch -d hotfix-1.2.1

这里有一个例外需要注意，当一个release分支当前还存在时，hotfix分支的修改应该合并至release分支，而不是develop分支。因为release分支完成后，需要合并至develop分支。

这一系列共有两部分:

趣学Git分支——本地分支篇
趣学Git分支——远程分支篇

这里仍然是继续学习learnGitBranching中的远程分支部分，为了保持博客的独立性，这里再简要介绍一下：learnGitBranching一个可视化+交互式学习Git分支的网站，并且是以关卡的形式呈现，一关一关打怪升级，最关键的是还有中文版，简直不要太友好！

网址：https://learngitbranching.js.org/
Github主页：https://github.com/pcottle/learnGitBranching

Git本身作为一种具有强分享性质的工具，远程操作也是其必不可少的一部分，作为代码共享编辑的利器，更需要了解远程分支的一些操作，从而实现代码的合理协作和共享。所以：

是时候分享你的代码了，让编码变得社交化吧！

前言

这里要先介绍一下远程仓库的相关知识，截取learnGitBranching的图来说明：

一. 基本操作

1. Git Clone

从第一篇博客看过来的读者都知道，我们到目前位置的介绍都聚焦于本地仓库的操作（如branch、merge和rebase等等）。现在要开始介绍远程仓库的操作，其中最基础也是最经常用到一个命令就是git clone。

git clone命令的作用是在本地创建一个远程仓库的拷贝（比如从github.com），并建立远程分支，详见下一节。

2. 远程分支

远程分支反映了远程仓库（在上次和它通信时）的状态。这将帮助理解本地工作与公共工作的差别，也是与别人分享工作成果前至关重要的一步。

远程分支有一个特别的属性，在checkout时自动进入分离 HEAD 状态（即直接指向本地其所在的提交记录）。Git 这么做是出于不能直接在这些分支上进行操作的原因，因此必须在别的地方完成工作，（更新了远程分支之后）再用远程分享你的工作成果。

远程分支有一个命名规范，它们的格式是:

<remote name>/<branch name>

其中<remote name>是远程仓库名，一般默认是origin，<branch name>是分支名。

3. Git Fetch

Git远程仓库相关的操作实际可以归纳为两点：向远程仓库传输数据以及从远程仓库获取数据。既然可以能与远程仓库同步，那么就可以分享任何能被Git管理的更新。

git fetch是一个能从远程仓库获取数据的命令，它将执行如下两步：

1. 从远程仓库下载本地仓库中缺失的提交记录
2. 更新远程分支指针（如origin/master）

因此git fetch实际上将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态，但它并不会改变本地仓库的状态，也不会更新master分支，也不会修改磁盘上的文件。

所以，并不是执行了git fetch之后，本地仓库就与远程仓库同步了。这一步可以理解为单纯的下载操作。

4. Git Pull

前面的git fetch是获取远程的数据，现在还需要将远程分支的变化合并到本地仓库中去，这一步有很多种方法，其实是可以像合并本地分支一样来合并远程分支的。比如如下命令：

1. git cherry-pick origin/master
2. git rebase origin/master
3. git merge origin/master
4. …

但实际上，由于先抓取更新再合并到本地分支的这个流程很常用，因而Git特地提供了一个专门的命令来完成这两个操作，即git pull。git pull实际上就是git fetch和git merge <just-fetched-branch>的缩写。

5. Git Push

git push命令负责将本地变更上传到指定的远程仓库，并在远程仓库上合并新提交记录。

一般git push不带任何参数时的行为与Git中的一个名为push.default的配置有关。所以在进行项目推送钱，可以检查一下这个配置。

6. 远程分支跟踪

在git clone执行的过程中，基本上远程分支都会在本地对应绑定一个相应的分支，用于追踪远程分支，即在pull和push时默认追踪的源头，即pull和push不指定参数时，会默认将本地当前分支与其跟踪的远程分支进行交互。

当然也可以自己指定这种追踪关系。

6.1 跟踪方法一

比如用如下命令，就可以创建一个名为totallyNotMaster的分支，它跟踪远程分支origin/master，其实等于绑定。

git checkout -b totallyNotMaster origin/master

此时如果执行git pull时，先执行git fetch origin/master的操作，然后在totallyNotMaster分支上执行git merge origin/master。

6.2 跟踪方法二

还有另外一种方式，用如下命令：

git branch -u origin/master foo

即可让foo分支跟踪origin/master，如果当前就在foo分支上，则可以省略foo，即git branch -u origin/master。

7. 带参数的git pull，git push和git fetch

在介绍完远程分支跟踪之后，就能知道前面介绍的不带参数的git push和git pull都是如何选择两边的分支进行操作的了。那下面将介绍带参数的这些命令，使得本地与远程的分支交互更为灵活。

7.1 带参数的git push

带参数的git push为：

git push <remote> <place>

例如git push origin master指定了将本地的master推送到远端的master上面去。此时会忽略当前的checkout状态。

那如果来源分支和去向分支的名称不同呢？比如想把本地的foo分支推送到远程仓库中的bar分支，这是可以用如下命令：

git push origin <source>:<destination>

用来指定源和目的。当远程目的分支不存在的话，Git会先在远程仓库中根据你指定的这个名字先自行创建，而后再执行push操作。

7.2 带参数的git fetch

git fetch <remote> <place>

这是第一种用法，如git fetch origin master会默认将远端master分支上的内容下载，并更新远程分支origin/master，注意是不更新本地分支的。

git fetch <remote> <target>:<source>

第二种用法是直接对本地分支进行操作，不过，不能在当前checkout的分支上面做这个操作，其他分支是可以的，当然很少有人这么做，此时相应的远程分支是不会更新的，并且也会忽略当前的checkout状态。如果本地分支没有，则会先创建。

与git push的操作一样，只不过这里的源和目的反过来了，毕竟一个是下载，一个是上传。而且，如果指定的本地分支不存在，也会先在本地新建分支，在执行fetch操作。

这里要注意的是：与push的不同在于，当git fetch没有参数时，它会下载所有的提交记录到各个远程分支，而不像git push一样操作当前checkout的分支及其对应追踪远程分支。

7.3 带参数的git pull

前面也提到过，git pull其实就是git fetch和git merge的缩写，那么带参数的git pull就同样很好理解了，比如下面的两种方式是等价的：

git pull origin foo
git fetch origin foo; git merge o/foo

git pull origin bar~1:bugFix
git fetch origin bar~1:bugFix; git merge bugFix

git pull 唯一关注的是提交最终合并到哪里，也就是为git fetch提供的destination参数。

8. 什么？没有source？

在Git中有两种关于<source>的用法是比较诡异的，可以在git push和git fetch的时候不指定任何的<source>，如下：

git push origin :side
git fetch origin :bugFix

8.1 push空的source

在push的时候如果<source>为空，则会***删除*** 远程仓库中的分支。操作需谨慎啊！

8.2 fetch空的source

在fetch的时候如果<source>为空，则会在本地***创建***一个新分支。这个操作还是挺友好的。

二. 场景分析

在git push的过程中，相信大多数人都有遇到过这种情况。

假设你周一克隆了一个仓库，然后开始研发某个新功能。到周五时，你新功能开发测试完毕，可以发布了。但是 —— 天啊！你的同事这周写了一堆代码，还改了许多你的功能中使用的 API，这些变动会导致你新开发的功能变得不可用。但是他们已经将那些提交推送到远程仓库了，因此你的工作就变成了基于项目旧版的代码，与远程仓库最新的代码不匹配了。

这时候直接git push的话，Git是不会允许你进行变更的，所以它会强制你先合并远程最新的代码，然后才允许你push。

这时候可以有两种做法：

1. git fetch; git merge origin/master; git push
2. git fetch; git rebase origin/master; git push

但是要敲很多条指令，为了方便，之前提到过可以使用git pull代替fetch和merge，或使用git pull --rebase代替fetch和rebase。

因此由fetch、rebase/merge和push组成的工作流很普遍。

在开发社区里面有很多关于merge和rebase的讨论，以下是关于rebase的优缺点：

1. 优点：Rebase能使提交树变得很干净，所有的提交都在一条线上。
2. 缺点：Rebase修改了提交树的历史。

所以用merge还是rebase就看个人喜好了。