理解git分支-远程分支

远程分支

远程引用是对远程仓库的引用(指针),包括分支、标签等等。 你能够经过 git ls-remote (remote)来显式地得到远程引用的完整列表,或者经过 git remote show (remote) 得到远程分支的更多信息。 然而,一个更常见的作法是利用远程跟踪分支。git

远程跟踪分支是远程分支状态的引用。 它们是你不能移动的本地引用,当你作任何网络通讯操做时,它们会自动移动。 远程跟踪分支像是你上次链接到远程仓库时,那些分支所处状态的书签。github

它们以 (remote)/(branch) 形式命名。 例如,若是你想要看你最后一次与远程仓库 origin 通讯时master 分支的状态,你能够查看 origin/master 分支。 你与同事合做解决一个问题而且他们推送了一个 iss53 分支,你可能有本身的本地 iss53 分支;可是在服务器上的分支会指向 origin/iss53 的提交。数据库

这可能有一点儿难以理解,让咱们来看一个例子。 假设你的网络里有一个在 git.ourcompany.com 的 Git 服务器。 若是你从这里克隆,Git 的 clone 命令会为你自动将其命名为 origin,拉取它的全部数据,建立一个指向它的 master 分支的指针,而且在本地将其命名为 origin/master。 Git 也会给你一个与 origin 的 master 分支在指向同一个地方的本地 master 分支,这样你就有工做的基础。缓存

NOTE

“origin” 并没有特殊含义

远程仓库名字 “origin” 与分支名字 “master” 同样,在 Git 中并无任何特别的含义同样。 同时 “master” 是当你运行 git init 时默认的起始分支名字,缘由仅仅是它的普遍使用,“origin” 是当你运行 git clone 时默认的远程仓库名字。 若是你运行 git clone -o booyah,那么你默认的远程分支名字将会是 booyah/master服务器

克隆以后的服务器与本地仓库。Figure 3-22. 克隆以后的服务器与本地仓库网络

若是你在本地的 master 分支作了一些工做,然而在同一时间,其余人推送提交到git.ourcompany.com 并更新了它的 master 分支,那么你的提交历史将向不一样的方向前进。 也许,只要你不与 origin 服务器链接,你的 origin/master 指针就不会移动。学习

本地与远程的工做能够分叉。Figure 3-23. 本地与远程的工做能够分叉fetch

若是要同步你的工做,运行 git fetch origin 命令。 这个命令查找 “origin” 是哪个服务器(在本例中,它是 git.ourcompany.com),从中抓取本地没有的数据,而且更新本地数据库,移动origin/master 指针指向新的、更新后的位置。this

`git fetch` 更新你的远程仓库引用。Figure 3-24. git fetch 更新你的远程仓库引用spa

为了演示有多个远程仓库与远程分支的状况,咱们假定你有另外一个内部 Git 服务器,仅用于你的 sprint 小组的开发工做。 这个服务器位于 git.team1.ourcompany.com。 你能够运行 git remote add 命令添加一个新的远程仓库引用到当前的项目,这个命令咱们会在 Git 基础 中详细说明。 将这个远程仓库命名为 teamone,将其做为整个 URL 的缩写。

添加另外一个远程仓库。Figure 3-25. 添加另外一个远程仓库

如今,能够运行 git fetch teamone 来抓取远程仓库 teamone 有而本地没有的数据。 由于那台服务器上现有的数据是 origin 服务器上的一个子集,因此 Git 并不会抓取数据而是会设置远程跟踪分支teamone/master 指向 teamone 的 master 分支。

远程跟踪分支 `teamone/master`。Figure 3-26. 远程跟踪分支 teamone/master

推送

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

若是但愿和别人一块儿在名为 serverfix 的分支上工做,你能够像推送第一个分支那样推送它。 运行 git push (remote) (branch):

 git push origin serverfix






$Counting objects: 24, done.Delta compression using up to 8 threads.Compressing objects: 100% (15/15), done.Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.Total 24 (delta 2), reused 0 (delta 0)To https://github.com/schacon/simplegit* [new branch]      serverfix -> serverfix

这里有些工做被简化了。 Git 自动将 serverfix 分支名字展开为refs/heads/serverfix:refs/heads/serverfix,那意味着,“推送本地的 serverfix 分支来更新远程仓库上的 serverfix 分支。” 咱们将会详细学习 Git 内部原理 的 refs/heads/ 部分,可是如今能够先把它放在儿。 你也能够运行 git push origin serverfix:serverfix,它会作一样的事 - 至关于它说,“推送本地的 serverfix 分支,将其做为远程仓库的 serverfix 分支” 能够经过这种格式来推送本地分支到一个命名不相同的远程分支。 若是并不想让远程仓库上的分支叫作 serverfix,能够运行 git push origin serverfix:awesomebranch 来将本地的 serverfix 分支推送到远程仓库上的awesomebranch 分支。

NOTE

如何避免每次输入密码

若是你正在使用 HTTPS URL 来推送,Git 服务器会询问用户名与密码。 默认状况下它会在终端中提示服务器是否容许你进行推送。

若是不想在每一次推送时都输入用户名与密码,你能够设置一个 “credential cache”。 最简单的方式就是将其保存在内存中几分钟,能够简单地运行 git config --global credential.helper cache 来设置它。

想要了解更多关于不一样验证缓存的可用选项,查看 凭证存储

下一次其余协做者从服务器上抓取数据时,他们会在本地生成一个远程分支 origin/serverfix,指向服务器的 serverfix 分支的引用:

 git fetch origin





$remote: Counting objects: 7, done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 0), reused 3 (delta 0)Unpacking objects: 100% (3/3), done.From https://github.com/schacon/simplegit* [new branch]      serverfix    -> origin/serverfix

要特别注意的一点是当抓取到新的远程跟踪分支时,本地不会自动生成一份可编辑的副本(拷贝)。 换一句话说,这种状况下,不会有一个新的 serverfix 分支 - 只有一个不能够修改的 origin/serverfix指针。

能够运行 git merge origin/serverfix 将这些工做合并到当前所在的分支。 若是想要在本身的serverfix 分支上工做,能够将其创建在远程跟踪分支之上:

 git checkout -b serverfix origin/serverfix

$Branch serverfix set up to track remote branch serverfix from origin.Switched to a new branch 'serverfix'

这会给你一个用于工做的本地分支,而且起点位于 origin/serverfix

跟踪分支

从一个远程跟踪分支检出一个本地分支会自动建立一个叫作 “跟踪分支”(有时候也叫作 “上游分支”)。 跟踪分支是与远程分支有直接关系的本地分支。 若是在一个跟踪分支上输入 git pull,Git 能自动地识别去哪一个服务器上抓取、合并到哪一个分支。

当克隆一个仓库时,它一般会自动地建立一个跟踪 origin/master 的 master 分支。 然而,若是你愿意的话能够设置其余的跟踪分支 - 其余远程仓库上的跟踪分支,或者不跟踪 master 分支。 最简单的就是以前看到的例子,运行 git checkout -b [branch] [remotename]/[branch]。 这是一个十分经常使用的操做因此 Git 提供了 --track 快捷方式:

 git checkout --track origin/serverfix

$Branch serverfix set up to track remote branch serverfix from origin.Switched to a new branch 'serverfix'

若是想要将本地分支与远程分支设置为不一样名字,你能够轻松地增长一个不一样名字的本地分支的上一个命令:

 git checkout -b sf origin/serverfix

$Branch sf set up to track remote branch serverfix from origin.Switched to a new branch 'sf'

如今,本地分支 sf 会自动从 origin/serverfix 拉取。

设置已有的本地分支跟踪一个刚刚拉取下来的远程分支,或者想要修改正在跟踪的上游分支,你能够在任意时间使用 -u 或 --set-upstream-to 选项运行 git branch 来显式地设置。

 git branch -u origin/serverfix
$Branch serverfix set up to track remote branch serverfix from origin.
NOTE

上游快捷方式

当设置好跟踪分支后,能够经过 @{upstream} 或 @{u} 快捷方式来引用它。 因此在 master分支时而且它正在跟踪 origin/master 时,若是愿意的话可使用 git merge @{u} 来取代git merge origin/master

若是想要查看设置的全部跟踪分支,可使用 git branch 的 -vv 选项。 这会将全部的本地分支列出来而且包含更多的信息,如每个分支正在跟踪哪一个远程分支与本地分支是不是领先、落后或是都有。

 git branch -vv



$iss53     7e424c3 [origin/iss53: ahead 2] forgot the bracketsmaster    1ae2a45 [origin/master] deploying index fix* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do ittesting   5ea463a trying something new

这里能够看到 iss53 分支正在跟踪 origin/iss53 而且 “ahead” 是 2,意味着本地有两个提交尚未推送到服务器上。 也能看到 master 分支正在跟踪 origin/master 分支而且是最新的。 接下来能够看到 serverfix 分支正在跟踪 teamone 服务器上的 server-fix-good 分支而且领先 2 落后 1,意味着服务器上有一次提交尚未合并入同时本地有三次提交尚未推送。 最后看到 testing 分支并无跟踪任何远程分支。

须要重点注意的一点是这些数字的值来自于你从每一个服务器上最后一次抓取的数据。 这个命令并无链接服务器,它只会告诉你关于本地缓存的服务器数据。 若是想要统计最新的领先与落后数字,须要在运行此命令前抓取全部的远程仓库。 能够像这样作:$ git fetch --all; git branch -vv

拉取

当 git fetch 命令从服务器上抓取本地没有的数据时,它并不会修改工做目录中的内容。 它只会获取数据而后让你本身合并。 然而,有一个命令叫做 git pull 在大多数状况下它的含义是一个 git fetch 紧接着一个 git merge 命令。 若是有一个像以前章节中演示的设置好的跟踪分支,无论它是显式地设置仍是经过 clone 或 checkout 命令为你建立的,git pull 都会查找当前分支所跟踪的服务器与分支,从服务器上抓取数据而后尝试合并入那个远程分支。

因为 git pull 的魔法常常使人困惑因此一般单独显式地使用 fetch 与 merge 命令会更好一些。

删除远程分支

假设你已经经过远程分支作完全部的工做了 - 也就是说你和你的协做者已经完成了一个特性而且将其合并到了远程仓库的 master 分支(或任何其余稳定代码分支)。 能够运行带有 --delete 选项的 git push命令来删除一个远程分支。 若是想要从服务器上删除 serverfix 分支,运行下面的命令:

 git push origin --delete serverfix

$To https://github.com/schacon/simplegit- [deleted]         serverfix

基本上这个命令作的只是从服务器上移除这个指针。 Git 服务器一般会保留数据一段时间直到垃圾回收运行,因此若是不当心删除掉了,一般是很容易恢复的。

相关文章
相关标签/搜索