Learn Git Branching 学习笔记（Git远程仓库篇）

目录

一、Git远程仓库篇

1.git clone 在本地创建一个远程仓库的拷贝       

2.远程分支

3.git fetch

4.git pull     

5.模拟团队合作

6.git push

7.远程库提交历史的偏离    

8.远程服务器拒绝!(Remote Rejected)

---

Git的高级话题集合在上一篇文章中Learn Git Branching 学习笔记（高级话题篇）_流年--by gone的博客-CSDN博客

这篇文章主要介绍git的远程仓库用法。

一、Git远程仓库篇

       远程仓库并不复杂，在如今的云计算盛行的世界很容易把远程仓库想象成一个富有魔力的东西，但实际上它们只是你的仓库在另个一台计算机上的拷贝。你可以通过因特网与这台计算机通信－也就是增加或是获取提交记录。

       话虽如此，远程仓库却有一系列强大的特性

• 首先也是最重要的的点，远程仓库是一个强大的备份。本地仓库也有恢复文件到指定版本的能力，但所有的信息都是保存在本地的。有了远程仓库以后，即使丢失了本地所有数据，你仍可以通过远程仓库拿回你丢失的数据。
• ·还有就是，远程让代码社交化了！既然你的项目被托管到别的地方了，你的朋友可以更容易地为你的项目做贡献（或者拉取最新的变更）
• 现在用网站来对远程仓库进行可视化操作变得越发流行了（像 GitHub），但远程仓库永远是这些工具的顶梁柱，因此理解其概念非常的重要！

       直到现在，教程都聚焦于本地仓库的操作（branch、merge、rebase 等等）。但我们现在需要学习远程仓库的操作 －我们需要一个配置这种环境的命令，它就是git clone。从技术上来讲， git clone 命令在真实的环境下的作用是在本地创建一个远程仓库的拷贝（比如从 github.com）。 但在我们的教程中使用这个命令会有一些不同——它会在远程创建一个你本地仓库的副本。显然这和真实命令的意思刚好相反，但是它帮咱们把本地仓库和远程仓库关联到了一起，在教程中就凑合着用吧。

1.git clone 在本地创建一个远程仓库的拷贝       

       现在我们有了一个自己项目的远程仓库。除了远程仓库使用虚线之外，它们几乎没有什么差别——在后面的关卡中，将会学习怎样在本地仓库和远程仓库间分享工作成果。

       先看看远程仓库的样子。

题目：

答案：

git clone

2.远程分支

       在我们的本地仓库多了一个名为 origin/master 的分支, 这种类型的分支就叫远程分支。远程分支有一个特别的属性，在你检出时自动进入分离 HEAD 状态。
       Git 这么做是出于不能直接在这些分支上进行操作的原因, 你必须在别的地方完成你的工作, （更新了远程分支之后）再用远程分享你的工作成果。

       你可能想问这些远程分支的前面的o/是什么意思呢？好吧，远程分支有一个命名规范——它们的格式是： <remote name>/<branch name>

       因此，如果你看到一个名为 o/main的分支，那么这个分支就叫 main，远程仓库的名称就是o。大多数的开发人员会将它们主要的远程仓库命名为origin，并不是o。这是因为当你用 git clone某个仓库时，Git 已经帮你把远程仓库的名称设置为 origin了。

       不过 origin对于我们的UI来说太长了，因此不得不使用简写o，但是要记住，当你使用真正的Git 时，你的远程仓库默认为 origin。

       说了这么多，让我们看看实例。

     如果检出远程分支会怎么样呢？

    输入git checkout origin/master、git commit

       正如你所见，Git 变成了分离 HEAD 状态，当添加新的提交时 origin/master 也不会更新。这是因为 origin/master 只有在远程仓库中相应的分支更新了以后才会更新。

题目：

       要通过本关，在main分支上做一次提交，然后检出o/main，再做一次提交，这有助于理解远程分支的不同，他们的更新只是反映了远程的状态。

   答案：

git commit
git checkout o/main
git commit

3.git fetch

       Git 远程仓库相当的操作实际可以归纳为两点：向远程仓库传输数据以及从远程仓库获取数据。既然我们能与远程仓库同步，那么就可以分享任何能被 Git 管理的更新（因此可以分享代码、文件、想法、情书等等）。

       本节课我们将学习如何从远程仓库获取数据－命令如其名，它就是 git fetch

       你会看到当我们从远程仓库获取数据时，远程分支也会更新以反映最新的远程仓库。在上一节课程中我们已经提及过这一点了。

       在解释 git fetch前，我们先看看实例。这里我们有一个远程仓库，它有两个我们本地仓库中没有的提交。

输入 git fetch

       C2,C3被下载到了本地仓库，同时远程分支o/main也被更新，反映到了这一变化。

       git fetch完成了仅有的但是很重要的两件事：从远程仓库下载本地仓库中缺少的提交记录，更新远程分支指针(如 o/main)。

       git fetch实际上将本地仑库中的远程分支更新成了远程仓库相应分支最新的状态。

       如果你还记得上一节课程中我们说过的。远程分支反映了远程仓库在你最后一次与它通信时的状态。

       git fetch 就是你与远程仓库通信的方式了！希红我说的够明白了，你已经了解git fetch与远程分支之间的关系了吧。

       git fetch通常通过互联网（使用http://或git://协议）与远程仓库通信。它不会改变本地仓库的状态，不会更新你的 master 分支，也不会修改你磁盘上的文件。

       理解这一点很重要，因为许多开发人员误以为执行了 git fetch 以后，他们本地仓库就与远程仓库同步了。它可能已经将进行这一操作所需的所有数据都下载了下来，但是并没有修改你本地的文件。所以, 你可以将 git fetch 的理解为单纯的下载操作。

 题目：

 答案：

git fetch

4.git pull     

       用git fetch 获取远程的数据,再将这些变化更新到我们的工作当中。

       当远程分支中有新的提交时，可以像合并本地分支那样来合并远程分支，也就是说可以执行以下命令：

• git cherry-pick o/master
• git rebase o/master
• git merge o/master等等

       由于先抓取更新再合并到本地分支，这个流程很常用，因此 Git 提供了一个专门的命令来完成这两个操作。它就是 git pull。

       我们先看fetch、merge依次执行的效果。

 输入git fetch、git merge o/main

       用fetch下载了C3，然后通过git merge o/main合并了这一提交记录，现在我们的main分支包含了远程仓库中的更新（在本例中远程仓库名为origin）。

       若使用git pull，则图示为同样的，git pull就是git fetch和git merge的缩写。

       题目同上，答案为git pull。

5.模拟团队合作

       fackTeamwork默认操作就是在远程仓库的main分支上做一次提交。

 git fackTeamwork

       远程仓库增加了一个新提交，我们还没有下载它，因为我们还没有执行git fetch。可以指定提交的分支或是数量，只需要在命令后加上它们就可以了。

    输入git fackTeamwork foo 3

       通过一个命令，我们就模拟队友推送了三个提交记录到远程仓库的foo分支。

题目：

       克隆一个远程仓库（用 git clone），再在刚创建的远程仓库中模拟一些修改，【模拟远程修改指令git fackTeamwork <分支名><提交次数>】然后在你自己的本地分支上做一些提交，再拉取远程仓库的变更。这看起来像是包含了好几节的课程。

   答案：

git clone   //local branch "master" set to track remote branch "o/master"
git fakeTeamwork main 2
git commit
git fetch
git merge o/main

6.git push

       git push 负责将你的变更上传到指定的远程仓库，并在远程仓库上合并你的新提交记录。可以将 git push 想象成发布你成果的命令。

        注意 —— git push 不带任何参数时的行为与 Git 的一个名为 push.default 的配置有关。它的默认值取决于你正使用的 Git 的版本，但是在教程中我们使用的是 upstream。这没什么太大的影响，但是在你的项目中进行推送之前，最好检查一下这个配置。

 输入 git push

        远程仓库接收了 C2，远程仓库中的 main 分支也被更新到指向 C2 了，我们的远程分支 (o/master) 也同样被更新了。所有的分支都同步了！

 题目：

       要完成本关，需要向远程仓库分享两个提交记录。

  答案：

git commit
git commit
git push

7.远程库提交历史的偏离    

       假设你周一克隆了一个仓库，然后开始研发某个新功能。到周五时，你新功能开发测试完毕可以发布了。但是你的同事这周写了一堆代码，还改了许多你的功能中使用的 API，这些变动会导致你新开发的功能变得不可用。但是他们已经将那些提交推送到远程仓库了，因此你的工作就变成了基于项目旧版的代码，与远程仓库最新的代码不匹配了。

       这种情况下, git push 就不知道该如何操作了。如果你执行 git push，Git 应该让远程仓库回到星期一那天的状态吗？还是直接在新代码的基础上添加你的代码，亦或由于你的提交已经过时而直接忽略你的提交？

       因为这情况（历史偏离）有许多的不确定性，Git 是不会允许你 push 变更的。实际上它会强制你先合并远程最新的代码，然后才能分享你的工作。

       输入git push什么都没变，因为命令失败了，git push失败是因为最新提交的C3基于远程分支中的C1。而远程仓库中该分支已经更新到C2了，所以Git拒绝了推送请求。

       需要做的就是使自己的工作基于最新的远程分支，最直接的方法就是通过rebase调整工作。

       输入git fetch 、git rebase o/main、git push

        用 git fetch 更新了本地仓库中的远程分支，然后用 rebase 将工们的工作移动到最新的提交记录下，最后再用 git push 推送到远程仓库。

        其它的方法，merge。尽管 git merge 不会移动你的工作（它会创建新的合并提交），但是它会告诉 Git 你已经合并了远程仓库的所有变更。这是因为远程分支现在是你本地分支的祖先，也就是说你的提交已经包含了远程分支的所有变化。

输入git fetch、git merge origin/master、git push

        git fetch 更新了本地仓库中的远程分支，然后合并了新变更到我们的本地分支（为了包含远程仓库的变更），最后我们用 git push 把工作推送到远程仓库

• 简化操作：

       git pull 就是 fetch 和 merge 的简写，git pull --rebase 就是 fetch 和 rebase 的简写！

题目：

 答案：

git clone
git fakeTeamwork
git commit
git pull --rebase
git push

8.远程服务器拒绝!(Remote Rejected)

       如果你是在一个大的合作团队中工作，很可能是main被锁定了，需要一些Pull Request流程来合并修改。如果你直按提交(commit）到本地main，然后试图推送(push)修改，你将会收到这样类似的信息：

      ！[远程服务器拒绝〕main (TF402455：不允许推送 (push)这个分支：你必须使用pull request来更新这个分支)

       远程服务器拒绝直接推送(push)提交到main，因为策略配置要求pull requests 来提交更新。应该按照流程，新建一个分支，推送(push)这个分支并申请pull request，但是你志记并直接提交给了main，现在你卡住并且无法推送你的更新。

        解决办法：新建一个分支feature，推送到远程服务-器．然后reset你的main分支和远程服务器保持一致，否则下次你pull并且他人的提交和你冲突的时候就会有问题。

   题目：       

   答案：

git reset --hard o/main    //在本程序中默认的行为是 --hard 硬重置，可以尽情省略掉那个选项以避免麻烦！但是要记录 Git 中默认的是 --mixed。
git checkout -b feature C2
git push origin feature

Git远程仓库篇完结撒花~