您的位置:首页 > 其它

《Pro Git》笔记二:关于远程仓库的一些思考和记录

2015-06-24 21:18 281 查看

前言

这篇笔记主要是当初在学习分支,远程仓库,远程分支时记录的一些基本概念和自己的理解。不得不说,这几样东西理解起来有点难,特别是远程仓库,远程分支。

分支

什么是分支

分支上本质上仅仅是个指向提交对象的可变指针。

什么是 HEAD

HEAD是一个指向你正在工作中的本地分支的指针,或者说项目仓库当前分支的指针。

分支的主要用途是什么

下面这段话是我当初看书时的理解,现在看起来,这应该算是分支的普遍用途吧。

关于分支,我现在想到的一个应用场景是这样的,比如现在我想在项目中加入某个特性或功能,但关于这个特性或功能实际效果怎样,以后是否要加入到发布的版本中,这个是不确定的。那我就可以新建一个分支,然后在这个分支上开发这个新的功能或特性,并测试其实际效果。最后如果觉得效果不错,要将这个功能加入都正式发布的版本中,那把这个分支和主分支合并一下就可以了。也许,分支的意义就在于你可以去做各种尝试,又不用担心影响到主分支。确实是一个非常有用的特性。

远程仓库

远程仓库的意义是什么?

远程仓库是多人进行协作进行一个项目的基础。要参与任何一个 Git 项目的协作,必须要了解该如何管理远程仓库。

什么是远程仓库

指托管在网络上的项目仓库。最常见的,比如我们托管在 Github 上的项目仓库都属于远程仓库;另外一些公司内部会有自己的 git 服务器,把公司的项目托管到上面,那些项目仓库也属于远端仓库。

远程分支

什么是远程分支

下面是书上对远程分支的定义。

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

下面是我的理解或解释。首先远程分支是一个存在于本地项目仓库中的分支,也就是说你可以在本地项目仓库中切换到远程分支,但它又不同于本地分支,它是远程仓库上的某一个分支在本地仓库的一个影子,一份缓存。为什么需要它的存在?我觉得主要还是方便获取远程仓库的分支一些信息。如果没有它的存在,那我们每次需要查看远程仓库的某个分支的信息时,都需要和网络上的远程仓库发生数据交换。但有了远程分支的存在,就不会了,我们只是在特定时候执行 git fetch 命令从远程仓库同步数据到本地。

什么是跟踪分支

从远程分支 checkout 出来的本地分支,称为 跟踪分支 (tracking branch)。跟踪分支是一种和某个远程分支有直接联系的本地分支。

关于远程仓库的使用情景

情景一 单人负责一个项目

这应该是最常见的一个使用情景了。

在 Github 上创建一个远程仓库 Blog,该远程仓库有一个默认分支 master

在本地 clone 该远程仓库

上述克隆操作,首先会在本地创建一个本地仓库,并在本地仓库中添加远程仓库 Blog 且将其命名为 origin,且会从远程仓库的 origin/master 分支创建一个跟踪分支 master

现在,我们就可以在这个跟踪分支 master上做一些修改,并在适当的时候通过 git push 命令将该跟踪分支 master 同步到远程仓库的 master 分支

情景二 多人协作完成一个项目

这种情境下,具体的流程其实要看项目组采用的分布式工作流程,这一点书中第五章会介绍。这里简单说下我觉得自己最可能会用到的一种分布式工作流程 - 集中式工作流。这种工作流其实跟用 SVN 差不多。下面是我总结的在这种工作流下,我会用的工作流程。

开始正式的编码之前,首先 git pull 获取远程仓库的最新数据并合并到当前工作分支

编写代码并提交到本地仓库

git fetch 获取远程仓库最新数据

切换到本地分支 git rebase 衍和远程分支

git push 推送本地分支到远程仓库

疑问:在一个本地仓库中使用多个远程仓库的使用情景?

在整理远程仓库相关的笔记时,自己心里最疑惑的一点是在一个本地中添加多个远程仓库的使用情景。

首先我想到的第一个使用情景是这样的。首先本地仓库是基于一个远程仓库克隆的,然后在这个项目中,我们需要使用另一个完全无关的项目,比如一个第三方库,然后我们就把这个第三方库的远程仓库添加到本地仓库,然后在把本地分支和该第三方库的远程仓库的某个分支合并。但想来想去,总感觉不好,非常不好,最后终于想起来,这种情况应该去使用 git 的子模块特性,然后一查笔记,果然是这样。额,我只能说这种情景想都不要想去使用远程仓库处理。

那什么才是正确的,或者说常见的在一个本地仓库中使用多个远程仓库的使用情景呢?

下面是一个例子。

我们在 Github 有一个远程项目仓库 A,然后我们打算在下个版本中给项目 A 添加一个新特性 f,然后我们发现有人 fork 了我们的项目仓库 A,并在他 fork 的这个远程仓库的基础上已经开发了特性 f,于是我们打算直接采纳这个人的代码,怎么做呢?首先我们把这个人 fork 的远程仓库加入到我们的本地仓库中,然后将这个远端仓库的特性 f 分支合并到本地分支,最后再把这个本地分支 push 到我们的远程项目仓库 A 就可以了。

说的有点简单,但这确实是在一个本地仓库中使用多个远程仓库的常见的情景之一。最后,抛开这些具体场景不谈,我觉的所有在一个本地仓库中使用多个远程仓库的正常场景应该都有一个共同点,那就是本地仓库同时使用的多个远程仓库之间的关系,这些远程仓库是源自同一个远程仓库的。这是我的理解,我相信,至少在绝大多数情况下是这样。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: