Git知识总览(六) Git分支中的远程操作实践

前几篇博客陆陆续续的讲了好多关于Git操作的内容，本篇博客仍然也不例外，不过本篇博客的主题是关于git的远程操作的。依照之前博客的风格，我们依然依托于LearningGitBranch中的相关内容来探究一下Git的远程操作。今天这篇博客算是Git系列博客的结尾了。

一、PUSH到远端

1、将本地的Merge操作推送给远端

下方左边是我们的git分支的初始状态，我们从master分支上分别创建了三个不同的分支side1、side2、side3。并且在每个分支上都有新的提交。右边是远端的状态，在我们从远端Clone后，团队的其他小伙伴往远端提了一个新的提交C8。

　　

下方就是我们经过远端代码的pull，然后在本地进行merge, 最终进行push的效果。下方我们就通过具体的分支操作来达到下方的目标。

　　

上述的目标其实很简单，就是将上述的side1、side2、side3分支合入到master分支，然后再push到远端。下方是完成目标的具体操作。

• git pull: 因为要合入到master分支，所有先我们通过 checkout 命令切换到master分支，然后通过 pull 命令获取到远端master分支上的所有提交。

• git merge: 接下来就是在 master分支上一系列的merge操作了，最终side1、side2、side3的分支都会合入到master分支。

• git push: 然后通过git push 操作将本地合并好的master分支push到远端进行共享。

使用场景：上述操作在日常开发中经常用到，比如你本地针对不同的问题开出了不同的分支，然后在各个分支上分别做了不同的事情。当这些事情做完时需要合并到主分支，和其他同事进行共享。在合入之前，需要先拉取远端master分支的最新代码，然后在本地进行合并，合并后在进行push操作。有的小伙伴文为啥要拉取最新的代码，因为拉取代码是为了保证本地的master分支与远端一致，并在代码merge时极有可能会产生冲突，需要我们在本地merge的过程中将这些冲突进行解决掉，然后再push到远端。

　　

2、推送远端前的rebase操作

上面代码合并时的分支看上去是非常乱的，我们可以不选择使用merge命令来合并分支，可以使用rebase-变基操作。变基操作在之前的博客中已经介绍过了，本篇博客就不做具体讲解了，下方只是对rebase操作的具体实践。

下方的内容也是比较简单的，就是使用rebase操作来代替上方的merge操作。下方的截图就是我们要完成的目标。此处的目标与上述merge操作后的结果对比一下，不难发现，下方经过rebase操作后的分支并没有那么杂乱，而是成线性的操作，push到远端的话，看上去就好像是基于master分支来开发的一样。

　　

下方的操作也是比较简单的，就是将上一部分的merge操作换成了rebase操作，不过在执行rebase操作时要区分好一个分支变基到那个分支上。下方是具体操作的描述：

• git fetch: 首先投过git fetch抓取远端的代码。

• git rebase: 然后就一系列的git rebase操作，先使用git rebase o/master side1 操作将side1分支上的提交内容变基到o/master分支上，然后是将side2变基到side1上，接着是将side3变基到side2上。最后是将master分支变基到side3上，这一步操作也就是快速前进的操作，目的是将master分支指向目前rebase后的分支的最后一个提交上。

• git push: 最后就是通过git push将整理好的分支push到远端。远端的分支看上去就是一个线性的提交了，而不会保留我们本地之前的那三个分支的具体提交。

通过merge和rebase操作都能完成我们将本地的代码进行合并到主分支然后push到远端的目标，但是其具体整理分支方式不同。rebase使得分支的合并更线性一些，而merge操作就使的分支的合并呈现二维的一个结构。

至于rebase好还是merge好，个人感觉merge的优点是能更好的保存你的操作历史，而rebase则会丢弃掉一些操作历史。但是merge的缺点是多个分支进行合并时，其合并历史看上去会比较繁杂，而rebase操作显得就比较干净利索。至于在合并分支时时用merge还是rebase，没有具体的要求。

　　

二、远端分支追踪和push

1、分支的远程追踪

首先我们来看一个示例：

• 首先我们通过 git clone 操作克隆了一份代码，然后在本地的master分支上通过 git checkout -b bugfix01分支并切换到该分支上，并且在远端通过fakeTeamwork操作创建了一个远端提交。

• 接着我们在bugfix01分支上做了一次提交。

• 此时此刻我们在bugfix01分支上想拉取远端最新的代码，执行了git pull操作。从下方来看，是不被允许的，并给出了提示 “bugfix01 is not a remote tracking branch! I dont know where to push”，大概意思是bugfix01没有一个正在追踪的远程分支，不知道从哪个分支上进行拉取。

　　

接下来要做的事情是在创建分支就给我们创建的新的分支指定一个追踪的远程分支，这样就可在我们创建的新分支上来pull远端分支中的内容了。下方是具体操作：

• 首先我们通过 git checkout -b bugfix02 o/master 命令创建并切换到了bugfix02上，后边所添加的o/master分支名就是bugfix02所要追踪的远程分支。

• 因为我们为bugfix02添加和远程追踪分支，我们就可以在bugfix02分支上通过 git pull 命令来拉取 o/master分支上的相关内容。具体如下所示。

　　

　　

 2、push到远端

接下来我们要聊到就是在当前操作分支上将将本地的其他分支push到远端。具体操作如下所示：

• 下方的操作我们事先将HEAD指针指向了C0。

• 然后执行 git push origin foo 操作将foo分支上的内容push到远端，push完毕后，本地的o/foo分支也会跟着变动，如下所示。

• 同样，使用 git push origin master 命令，可以将本地的master分支上的提交push到远端的master分支，并修改本地的远端o/master分支的指向。

因为在该操作中foo追踪了远端的o/foo分支，所以可以push到远端的foo分支上。

　　

上面将相关分支同步到远端所对应的分支上，比如将本地的master分支push到远端的o/master分支上。而接下来要做的事情是将本地的 a分支push到远端的b分支上，将本地的b分支push到远端的a分支上。具体导致如下所示：

• 下方我们通过 git push origin foo:master 操作将本地foo分支上的提交push到远端的master分支上。

• 通过 git push origin master^:foo 操作，将本地的master分支之前的所有分支提交到远端的foo分支上。

上述冒号后方的分支名所对应的就是远端的分支。

　　

三、抓取远端操作

1. fetch origin

上面演示了push origin 的操作，接下来我们可以看一下fetch origin的操作。

• 我们可以通过 git fetch origin foo:master 来将远端的master分支上的内容同步到本地的foo分支上，当然这个foo分支也要有对应的追踪远端的。

　　

我们还可以通过fetch origin或者push origin来创建和删除相关分支。下方左图是我们要完成的目标，右图是目前现状。我们要做的是通过 fetch origin 命令来删除foo分支，然后也是通过fetch origin命令来创建一个barf分支。

　　

接下来我们就通过相关命令来完成上述目标：

• 首先我们通过git push origin :foo 操作来删除远端的foo分支。

• 然后在通过git fetch origin :bar操作来创建一个本地的bar分支。

具体如下所示：

　　

四、本地分支跟踪远端其他分支

本关其实就是在拉取分支时顺便创建一个追踪远端相关分支的本地分支。下方截图就是本关要完成的任务。图左边是我们要完成的目标，右边是现有状态。要完成最终的目标，需执行下方的几步：

• 当前状态是在master分支上有一个新的提交C4并未push到远端, 若要达到目标，需要在master分支上线pull远端的bar分支，然后在pull远端的master分支。

• 在pull远端分支时，分别创建了不同的分支跟踪远端的分支。下方会有具体的命令操作。

　　

下方是具体的命令操作：

• 首先通过 git pull origin bar:foo 命令拉取远端的 bar 分支，在拉取远端分支后，在本地创建一个 foo 分支来跟踪远端的bar分支。

• 然后再通过 git pull origin master:side 命令拉取远端的 master 分支，然后创建一个本地side分支来跟踪远端的master分支。

最终操作如下所示：

　　

陆陆续续的也聊了好多git相关操作，git相关内容先到这儿，以后如果还有其他内容再做补充。