本篇主要总结关于Git中远程操作的相关事项：
理解分布式版本控制系统
在进行远程操作前，首先要理解什么是分布式版本控制系统
理解这个问题时要思考这样的问题：我之前进行的add和commit的操作都是在我本地进行的，如果我的电脑坏了怎么办
因此，就出现了一个解决方案，让多台计算机都把这个仓库进行备份，并且只要有任何一个计算机的仓库下提供了一个改变，都会把数据推送给其他人的电脑，其他人就可以从仓库中看到某个人的更新记录
这个操作是有历史进步意义的，但这个方法依旧不好，计算机并不稳定，如果还没有备份到多台机器上就已经全部损失了数据该怎么办？
因此，就出现了现在主流的管理方案，有一个中央服务器，这个中央服务器是24h进行运转，并且十分稳定，有谁需要进行操作就可以在仓库中进行相关的操作，这样既能保证开发效率的前提下，还能使得仓库变得十分的稳定，而这个中央服务器，就是所谓的Github和Gitee
克隆仓库
在Gitee中可以获取到克隆的链接，直接使用命令：
# xxxx表示克隆的地址 git clone xxxx
远程推送
本地已经clone成功了远程仓库后，就可以向仓库中提交内容，例如新增一个file.txt文件
在提交的时候需要注意的是，前面有进行过全局的name和email的配置，这两个信息是要和gitee上的用户名和邮箱是需要一致的，否则会导致推送出错
当使用完add和commit的操作后，就可以把仓库中的信息推送到远程仓库了：
git push [远程主机名] [本地分支名]:[远程分支名]
需要注意的是，如果本地分支名和远程分支名相同，那么冒号和远程分支名是可以省略的
拉取远程仓库
如果远程仓库的更新版本程度比本地的更新版本程度要新，那么就需要用到pull指令，用处是拉取远程仓库到本地仓库
git pull [远程主机名] [本地分支名]:[远程分支名]
如果本地分支名和远程分支名相同，那么冒号和远程分支名是可以省略的
配置Git
在日常使用中，在程序经过编译等多项结果后，会产生一系列附属的临时文件或动静态库等等，那么如何保证这些文件不被提交？
因此就引入了一个工具叫做.gitignore
具体的用法是，在文件中可以写入一些东西：
* .so * .ddl
上面的规则写法就代表着，如果要推送的内容中含有.so或.ddl的文件，就把这些文件忽略掉不予理睬，只进行其他文件的推送
那如果有一个场景确实需要推送一个叫做a.so的文件？
可以在.gitignore中添加：
! a.so
用感叹号的这种写法就表示，对于有这样名称的文件就进行提交，这样就可以进行提交了
# 常用的.gitignore # Build and Release Folders bin-debug/ bin-release/ [Oo]bj/ [Bb]in/ # Other files and folders .settings/ # Executables *.swf *.air *.ipa *.apk #过滤掉不想要文件和文件夹 *.exe *.sln *.vcxproj *.filters *.user *.suo *.db *.ipch Debug/ .vs Release/
标签管理
如何理解标签？标签的意义是什么？
标签可以理解为，是对于某次commit后的一个标识，相当于起了一个别名，例如，在项目中发布一些版本的时候，可以对于最后一次的commit进行命名，作为一个特殊意义
其实标签的意义远不止于此，相比起晦涩难懂的commit id，标签就可以很好的解决这个问题，一般来说自定义的标签都是有意义的，可以帮助人进行记忆的名字，因此使用标签在帮助我们回退某个版本的时候有很大的帮助
创建标签
git tag [name]
通过上述的命令就可以实现打标签的一个效果
git tag
这个命令可以用来查看所有的标签
对于默认的标签是打在最后提交的commit上的，但是对于指定的commit版本也有对应的使用方法，那就是找到那次commit id，再打到那个id就可以了
git tag v0.9 [commit id]
查看标签的信息
git show [tagname]
除此之外，Git 还提供可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：
git tag -a [name] -m "XXX" [commit_id]
那么下面进行关于Git的一些实战操作，借助这些实战操作来更好的理解Git在多人开发中的用途
