Git Step by Step – (6) Git远程仓库

前面文章中出现的全部Git操做都是基于本地仓库的，可是平常工做中须要多人合做，不可能一直都在本身的代码仓库工做。因此，这里咱们就开始介绍Git远程仓库。

在Git系统中，用户能够经过push/pull命令来推送/获取别的开发人员的更新，当时对于一个工做组来讲，这种方式会效率比较低。因此，在一个Git系统中，都会有一个中心服务器，你们都经过中心服务器来推送/获取更新。

为了方便本篇例子的进行，我就使用多个目录来模拟多个用户以及中心服务器，这样就不用搭建Git服务器了。

• 中心服务器：C:\VM\CentralRepo
• 用户wilber：C:\VM\wilberWorkSpace
• 用户will：C:\VM\willWorkSpace

 

Git远程仓库命令

创建中心服务器

经过前面的文章咱们知道能够经过"git init"来创建一个Git仓库，这里，咱们使用"git init --bare"来创建中心仓库，注意"--bare"参数，后面进行介绍。

到这里，一个空的中心服务器就建好了。

Clone一个仓库

在Git中，咱们有两种方式创建Git仓库：一个是经过"git init"创建一个新的仓库，另外一个是经过"git clone"命令clone一个已有的Git仓库。

既然中心服务器，用户will就能够经过clone命令来复制一个Git仓库。

从上面的clone操做能够看到，在clone命令中须要给出目标仓库的地址，Git支持http、ssh以及git原生协议来进行clone。这里为了演示，咱们就使用本地目录。

这时，用户will就从中心服务器clone了一个空的仓库，接下来will就能够在这个本地仓库工做了。

更新的push和pull

如今will在本地仓库中添加了一个"calc.py"的文件，而且提交到了本地仓库。

为了是其余用户能够获得这个更新，will须要把这个更新push到中心服务器上。

如今用户wilber经过clone方式得到了中心服务器上的仓库副本，经过"git log"will的更新已经自动被clone了下来。

如今，wilber提交了一个新的更新，那么will就能够经过pull的方式从中心服务器获得这个更新。

--bare

如今咱们看看创建中心服务器时候用到的"--bare"选项。

"git init --bare"方法建立的是一个裸仓库，之因此叫裸仓库是由于这个仓库只保存Git历史提交的版本信息，而不容许用户在上面进行各类git操做。

之因此有裸仓库，是由于用"git init"初始化的版本库，用户也能够在该目录下执行全部git方面的操做。但别的用户在将更新push上来的时候容易出现冲突。在这种状况下，最好就是使用"--bare"选项创建一个裸仓库。

上游仓库(upstream repository)

在Git系统中，一般用"origin" 来表示上有仓库。咱们能够经过 "git branch -r"命令查看上游仓库里全部的分支，再用 origin/name-of-upstream-branch 的名字来抓取(fetch)远程追踪分支里的内容。

从上面能够看出，对于wilber的仓库，master分支的上游分支是中心服务器的master分支。

经过上一篇文章的内容，咱们能够在中心服务器上创建两个新的"release-1.0"和"release-1.1"分支，经过pull命令，用户wilber就看到了这些上游分支。

--set-upstream-to

当咱们至关然的按照前一篇文章在本地仓库创建一个branch的时候，咱们的pull操做会遇到如下问题，提示咱们这个branch没有任何的跟踪信息。仔细想一想也是，咱们应该把本地仓库中的分支与上游分支关联起来。这时，咱们就能够根据Git的提示，使用"--set-upstream-to"命令进行关联了。

固然，在Git中咱们能够直接经过"git checkout -b localBranchName origin/remoteBranchName"来建立关联分支。建议通常把"localBranchName"名称跟"remoteBranchName"名称设置成同样。

 

牛叉的patch

在Git中patch绝对是一个颇有用的东西。假设在一个没有网络的环境中，wilber和will还要继续工做，这时wilber有一个更新，will须要基于这个更新进行下一步的工做。若是是集中式的代码版本工具，这种状况就没有办法工做了，可是在Git中，咱们就能够经过patch的方式，把wilber的更新拷贝给will。

在Git中有两种patch的方式：一是经过"git diff"生成一个标准的patch，另外一个是经过"git format-patch"生成一个Git专用的patch。

基于"git diff"的patch

假设如今wilber更新"calc.py"文件而且经过"git diff"生成了一个patch。

下面，咱们把wilberPatch这个文件拷贝到will的工做目录中，而后经过"git apply"应用这个patch，从而获得wilber的更新。

基于"git format-patch"的patch

一样使用上面的例子，此次咱们使用"git format-patch"来生成patch。

注意"git format-patch"命令的参数"origin/master"，这个参数的含义是，找出当前master跟origin/master之间的差异，而后生成一个patch。

把patch文件拷贝到will的工做目录，则此咱们经过"git am"命令来应用这个patch。

两种patch方式的比较

下面简单看看两种patch方式的比较。

• patch兼容性："git diff"生成的patch兼容性强。也就是说，若是别人的代码版本库不是Git，那么必须使用git diff生成的patch才能被别的版本控制系统接受。
• patch合并提示：对于"git diff"生成的patch，你能够用git apply --check 查看patch是否可以干净顺利地应用到当前分支中；若是"git format-patch" 生成的patch不能打到当前分支，git am会给出提示，帮你解决冲突，二者都有较好的提示功能。
• patch信息管理：经过"git format-patch"生成的patch中有不少信息，好比开发者的名字，所以在应用patch时，这个名字会被记录进版本库，这样作是比较合理的。

 

总结

经过这篇文章，咱们了解了远程仓库的命令以及操做。其实，这才是Git中最多见的工做方式，你们都经过中心服务器来交换跟新。

同时，咱们见识到了Git的patch工具，patch也是一种很经常使用的交换更新的方式。