Git之远程仓库
之前我们使用的都是本地git仓库来进行管理文件的。但git其实是一个分布式版本控制器，我们之前只使用了git的版本控制功能，却没有体现出分布式！
同一个git仓库，可以克隆到不同的机器上，并且每一个机器上都是一个完整的git仓库，如果两个开发人员对代码进行了修改，想要其他人看见，只需要将自己的修改提交，并推送到远程，让另一方重新拉取最新的代码即可。
一.新建远程仓库
gitee就是一个代码托管平台，我们可以将其作为我们的远程仓库。
我们可以看到，我们在创建远程仓库时并没有选择分支模型，这里默认就是master单分支模型
二.克隆远程仓库到本地
克隆时，我们可以选择https协议克隆，也可以选择ssh协议克隆。
https克隆适用于临时克隆仓库使用，https每一次推送的时候需要输入密码，但克隆仓库简单。
ssh克隆仓库需要配置公钥，适用于长期开发。并且ssh配置之后，每一次push无需输入密码。
下面以ssh克隆远程仓库为例：
ssh克隆远程仓库必须要配置公钥，如果没有公钥直接克隆服务器会拒绝我们的访问请求。
1.在家目录下，看.ssh的隐藏目录中有没有id_rsa和id_rsa.pub这两个文件，如果没有则需要创建ssh key（如果有，则直接跳到下一步）
因为我这里已经有了公钥，所以会提示我是否要覆盖，没有公钥的，直接一路回车即可。
然后.ssh就会有那个文件，我们打印.pub文件，这就是公钥，我们将其全部复制。
然后在gitee设置中，添加公钥即可
2.克隆远程仓库到本地
克隆完成后，就会在当前目录下，生成一个与远程仓库同名的目录
进入该目录内部，就会有我们初始化时选择的readme文件，以及.git和.gitee隐藏目录
.git就是git仓库，而.gitee则是我们选择模板时的issue和pull requset模板
当我们clone之后，git会默认将本地的master分支和远程的master关联起来，远程仓库默认叫做origin
git remote -v看到有fetch和push权限
3.克隆之后，我们要使用git config 来配置我们的git仓库
其实在clone命令的下面，gitee就给了我们提示，我们直接运行这个命令即可
三.向远程推送内容
我们创建一个file.txt文件，并进行提交，此时查看仓库状态，提示我们领先于远程的master，要进行push
这一步就是将我们本地的修改推送到远程，让远程与我们进行同步，git push的选项如下：
git push <远程主机名> <本地分⽀名>:<远程分⽀名> # 如果本地分⽀名与远程分⽀名相同，则可以省略冒号：
git push <远程主机名> <本地分⽀名>
此时我们在gitee上查看我们的仓库，就会多了一个file.txt文件
四.拉取远程仓库内容
我们在远程仓库上直接对file.txt进行修改，让远程仓库的版本领先于本地（这种行为严重错误，不要在远程仓库上直接修改，这里是便于测试）
此时本地仓库比远程仓库落后，为了与远程一致，我们要拉取远程仓库的内容到本地，拉去操作如下：
git pull <远程主机名> <远程分⽀名>:<本地分⽀名> # 如果远程分⽀是与当前分⽀合并，则冒号后⾯的部分可以省略。
git pull <远程主机名> <远程分⽀名>
五.配置Git
配置忽略文件——.gitignore
在创建仓库时，初始化仓库有一个.gitignore忽略模板，这个隐藏文件的功能其实就是为了屏蔽一些文件的干扰，比如我们写了很多.c/.cpp的源文件，我们同时也写了很多的txt文件，但是我们上传的时候只想push源文件，而不想push txt文件。
如果没有.gitignore，我们就得一个一个的push，很麻烦。而有了该文件，我们可以给里面写上我们不想要push的文件，此时我们就可以大胆放心的push，不会将.gitignore中的满足要求的文件push到远程。
如下测试所示：我们设置*.so和*.a表示以.so和.a结尾的文件都不会push，但是我们又设置了!b.so，表示该文件要push。
还有一个细节，那就是我们这里直接使用了git push而没有使用 git push origin master，这是因为我们远端的master分支已经和我们本地的master建立了联系，此后就可以直接使用git push来推送，拉取也是一样。
给命令起别名
git config --global alias.xx 原命令比如，我们当是使用git查看带分支的日志时，命令非常长
git log --graph --pretty=oneline --abbrev-commit
我们就可以使用alias来为该命令创建一个别名：
六.标签管理
1.理解标签
标签 tag ，可以简单的理解为是对某次commit 的⼀个标识，相当于起了⼀个别名。例如，在项⽬ 发布某个版本的时候，针对最后⼀次commit 起⼀个v1.0 这样的标签来标识⾥程碑的意义。
这有什么⽤呢？相较于难以记住的 commit id ， tag 很好的解决这个问题，因为 tag ⼀定要给⼀ 个让⼈容易记住，且有意义的名字。当我们需要回退到某个重要版本时，直接使⽤标签就能很快定位 到。
2.标签操作
使用git tag xx创建标签，默认会给当前分支的最新一次commit打上标签。
使用git show可以查看标签
如果想要给指定的commit id打上标签，则需要指定commit id
使用git show [tag]可以查看该标签的内容
使用git tag -d删除标签
如果要将某个标签推送到远程，则需要git push origin <tagname> 
如果你有多个标签，想要一次性推送，可以使用
git push origin --tags 如果要想删除已经同步到远程的标签，需要先删除本地的，然后同步要远程:
七.多人协作
在日常开发过程中，往往都是很多人同时进行开发。并且为了保证远程master分支的稳定性，我们一般不直接对master分支进行push操作，而是在远程创建新分支，每一个分支对应一个新功能，开发人员在本地对新建分支进行操作。开发完毕也将修改提交到新分支上，然后提交pull request表单，来申请将功能合并到主分支，这样就可以避免直接合并代码而导致出bug的问题。
1.在Windows下克隆该仓库
2.创建远程分支
2.使用git pull将dev分支拉去到本地
拉取之后，我们新建一个本地的dev分支，并于远程dev分支产生关联，这样我们push/pull的时候，就不用带origin参数了
windows也一样
3.开发
我们在Linux上，和Windows上，同时对file.txt这个文件进行修改。
此时查看码云上的dev分支，它比master分支领先
此时我们继续让Windows下对file.txt进行开发
但是我们对dev分支进行推送的时候，就会发送请求被拒绝了。这是因为发送了冲突。对于Windows来说，远程的dev分支，比本地的dev分支领先，此时推送的时候，git不知道怎么合并，所以我们此时需要手动解决
先从远程拉取最新内容
然后选择如何进行合并，并且重新进行提交
此时再看码云，就可以看到最新的两个人的开发内容了：
但此时内容仍在dev分支上，master分支依旧看不到：
4.将dev分支合并到master分支
在本地，我们合并时为了避免冲突，先让dev合并master，然后master合并dev。然后再远程仓库，我们合并dev，需要申请pull request。
当审查和测试通过后，我们就可以进行合并了
因为合并后dev分支就没有用了，此时我们直接删除dev分支即可。
合并之后，我们在master分支就可以看到dev分支上开发的内容了，并且dev分支也被删除了
5.删除本地的dev分支
远程分支dev已经删除了，但是我们依旧可以查到，可以使用git remote prune orgin删除那些远程不存在的分支
然而再真正的开发过程中，往往都是一个功能对应一个分支，不会同时在一个分支上实现多个功能。 但只要我们遵守以上的原则，就不会出现什么大问题了。