Git之5-Gitee（远程仓库）

我们之前讲的全是在本地电脑上进行的操作，那还不如不用版本控制工具，自己去控制。因此我们团队小组开发，一定要用到远程仓库，这样才能更好地进行版本控制。（不用远程仓库的话，那小组开发只能用同一个U盘，但这样又太荒谬了）。因此我们使用远程仓库gitee。

1、注册与创建远程仓库

• 常用远程仓库： - GitHub（国外的，访问速度很慢、甚至访问不到）- Gitee（国内的，访问速度快）- Gitlab（公司内，搭建的私服）
• 注册码云

• 创建远程仓库

2、配置SSH公钥

为什么要配置SSH公钥？

答：本地电脑，今后要去连接远程仓库。而登录远程仓库时，需要输入账号和密码。因此我们从本地电脑向远程仓库推送/拉取代码时，就必须得先登录，这样就十分不方便。

    因此正规的解决方案是：在本地电脑上，下载一个远程仓库的公钥，有了这把钥匙，以后就不需要账号密码，就能在本地电脑连接远程仓库了。

    说白了就是，这个公钥，以后就当做账号、密码来使用了，方便我们本地电脑连接远程仓库。

• ①产生公钥：ssh-keygen -t rsa "邮箱地址"（这个邮箱地址之前在本地电脑的git设置过）

• ②查看公钥：cat ~/.ssh/id_rsa.pub

• ③复制公钥到gitee个人设置：

• ④验证公钥是否生效：ssh -T git@gitee.com

3、添加与推送远程仓库

• 添加远程仓库（添加完远程仓库，本地git就知道要操作哪个远程仓库了）

    git remote add origin git @gitee.com:jingangbo/gitstore.git
  

• 查看远程仓库

    git remote
  

• 推送代码到远程仓库

    git push origin master : master
  

    刷新gitee的对应仓库，看看是否有代码文件

• 建立关联（是为了直接推送代码） - git push --set-upstream origin master- - git branch -w （查看关联）- - git push （建立好关联以后，直接可以推送） -

    下面就去远程仓库gitee上，去查看：
  

4、推送远程仓库dev分支

• 远程仓库创建dev分支

查看刚创建的分支：

可见这个dev分支，拥有那个时刻master分支的全部内容。

• git push origin dev（推送代码到远程仓库的dev分支）

推送前，我们要观察本地git的dev分支，是否缺少远程仓库的dev分支中的某个文件：

此时我们就不能直接从本地git，直接推送文件到远程仓库的dev分支上，肯定会报错，如下：

因此，此时我们就需要先将远程仓库的dev分支的代码，全部拉取到本地git的dev分支上，再推上去：

此时就不缺少文件了，此时直接将本地git的dev分支的代码，推送到远程仓库的dev分支即可：

以上就是推送代码到远程仓库的dev分支上的全部流程。

5、克隆与拉取远程仓库

• 克隆（只会克隆远程仓库的master分支）

    git clone 仓库路径 本地目录
  
    ①本地仓库打开git控制台
  

    ②获取远程仓库的地址

• 抓取与合并（不常用，因此就不演示了）

    git fetch origin master
  
    抓取指令就是将仓库里的更新都抓取到本地，不会进行合并（你只抓取下来远程仓库的代码，而不合并它们，这就显得很鸡肋。因此我们很少用这个fetch命令。因此我们常用下面的pull命令，它就等同于fetch+merge（合并））。
  
    如果不指定远端名称和分支名，则抓取所有分支。
  

• 拉取（常用，而且会将拉取到的分支代码，自动合并到本地git的主分支）

    git pull origin master（将远程仓库的代码，拉取到本地仓库）
  
    拉取指令就是将远程仓库的修改拉到本地并自动进行合并，等同于fetch + merge
  
    如果不指定远端名称和分支名，则抓取所有并更新当前分支
  

举例：在git-test中，向远程仓库的dev分支推送一个新文件post.txt（岗位功能）

查看远程仓库的dev分支，是否更新了该文件：

可见确实更新了该文件，那么接下来就需要在本地的git-test2中，拉取远程仓库的dev分支中的最新代码：

查看本地的git-test2中，是否更新了post.txt文件：

可见，我们明明拉取的是远程仓库的dev分支，但是此时本地git的主分支也更新了，说明pull命令的特点就是：自动将拉取到的分支代码合并到本地git的主分支master上。

6、解决合并冲突

• 冲突原因：不同的人，对同一处地方编写了不同的代码。
• 解决方案：类似于分支冲突的解决方案，人为判断冲突的地方应该如何写代码。

模拟合并冲突：

这样一来，二者都对log.txt文件做了编写，并推送到了远程仓库的dev分支上，此时就一定会产生冲突。

具体操作过程如下：

①在git-test文件夹（小明负责）下，做如下操作：

查看远程仓库的dev分支下的log.txt的内容：

②在git-test2文件夹（小李负责）下，做如下操作：

下面查看一下远程仓库的dev分支中的log.txt文件是否得到更新：

③此时小明（git-test文件夹），应该拉下来远程仓库的dev分支的代码（也得到一下更新）：

最终得到的结论：

文件推送时，发生冲突的话，就先将远程仓库的代码拉下来，再人为手动解决冲突即可，再推送上去即可。

即：发生冲突以后，也需要人为手动解决，因为代码是人写的，计算机也不知道留哪一段代码，怎么取舍，因此只能靠人为手动解决冲突。