文章目录
- [1. 理解分布式版本控制系统](#1. 理解分布式版本控制系统)
- [2. 远程仓库](#2. 远程仓库)
- [3. 新建远程仓库](#3. 新建远程仓库)
- [4. 克隆远程仓库](#4. 克隆远程仓库)
- [5. 向远程仓库推送](#5. 向远程仓库推送)
- [6. 拉取远程仓库](#6. 拉取远程仓库)
- [7. 忽略特殊文件](#7. 忽略特殊文件)
- [8. 给命令配置别名](#8. 给命令配置别名)
1. 理解分布式版本控制系统
我们目前所说的所有内容（工作区，暂存区，版本库等等），都是在本地！也就是在你的笔记本或者计算机上。而我们的 Git 其实是分布式版本控制系统！什么意思呢？
可以简单理解为，我们每个人的电脑上都是一个完整的 版本库，这样你工作的时候，就不需要联网了，因为 版本库 就在你自己的电脑上。既然每个人电脑上都有一个完整的 版本库，那多个人如何协作呢？
比方说你在自己电脑上改了 文件A，你的同事也在他的电脑上改了 文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
如下图所示：
分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整 版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。
在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送 版本库 的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了。也可能今天你的同事病了，他的电脑压根没有开机。
因此，分布式版本控制系统通常也有一台充当 中央服务器 的电脑，但这个 服务器 的作用仅仅是用来方便 交换 大家的修改，没有它大家也一样干活，只是交换修改不方便而已。有了这个 中央服务器 的电脑，这样就不怕本地出现什么故障了（比如运气差，硬盘坏了，上面的所有东西全部丢失，包括 git 的所有内容）
2. 远程仓库
Git 是分布式版本控制系统，同一个 Git 仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以 克隆 这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。
你肯定会想，至少需要两台机器才能玩远程库不是？但是我只有一台电脑，怎么玩？
其实一台电脑上也是可以克隆多个版本库的，只要不在同一个目录下。不过，现实生活中是不会有人这么傻的在一台电脑上搞几个远程库玩，因为一台电脑上搞几个远程库完全没有意义，而且硬盘挂了会导致所有库都挂掉，所以我也不告诉你在一台电脑上怎么 克隆 多个仓库。
实际情况往往是这样，找一台电脑充当 服务器 的角色，每天 24 小时开机，其他每个人都从这个 服务器 仓库 克隆 一份到自己的电脑上，并且各自把各自的提交推送到 服务器 仓库里，也从 服务器 仓库中拉取别人的提交。
完全可以自己搭建一台运行 Git 的 服务器 ，不过现阶段，为了学 Git 先搭个 服务器 绝对是小题大作。好在这个世界上有个叫 GitHub 的神奇的网站，从名字就可以看出，这个网站就是提供 Git 仓库托管服务的，所以，只要注册一个 GitHub 账号，就可以免费获得 Git 远程仓库。
如下所示：
3. 新建远程仓库
1）新建远程项目仓库：
2）填写基本信息
3）创建成功
4）创建成功后，我们可以对远程仓库进⾏⼀个基本的设置：开源 or 私有
往下翻，找到 Danger Zone，选择 Change visibility
5）从创建好的远程仓库中我们便能看到，之前在本地学习过的分⽀，也存在于远程仓库中并被管理起来了。刚创建的仓库有且只有⼀个默认的 main（master） 分⽀。
6）实际在开发过程中，我们会新建一个 dev 分支，然后进行 Coding，写完代码以后，不能直接在 dev 上 合并（merge） 主分支，而是要提一个 PR（Pull requests） 合并申请单，提完以后，由管理员进行 merge 操作。
4. 克隆远程仓库
克隆/下载远端仓库到本地，需要使用 git clone 命令，后面跟上我们的远端仓库的链接，远端仓库的链接可以从仓库中找到：选择 克隆 / 下载 获取远程仓库链接：
SSH 协议和 HTTPS 协议是 Git 最常使用的两种数据传输协议。SSH 协议使用了公钥加密和公钥登陆机制，体现了其实用性和安全性，使用此协议需要将我们的公钥放上 服务器，由 Git 服务器进行管理。使用 HTTPS 方式时，没有要求，可以直接克隆下来。
- 使用 HTTPS 方式
bash
git clone https://github.com/LuvKobe/gitCode_Teaching.git结果如下：其中 origin 是远程仓库默认的名字，fetch 是【拉取】，push 是【推送】。
- 使用 SSH 方式
第一步：创建SSH Key。在用户主目录下，看看有没有 .ssh 目录，如果有，再看看这个目录下有没有 id_rsa 和 id_rsa.pub 这两个文件，如果已经有了，可直接跳到下一步。如果没有，需要创建SSH Key：
bash
# 注意要输⼊⾃己的邮箱，然后⼀路回车，使用默认值即可
ssh-keygen -t rsa -C "xxxxxx@qq.com"
# 查看密钥对
ls -a .ssh/顺利的话，可以在用户主目录里找到 .ssh 目录，里面有 id_rsa 和 id_rsa.pub 两个文件，这两个就是 SSH Key 的秘钥对，id_rsa 是私钥，不能泄露出去，id_rsa.pub 是公钥，可以放心地告诉任何人。
如下所示：
第二步：添加自己的公钥到远端仓库。
点击头像，选择 Settings
点击 ssh公钥 选项，进行设置：
使用命令查看公钥：
bash
cat .ssh/id_rsa.pub然后把公钥复制进去：
点击确认后，需要对你进行认证，输入你的账号密码即可。
至此，我们的准备工作全部做完，欢快的 clone 吧。
done，成功！如果有多个人协作开发，GitHub 允许添加多个公钥，只要把每个人的电脑上的 Key 都添加到 GitHub，就可以在每台电脑上往 GitHub 上提交推送了。
当我们从远程仓库克隆后，实际上 Git 会自动把本地的 master 分支和远程的 master 分支对应起来，并且，远程仓库的默认名称是 origin。在本地我们可以使用 git remote 命令，来查看远程库的信息，如：
bash
[Tom@vm-centos:~/gitCode_Teaching]$ git remote
origin或者，用 git remote -v 显示更详细的信息：
bash
[Tom@vm-centos:~/gitCode_Teaching]$ git remote -v
origin git@github.com:LuvKobe/gitCode_Teaching.git (fetch)
origin git@github.com:LuvKobe/gitCode_Teaching.git (push)上面显示了可以抓取和推送的 origin 的地址。如果没有推送权限，就看不到 push 的地址。
5. 向远程仓库推送
如果我们之前设置过全局的 name 和 e-mail，这两项配置需要和 github 上配置的用户名和邮箱一致，否则会出错。或者从来没有设置过全局的 name 和 e-mail，那么我们第一次提交时也会报错。这就需要我们重新配置下了，同样要注意需要和 gitee 上配置的用户名和邮箱一致。
配置命令如下：
bash
# 用户名和邮箱要与github上保持一致
git config --global user.name "xxxxx"
git config --global user.email "xxxxx@qq.com"
# 查看配置信息
git config -l本地已经 clone 成功远程仓库后，我们便可以向仓库中提交内容，例如新增一个 file.txt 文件：
bash
# 新建文件
touch file.txt
echo "hello git" > file.txt
# 提交文件
git add .
git commit -m "create file.txt"结果如下：
到这里我们已经将内容提交至本地仓库中，如何将本地仓库的内容推送至远程仓库呢，需要使用 git push 命令，该命令用于将本地的分支版本上传到远程并合并，命令格式如下：
bash
git push <远程主机名> <本地分⽀名>:<远程分⽀名>
# 如果本地分⽀名与远程分⽀名相同，则可以省略冒号：
git push <远程主机名> <本地分⽀名> 此时我们要将本地的 main 分支推送到 origin 主机的 main 分支，则可以：
bash
# 写法一
git push origin main:main
# 写法二
git push origin main结果如下：
推送成功！这里由于我们使用的是 SSH 协议，是不用每一次推送都输入密码的，方便了我们的推送操作。如果你使用的是 HTTPS 协议，有个麻烦地方就是每次推送都必须输入口令。
接下来，看看远程仓库：
代码已经被推送至远端了：
6. 拉取远程仓库
在 远程仓库里 点击 file.txt 文件并在线修改它：
修改内容：
此时，远程仓库是要领先于本地仓库一个版本，为了使本地仓库保持最新的版本，我们需要拉取下远端代码，并合并到本地。Git 提供了 git pull 命令，该命令用于从远程获取代码并合并本地的版本。格式如下：
bash
git pull <远程主机名> <本地分⽀名>:<远程分⽀名>
# 如果远程分⽀是与当前分支一样，则冒号后⾯的部分可以省略。
git pull <远程主机名> <远程分⽀名>使用一下：
bash
git push origin main结果如下：
我们发现，拉取成功了！
7. 忽略特殊文件
在日常开发中，我们有些文件不想或者不应该提交到远端，比如保存了数据库密码的配置文件，那怎么让 Git 知道呢？在 Git 工作区的根目录下创建一个特殊的 .gitignore 文件，然后把要忽略的文件名填进去，Git 就会自动忽略这些文件了。
不需要从头写 .gitignore 文件，Github 在创建仓库时就可以为我们生成，不过需要我们主动勾选一下：
如果当时没有选择这个选择，在工作区创建一个也是可以的。无论哪种方式，最终都可以得到一个完整的 .gitignore 文件，例如我们想忽略以 .so 和 .ini 结尾所有文件，.gitignore 的内容如下：
bash
# 省略选择模本的内容
# My configurations:
*.ini
*.so在 .gitignore 文件中也可以指定某个确定的文件。
最后一步就是把 .gitignore 也提交到远端，就完成了：
bash
# 新建.gitignore文件
vim .gitignore
# 提交并推送
git add .
git commit -m "add .gitignore"
git push origin main结果如下：
接着我们就来验证一下 .gitignore 文件的能力，在工作区新增两个文件 a.so b.ini：
bash
touch a.so b.ini检验 .gitignore 的标准就是使用 git status 命令，看看是否出现了 working tree clean。我们发现 Git 并没有提示在工作区中有文件新增，果然 .gitignore 生效了！
但有些时候，你就是想添加一个文件到远程仓库中，但由于这个文件被 .gitignore 忽略了，根本添加不了，那么可以用 -f 强制添加：
bash
git add -f [filename]如下所示：我们可以新建一个 b.so 文件，然后使用 -f 选项来强制添加（别提交）：
或者你发现，可能是 .gitignore 写得有问题，需要找出来到底哪个规则写错了，比如说 a.so 文件是要被添加的，可以用 git check-ignore 命令检查：
bash
[Tom@vm-centos:~/gitCode_Teaching]$ git check-ignore -v a.so
.gitignore:4:*.so a.soGit 会告诉我们，.gitignore 的第 4 行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。
还有些时候，当我们编写了规则排除了部分文件时，例如：
bash
# 排除所有.开头的隐藏⽂件
.*但是我们发现 . 这个规则把 .gitignore 也排除了。虽然可以用 git add -f 强制添加进去，但有强迫症的童鞋还是希望不要破坏 .gitignore 规则，这个时候，可以添加一条例外规则：
bash
# 排除所有.开头的隐藏⽂件
.*
# 不排除.gitignore
!.gitignore把指定文件排除在 .gitignore 规则外的写法就是 ! + 文件名，所以，只需把例外文件添加进去即可。
现在我们可以在 .gitignore 新增一条规则：不排除 c.so 文件
bash
# 不排除 c.so
!c.so结果如下：
再创建一个 c.so 文件，不加 -f 选项来验证一下
bash
# 新建文件
touch c.so
# 查看状态
git status结果如下：
然后再进行推送到远端仓库：
bash
# 添加
git add .
# 提交修改
git commit -m "add .so"
# 推送
git push origin main结果如下：
同时可以去远端仓库刷新看一下：
8. 给命令配置别名
在我们使用 Git 期间，有些命令敲的时候着实让人头疼（太长了...），幸运的是，git 支持对命令进行简化！
举个例子，将 git status 简化为 git st，对应的命令为：
bash
git config --global alias.st status--global 参数是全局参数，也就是这些命令在这台电脑的所有 Git 仓库下都有用。如果不加，那只针对当前的仓库起作用。
好了，现在敲 git st 看看效果：
再来配置一个 git last，让其显示最后一次提交信息：
bash
git config --global alias.last 'log -1'这样，用 git last 就能显示最近一次的提交：
不过，我个人还是不推荐大家现在去使用它，目前所有的命令都要手动完成，尽快适应 Git。