Git的使用总结（三）

3.远程仓库

若只是对比管理文件的历史的话，那么混帐与SVN是没有什么差别的git的的优势在于远程仓库。

可以在一台电脑上克隆多个仓库，不过一般不这么做，因为在一台电脑上搞好几个远程是没有意义的，而且硬盘挂了的话所有的库都会挂掉。实际情况往往是这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

可以搭一个运行的混帐的服务器。不过，有一个GitHub的上的网站，它是提供的Git的仓库托管服务的。只要注册一个GitHub上的账号，就可以免费获得的Git的远程仓库。

由于本地仓库与GitHub上的仓库的传输是通过SSH加密的，所以要事先设置一下。

设置步骤：1）创建SSH Key.2）添加。

（1）添加远程库

在本地创建一个GitHub上的仓库，又想在GitHub上的上创建一个混帐的仓库，实现这两个仓库的远程同步步骤如下：

1）要关联一个远程库，使用命令

$git remote add origin git@server-name:path/repo-name.git

2）关联后，使用命令

$git push -u origin master

第一次推送主分支的所有内容（我们第一次推送master分支时，加上了-u参数，GIT会把中不但本地的master分支内容推送的远程新的master分支，还会把本地的master分支状语从句：远程的master分支关联起来，在以后的推送或者拉取时就可以不用添加-u。）之后，每一次就可以使用命令git push origin master来推送最新修改。

对比发现：！分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的当有网络的时候，再把本地提交推送一下就完成了同步。

（2）从远程库克隆

从远程库克隆到本地库要注意：

1）必须知道仓库的地址，然后使用git clone命令克隆;

2）Git支持很多种的协议，默认的git：//使用的是SSH，但也支持https等协议。

通过ssh请|立即iTunes的电子杂志原的生git协议速度最快。使用https除了速度慢以外，还有个最大的麻烦的英文每次推送都必须输入侧侧口令，但是在某些只开放HTTP端口的公司内部就无法使用ssh协议而只能用https。

4.分支管理

混帐的分支：你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

其他版本控制系统，如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。

（1）创建于合并分支

主分支：主分支，HEAD指向的是当前分支。

创建分支：

$git branch <name>

切换分支：

$git checkout <name>

创建并切换分支：

$git checkout -b <name> 

查看分支：

$ git branch

合并分支：

$git merge <name>

命令用于合并指定分支到当前分支。查询查询查询查询结果中有Fast-forward信息，GIT中会告诉我们，这次合并是“快进模式”，就是也。把直接master指向dev的当前提交，所以合并速度非常快。当然，也不是每次合并都能Fast-forward，还有其它方式的合并。

删除分支：

$git branch -d <name>

注：因为创建，合并和删除分支非常快，所以GIT中的鼓励你使用分支完成某个任务，合并后再删掉分支，状语从句：直接这在master分支上工作效果的英文一样的，但过程更安全。

（2）解决冲突

master状语从句：分支新建的feature1。分支各自都分别有新的提交，在这种情况下的混帐无法实现“快速合并”，只能把各自的修改合并起来，这种但合并会有冲突在这种情况下，需要：

先解决冲突，之后再提交，合并完成。解决冲突的方式：是把Git合并失败的文件手动编辑为我们希望的内容，再提交。使用git log --graph命令看到分支合并图。

（3）分支管理策略

对于之前的合并来说，使用的是快进模式。但是，在这种模式下当删除分支时会丢失分支的信息。若一定要禁用快进模式，采用可以加上--no-ff参数的方式，这样就可以用普通模式合并的git的会在合并时生成一个新的承诺，从分支信息上可以看出分支。

注：master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活;

       干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本团队分支图如下所示：

（4）错误分支

每个错误都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你接到一个修复一个代号101的错误的任务时，很自然地，想你创建³³分支一个issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交。并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作。

当手头工作没有完成时，先把工作现场git stash一下，然后去修复的BUG，修复后，再git stash pop，回到工作现场。

GIT中把藏匿内容存在某个地方了，但是需要恢复一下，有两个办法：一是用git stash apply恢复，但是恢复后，藏匿内容并不删除，你需要用git stash drop来删除;另一种方式是用git stash pop，恢复的同时把藏匿内容也删了。

（5）功能分支

每添加一个新功能，最好新建一个功能分支，在上面开发，完成后，合并，最后，删除该功能分支。

如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

（6）多人协作

1）远程仓库的默认名称是原点。

2）并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

一个主分支是主分支，因此要时刻与远程同步。

Taiwan dev的分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步;

C.错误分支只用于在本地修复错误，就没必要推到远程了，除非老板要看看你每周到底修复了几个错误;

d。设有分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

3）多人协作的工作模式通常是这样：

一个首先，试图可以用。git push origin <branch-name>推送自己的修改;

台湾如果推送失败，则因为远程分支比你的本地更新，先需要用git pull试图合并如果。git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>;

C.如果合并有冲突，则解决冲突，并在本地提交;

d。没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功。

4）查看远程库信息，使用git remote -v;

     本地新建的分支如果不推送到远程，对其他人就是不可见的;

     在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致（即branch-name应该是一致的） ;

     建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name;

     从远程抓取分支，使用git pull，如果有冲突，要先处理冲突（见3））。

（7）再次基于

即使没有冲突，后推的童鞋不得不先拉，在本地合并，然后才能推动成功。每次合并再推后，分支总之看上去很乱。现在，想要将提交历史变为一条干净的直线，可以采用rebase的操作（也被称为“变基”）。

rebase操作可以达到这一作用的原因在于： Git把我们本地的提交“挪动”了位置，放到了f005ed4 (origin/master) set exit=1之后，这样，整个提交历史就成了一条直线.rebase操作前后，最终的提交内容是一致的，但是，我们本地的承诺修改内容已经变化了，它们的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，求最后是什么意思？但提交的7e61ed4内容的英文和睦和谐的。

变基操作可以把本地未推的分叉提交历史整理成直线，看上去更直观。缺点是本地的分叉提交已经被修改过了（见上段内容）。