一、原理和用途

本质：

远程文档库 vs 本地文档库，即 库与枯库之间，基于相同branch的merge（rebase）操作的 clone和经SCM批准的相互更新

        相比 库内分支之间：checkout ( -b ) / merge （无须认证）

        库与库之间：pull / push （须认证）

            push是唯一一个在本地 修改远程文档库数据的命令：git push / git push --delete

            pull = fetch + merge

            push之前要先pull，以此确保，push最终在远程文档库端造成的merge是FF类型的merge。

为什么用专用的远程文档库：

    A. 系统安全：不想协同开发者为了branch新分支，而登录我的开发系统，所以需要共用的远程文档库

    B. 文档库安全： 如果把我的本地文档库兼作共用的远程文档库，那么别人的push会企图改变我的文档库。文档库是本地开发的追踪基线，不应该由本地SCM之外的任何人、系统作库的整体更新。

        coder编辑本地working directory <-->通过git<-->  更新本地文档库 -<->通过git<-->  更新远程文档库

                |                                                                 |                                                  |

          开发者 base IDE                              SCM base GIT                         SCM base git(+git server admin)

特征：

远程文档库不是working directory的“附属” .git 子目录，也没有working directory存在的意义，因为它不直接面对开发者。

它本身是一个孤立的目录：<文档库名字>.git

因此，它叫bare类型文档库，创建时声明 ：  --bare

二、用法

本地文档库和远程文档库之间的三重联系：

A. 双向的数据（有效代码）的同步

B. 在本地文档库，注册属性 -- 远程文档库url ： 

        remote.<远程文档库名字>.url = <远程文档库的https或ssh路径>

                * https：https://web_server_IP/库的路径

                   ssh:    gitaccount@ssh_server_ip:库的路径

                * 远程文档库名字，在默认注册属性时，叫origin

        对应命令： git remote add

C. 在本地文档库，注册属性 -- 分支追踪信息：

        branch.<分支名称>.remote = <远程文档库名字>

        branch.<分支名称>.merge = refs/heads/<对应的远程文档库中的分支的名字>

                * master分支，会默认注册，

        对应命令： git remote update 、git push --upstream  

所有的操作都是对针对这三重联系

管理命令

1. 创建远程文档库，并clone的两种方法，实现A+B的联系：

    method a. 从远程文档库所在系统A创建，然后复制到本地系统B一个本地文档库：

        step1. [serverA] # git init --bare  <远程文档库名字>.git

        step2. [serverB] # git clone  <远程文档库的https或ssh路径>   <本地文档库的名字>          // 如果不指定本地名字，默认与远程文档库同名。此处，建立了A+B的联系

     method b. 从本地系统B的文档库 复制出远程文档库到系统A：

        step1. [serverB] # git clone --bare <本地文档库的working directory文件夹名字>    <远程文档库的https或ssh路径>                    此处，建立了A的联系。却没有任何操作帮助“子”注册得到父的信息，需要手工建立B的联系：

        step2. [serverB] # git remote add  <远程文档库名字>  <远程文档库的https或ssh路径>        此处，建立了B的联系

                * 库名随意，不一定叫origin。

    * 支持一个本地文档库有多个远程文档库  

        How？代码人格分裂？？我可以想出的应用场景：

        远程文档库fork出另一个远程文档库，用于不同的项目组后续开发。然鹅，一个coder给两个项目共用（悲催）。她本地的文档库，必然有两个分支，对应两个项目的新功能。代码共享相同的base代码，她的代码贡献commit到同一个本地版本库，但却push到不同的远程版本库对应的分支上。

        git remote add  <远程文档库名字1>  <远程文档库1的https或ssh路径>

        git remote add  <远程文档库名字2>  <远程文档库2的https或ssh路径>     //注册多个远程文档库url，即建立B联系

        远程版本库注册信息，记录在本地版本库的配置里 :

            git ls-remote             查看所有远程库list

            git remote -v             列出本地全部的和远程库相关的config

            git remote show <远程文档库名字>            列出这个远程库的具体信息

    * 要改变某注册的过的远程库的url

        git remote set-url <远程文档库名字>  <远程文档库新的https或ssh路径>

    * 添加过的远程库，要从注册信息中删掉或者改名字。A+B的信息会被一起更新：

        git remote rm   <远程文档库名字>            //取消这个远程库，是git remote add + git remote update的逆

        git remote rename  <旧的远程文档库名字>  <新的远程文档库名字>        //更改这个远程库的名字

2. 建立分支追踪信息，实现C联系：

    master分支追踪信息是默认建立的

    情景 1. 对于新建的分支：

        git push --up-stream <远程版本库名字>  <对应的远程文档库中的分支的名字> 

    情景 2. 对于所有的固有分支：

        git remote update

    建立的分支追踪信息记录在本地版本库的配置里 （git config -l | grep <分支名称>）

    * C联系的效用：

       1. 有多分支时，git push的发起者，本意只是提交某些或某个分支。使用：

            git push <远程版本库名字> <对应的远程文档库中的分支的名字>

            根据已注册的分支追踪信息，git确定出 发起者要push的是哪个本地分支的变更。

        2. 服务懒人，当他的命令是简单的: git push

            git push --all        忽略config值，所有注册过的分支都会被push

            没有--all，效用取决于 git config -l | grep push.default：

            （1）push.default=simple        --> 当前checkout分支，如果被注册过，push当前分支

            （2）push.default=matching    -->  所有被-u push过的分支，都会被push

                    这是一个危险的动作。所以建议：git config --global push.default simple

        * 查看所有注册过的远程对应分支

            git branch -a

3. 有效代码的双向同步（A联系）：

    1. 下载（更新本地文档库） = 从 远程版本库  取回当前本地所在分支 对应的分支  的head版本的数据，并在本地发生merge或rebase操作 （更新本地commit演进图）

        git pull = git fetch <远程文档库的名字>/<远程文档库对应的分支> + git merge  <远程文档库的名字>/<远程文档库对应的分支>

        git pull --rebase = git fetch <远程文档库的名字>/<远程文档库对应的分支> + git rebase <远程文档库的名字>/<远程文档库对应的分支>

    2. 解决冲突  = 使之后的push，在远程版本库发生FF合并

    3. 上载 （更新远程文档库） 

        git push = 从 本地版本库  取出当前分支的HEAD版本数据，  提交到远程版本库，远程版本库发生FF merge。

        git push -u <远程库的名字> <远程库对应的分支名字>

        git push <远程库的名字> <远程库对应的分支名字>

        git push            // push.default=simple的情况

三、文档库的fork

1. 库内的branch，类比库级别的fork: 

    branch可以:                被动merge回master、                    或rebase  master的新HEAD

    fork出的文档库可以:    主动请求pull request合并回源文档库、或rebase 源文档库的HEAD

2. fork不是git-native的操作。所以只能在github、gitlab上点按钮了。

3. pull request操作需要源库的批准，才能被合并到源库。