Git学习（一）：Git介绍、仓库和分支等基本概念解释

一、 Git介绍

二、 关于git仓库和分支的解释

1 仓库

2 分支

3 例子解释

4 本地与远程建立联系 

5 git merge命令解释

6 Merge Request解释

7 尽量避免冲突的做法

8 Upstream概念及使用

9 分支类型解释以及git pull

参考自： https://blog.csdn.net/xiaoxuantengkong/article/details/41211315

Git 是一个快速、可扩展的分布式版本控制系统，它具有极为丰富的命令集，对内部系统提供了高级操作和完全访问。

Git 像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照 的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。Git 的工作方式就像下图所示：

对于任何一个文件，在 Git 内都只有三种状态：已修改（modified），已暂存（staged）和已提交（committed）。

由此我们看到 Git 管理项目时，文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。

重点参考下面的博客连载（讲解得十分通俗易懂）：https://blog.csdn.net/xiaoxuantengkong/article/details/45231331

如果我们使用Git Bash进入一个目录（比如：D：/test/），在这个目录下执行git init命令，就会在这个目录建立一个Repository（仓库），这个仓库就是我们被Git管理的仓库了，如果你在这个目录下做什么操作，都是可以通过Git进行管理的。

比如你新建了一个文件TestFile.txt，那么通过git add TestFile.txt命令就可以把这个文件加入Git的暂存区，再通过git commit -m"增加一个文件TestFile.txt"命令就能够彻底将这个文件纳入Git管理了。

当建立一个Repository后，Git会默认为我们建立一个master分支的，我们默认的是在这个名字叫做master的分支上进行操作。

当然，我们可以通过git branch testbranch命令建立一个名字叫做testbranch的分支，这个分支是基于你当前的分支创建的，也就是说，你当前如果处于master分支的话，如果你建立了testbranch分支，那么testbranch分支里的内容会和你在master分支里commit进去的内容是一样的，testbranch里同样会有刚才我commit进的TestFile.txt文件。

我们可以通过git checkout master和git checkout testbranch命令在两个分支上来回切换，切到哪个分支上你的文件目录就会变成哪个分支上的内容。（git checkout -b testbranch2 命令相当于git branch testbranch2+git checkout testbranch2两个命令）。

假设远程（公司）的服务器上有个仓库Repository，这个项目包含了一个master分支，一个TestA分支，一个TestB分支。我们开发项目时，在自己电脑上直接把项目clone到本地，那么我们的电脑上也会出现一个同样的Repository，同样包括一个master分支，一个TestA分支，一个TestB分支。

目前能了解到的已经有6个分支了，远程有三个，你本地也有三个。为了方便区分，后面我会把本地分支后面加一个（L）。那么当我们使用git checkout master命令的时候，其实我们是在本地切换到了master(L)分支上，要记住哦，我们是不可能切换到远程上的分支的哦，那不是你的Repository~

下面就轮到git pull和git push出场了。

如果我们git checkout TestA之后会切换到TestA(L)分支上，如果我们做了一些改动，git add和git commit之后，意思是讲这些改动提交到了TestA(L)分支中，而远程的TestA分支还是原来的那个样子，如果你想让远程的TestA分支也变成你改动之后的样子，那就会用到git push命令了。当然这里是不出意外的情况，因为大概是在1.9.2之后的Git版本中，Git默认的push方式改成了simple方式，个人比较建议这种方式（即从哪里pull过来，我就push回哪里去）。

可以通过命令git config push.default查看你当前的push方式，可以通过git config --global push.default simple命令把你全局的push方式设置成simple方式的。其它方式读者可以自行搜索在此不再赘述。

所以总结一下，一般情况下，如果你checkout到了TestA(L)分支上执行git pull命令，就会把远程Repository中TestA分支中的内容更新到你本地的TestA(L)分支中；push命令同理。

remote即远程。比如你公司使用Stash管理项目时，你们公司的Stash服务器就是你的remote端；比如你使用Github管理自己的项目时，Github端就是你的remote端。其实你的本地库Repository可以同时对应到很多remote端的哦~也就是说你可以把你本地的库push到任何几个你有权限的remote端！这一点amazing，但是一开始不建议大家这么做，等以后越来越熟悉了再涉足这方面省着出乱子~下面就先对一个本地库对应到一个remote端来进行分析。

就Github进行举例吧，如果我们要在Github这个服务器上维护一个自己的项目，或者叫Repository。首先，我们在Github上用自己的账号新建一个Repository（这个步骤直接上Github按照说明做，简单的几步操作即可完成），建立完成后Github会给我们一个地址（这里的地址其实有两种，一种是SSH的一种是HTTPS的，建议大家直接用HTTPS的比较方便），如https://balabala/testproject。此后就代表Github已经为你在服务器端开辟了一个Repository，而那个地址就是指向这个Repository的。显然，目前这个Repository还是个空的库，里面什么东西都没有，顶多有个说明文件README。

目前，我们仅仅是在服务器上有了一个空仓库，而我们的本地还什么都没做、什么都没有。而我们要实现的状态是：在服务器上的仓库中有我们的项目，在我们本地也有一份同样的项目，并且两者是相互“关联”的（即我们如果pull则能从这个服务器上拉数据下来，如果push则能把本地数据推到这个服务器的这个仓库中去）。

下面就要分两种方法了：

第一种方法：

用Git Bash打开并进入一个目录，使用Git clone https://balabala/testproject命令将Github上的仓库“克隆”下来，就在当前目录。这个过程其实从整体上做了两类事情：1.在当前目录下建立Repository库，将Github上的testproject库中的文件下载下来并按部就班地部署到本地Repository库中；2.既然是clone下来的，那么“自然而然”地就会产生了关联。即本地Repository与Github上的Repository已经产生了联系，我们不管是git pull命令还是git push命令都会互相找到对方。

下一步就是去我们事先已经有了的项目目录，将我们要管理的文件内容拷贝到本地当前的目录下，然后git add进所有要管理的文件，再git commit进所有的文件。现在我们所有想管理的文件都已经在本地纳入了Git的管理了？我们本地的Repository库已经内容丰富了！下一步就是git push啦，将本地Repository里所有新的内容都推到Github服务器上去，这样不管是本地还是remote都已经达到了我们想要的状态了。

第二种方法：

直接用Git Bash进入我们事先已经有了的IDE正在指向的项目目录，这个目录下有我们要管理的所有文件。使用git init命令，直接在当前目录下建立Repository进行项目管理，然后把所有需要管理的文件git add然后git commit进来。这时候我们本地就有了饱满的Repository，与我们的目标唯一的区别就是我们本地的饱满的Repository和Github上的空Repository完全没有关系。

怎么建立联系呢？git remote add myGithubRemote https://balabala/testproject命令就OK了！这个命令的意思就是，我们本地的Repository定义了一个名字叫做myGithubRemote的remote端，这个remote端指向的是https://balabala/testproject地址上的远程Repository。此时你可以用git remote -v 命令查看一下我们的remote状态，在结果信息里就可以看到了myGithubRemote 和 https://balabala/testproject 的对应关系。

简单情况下，这时我们在执行git push命令时Git就知道应该把数据推到哪里了，就是myGithubRemote对应的https://balabala/testproject地址的仓库。当我们push完毕之后，就已经达到了目标状态，而且不用做什么文件迁移。

了解了这些之后，不难猜测第一种方法中git clone的第二类操作到底做了什么，其实Git就是默认为我们git remote add origin https://balabala/testproject了，Git默认给我们建立了这个对应关系，并且给这个远程库起名叫origin！这个origin就相当于我们自己定义的那个myGithubRemote~

git merge命令时用来合并的，而合并的对象就是branch（分支）。

下面我举个简单的应用场景（只在本地Repository中）来说明：本地库中有两个分支testBranch1和testBranch2。目前两个分支中的文件内容相同，都只有一个fileA.txt文件，而且fileA.txt的内容只有一行文字：HelloWorld!

如果你目前处于testBranch1，并且修改了fileA.txt文件在第二行增加了一句：Hello! 此时你的fileA.txt形如：

不仅如此，你还新建了另一个空文件fileB.txt，并且把所有的修改commit进来。

然后checkout到testBranch2上，此时testBranch2上应该只有一个fileA.txt文件而且内容只有一行HelloWorld! 此时你又修改了fileA.txt在第二行增加了一句HaHa! ，并且把所有的修改都commit进来。此时你的fileA.txt形如：

现在可以想象，testBranch1和testBranch2两个分支分别管理着两套不同版本的内容了。前者有两个文件，后者只有一个文件，而且名字相同的文件内容也有所差别。好了git merge命令马上要出场了，下面请特别注意小编介绍的两个场景：

场景1：

git checkout testBranch1（即切换到testBranch1分支上），执行git merge testBranch2命令。这样代表：站在testBranch1分支上，把testBranch2分支上的内容融合到testBranch1分支上来。这样git会尝试把testBranch2中的内容与testBranch1融合，而这样是不会改变testBranch2分支上的内容的，只会改变testBranch1上的内容。所以此后testBranch1上有两个文件（fileA.txt和fileB.txt），而testBranch2上依然只有1个文件（filtA.txt）

场景2：

git checkout testBranch2 (即切换到testBranch2分支上)，执行git merge testBranch1命令。这样代表站在testBranch2分支上，把testBranch1分支上的内容融合到testBranch2分支上来。这样git会尝试把testBranch1中的内容与testBranch2融合，而这样是不会改变testBranch1分支上的内容的，只会改变testBranch2上的内容。所以此后testBranch1上有两个文件（fileA.txt和fileB.txt），而testBranch2上也有了2个文件（fileA.txt和fileB.txt）

场景1和场景2在整体上的变化大家明白以后应该就能理解merge命令的含义了吧？下面说一下另一个细节

如果第一个分支的fileA.txt和第二个分支的fileA.txt进行融合的话，是有可能产生歧义的。前者的第二行希望是Hello!，后者的第二行希望是HaHa!那么最终结果到底听谁的呢？这种情况下Git就“有可能产生冲突”。那么在merge过程中产生冲突是怎样的效果呢？此时你的fileA.txt可能会呈现类似以下的中间状态（此时以场景1的情况为例）：