【Git版本控制 | 篇②】远程仓库

话写在最开头：

在牛某网看见了牛肉哥的帖子之后，打算向牛肉大佬学习，故开始书写优快云博客，通过博客的方式来巩固自身知识学习。
在了解Git之后，在模糊记忆中去对工具的使用做再一步的巩固，可用于查询模糊知识点使用

目录

远程仓库：

注册，创建：

配置SSH公钥：

生成SSH公钥：

获取公钥：

验证公钥：

仓库操作：

添加远程仓库：

查看远程仓库：

推送到远程仓库(PUSH)：

克隆远程仓库：

查询关联关系：

抓取远程仓库（Fetch）：

拉取远程仓库（PULL）：

解决合并冲突：

注解

远程仓库：

注册，创建：

省略......

配置SSH公钥：

SSH：是一种安全协议，用作远程连接服务器的主要手段。

生成SSH公钥：

在本地仓库打开Git Bash，输入：

ssh-keygen -t rsa

不断回车，直至显示：

获取公钥：

输入：

cat ~/.ssh/id_rsa.pub

将所获公钥复制，打开GitHub，进入个人Settings中，选择“SSH and GPG keys”进行配置SSH公钥

验证公钥：

配置完成后，在Git Bash中输入：

ssh -T git@github.com

配置完成。

仓库操作：

添加远程仓库：

git remote add 远端名称 仓库路径

远端名称： 取决于远端服务器设置 一般是origin

仓库路径：从远端服务器获取此 URL

查看远程仓库：

git remote：显示远端名称

推送到远程仓库(PUSH)：

git push [-f] [--set-upstream] [ 远端名称 [ 本地分支名 ][: 远端分支名 ] ] 

如果远程分支名和本地分支名称相同，则可以只写本地分支

-f ：强制覆盖

-- set - upstream ：推送到远端的同时并且建立起和远端分支的关联关系。

远端名称：一般是origin

克隆远程仓库：

git clone < 仓库路径 > ：将远程仓库的内容克隆到本地仓库

在克隆项目的git-log中，克隆项目多了一个origin/HEAD，这个origin/HEAD就是用来标记远程仓库默认分支的指针，比如你这里它和origin/MASTER指向同一个提交，就说明远程仓库的默认分支是master。

查询关联关系：

git branch - vv：查看分支关系关联的情况

抓取远程仓库（Fetch）：

抓取： git fetch [remote name] [branch name]

抓取所有：git fetch

抓取指令就是将仓库里的更新都抓取到本地，不会进行合并

不进行合并:如图：假如别的用户向远程仓库添加了文件4，那么使用fetch后，会把文件4纳入到origin/master中，需要进行merge来整合

拉取远程仓库（PULL）：

拉取： git pull [remote name] [branch name]

拉取所有：git pull

拉取指令就是将远端仓库的修改拉到本地并自动进行合并，等同于 fetch+merge

解决合并冲突：

冲突造成原因：一段时间里，A、B用户修改了同一文件的代码，此时会发生合并冲突。
具体：A用户在完成更新内容且推送后，B用户若想要再次去推送，是被git建议不推送的。

因为远程仓库（GitHub 上）的 master 分支有你本地仓库没有的提交记录，Git 为了防止覆盖远程的这些更改，拒绝了你的推送。

冲突解决方式：

推送的过程：先拉取远程仓库的内容，判断是否有本地仓库没有提交的记录，若有，说明有用户进行了改动，会发出CONFLICT报告

需要对指明文件进行处理，选择最终推送内容，即进行合并之后，才能推送回远程仓库。

注解：

git-log目录解释：

• 时间顺序：越晚提交的记录，在日志中位置越靠上。在分叉中则相反
• *：*是每一次的提交，后边的内容是commit时候的注解 'xxx' 
• 分叉原因：为了模拟冲突，利用本地仓库和克隆项目的Git Bash进行了操作，形成了两条独立的开发线，故发生开叉
• 合并原因：为了成功去进行push，我进行了pull，而pull相当于fetch+merge，所以进行了合并
• 颜色：为了分辨分支等功能
  • master、origin/master、origin/HEAD 都指向这个提交，说明：
  • 你本地的 master 分支已经更新到这个状态。
  • 你已经成功将这个提交推送到了远程仓库（origin/master也指向它）。
  • 远程仓库的默认分支（origin/HEAD）依然是master。