查看当前Git 版本：
git --version
更新版本：
sudo apt update # 更新源 sudo apt install software-properties-common # 安装 PPA 需要的依赖 sudo add-apt-repository ppa:git-core/ppa # 向 PPA 中添加 git 的软件源 sudo apt install -y git
克隆仓库到本地：
git clone + [仓库地址]
进入仓库主目录，仓库主目录中有个 .git 隐藏目录，它里面包含了仓库的全部信息，删掉这个目录，仓库就变成普通的目录了
当我们在 GitHub 上创建一个仓库时，同时生成了仓库的默认主机名 origin，并创建了默认分支 master。GitHub 可以看成是免费的 Git 服务器，在 GitHub 上创建仓库，会自动生成一个仓库地址，主机就是指代这个仓库，主机名就等于这个仓库地址。克隆一个 GitHub 仓库（也叫远程仓库）到本地，本地仓库则会自动关联到这个远程仓库，执行 git remote -v 命令可以查看本地仓库所关联的远程仓库信息。
查看本地仓库所关联的远程仓库信息：
git remote -v
Git 要求对本地仓库关联的每个远程主机都必须指定一个主机名（默认为 origin），用于本地仓库识别自己关联的主机，git remote 命令就用于管理本地仓库所关联的主机，一个本地仓库可以关联任意多个主机（即远程仓库）。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Git 本地仓库有三大区域：工作区、暂存区、版本区。
进入仓库主目录，执行 git status 查看整个仓库的状态：
git status
创建一个文件并再次查看仓库状态，这步操作是在工作区中：
如上图所示，新建文件后，状态提示：提交为空，但是存在未跟踪的文件
按照上图的提示，使用 git add [文件名] 命令跟踪此新建文件，即把新增文件添加到暂存区，以备提交：
出现警告：
warning: LF will be replaced by CRLF in one.txt.
The file will have its original line endings in your working directory.
解决方法： git 换行符LF与CRLF转换问题 一、背景 在各操作系统下，文本文件所使用的换行符是不一样的。UNIX/Linux 使用的是 0x0A（LF），早期的 Mac OS 使用的是0x0D（CR），后来的 OS X 在更换内核后与 UNIX 保持一致了。但 DOS/Windows 一直使用 0x0D0A（CRLF）作为换行符。Git提供了一个“换行符自动转换”功能。这个功能默认处于“自动模式”，当你在签出文件时，它试图将 UNIX 换行符（LF）替换为 Windows 的换行符（CRLF）；当你在提交文件时，它又试图将 CRLF 替换为 LF。Git 的“换行符自动转换”功能听起来似乎很智能、很贴心，因为它试图一方面保持仓库内文件的一致性（UNIX 风格），一方面又保证本地文件的兼容性（Windows 风格）。但遗憾的是，这个功能是有 bug 的，而且在短期内都不太可能会修正。 二、解决方案 1.Git设置 git config --global core.autocrlf false git config --global core.safecrlf true 含义： AutoCRLF #提交时转换为LF，检出时转换为CRLF git config --global core.autocrlf true #提交时转换为LF，检出时不转换 git config --global core.autocrlf input #提交检出均不转换 git config --global core.autocrlf false SafeCRLF #拒绝提交包含混合换行符的文件 git config --global core.safecrlf true #允许提交包含混合换行符的文件 git config --global core.safecrlf false #提交包含混合换行符的文件时给出警告 git config --global core.safecrlf warn
所以使用 git config --global core.autocrlf false 来关闭转换。
如果对多个文件或目录进行了增删改，可以使用 git add . 命令全部添加到暂存区。
注意这里有个概念，当我们修改了工作区，git add命令是将这些修改添加到暂存区，暂存区记录的只是修改。如果要撤销暂存区的修改怎么办？执行 git reset -- [文件名] 或者 git rm --cached [文件名] 命令即可：
上图的命令，如果省略最后的文件名，把命令写成 git reset -- 即可把暂存区的全部修改撤销。好，现在暂存区的修改被撤销，又回到了工作区。
现在介绍另一个命令 git diff，它可以用来查看工作区被跟踪的文件的修改详情，此时新建文件 one.txt 并未被跟踪，而已被跟踪的文件 README.md 无修改，所以看不到。注意，只有在版本区中存在的文件才是被跟踪文件。
我们先修改 README.md 文件，然后执行此命令：
接下来把变动全部提交到暂存区：
介绍另一个命令 git log，它用来查看版本区的提交历史记录，当前只有一个提交，就是在 GitHub 上创建新仓库时的初始化提交。同样此命令也会跳到新页面，如下图所示：
关于查看提交历史记录的命令，有些常用的选项介绍一下：
git log [分支名]查看某分支的提交历史，不写分支名查看当前所在分支git log --oneline一行显示提交历史git log -n其中 n 是数字，查看最近 n 个提交git log --author [贡献者名字]查看指定贡献者的提交记录git log --graph图示法显示提交历史
现在执行 git commit 命令生成一个新的提交，一个必须的选项 -m 用来提供该提交的备注：
提交后，暂存区的修改被清空，执行 git log 查看提交记录，紫色框中的十六进制序列号就是提交版本号，这是很重要的信息，每个提交都有自己单独的版本号，就像公民身份证号一样：
观察上图的提交信息，提交版本是按时间倒序排列的，也就是最近的提交排在最上面，你可能需要查看时间正序排列的信息，那么可以使用 git log --reverse 命令。
现在介绍一个超级实用、使用频率极高但几乎所有 Git 教程都不重视的命令 git branch -avv，它用来查看全部分支信息：
上图有三行信息，依次说明:
第一行，开头的星号表示当前所在分支，绿色的 master 是分支名，之所以是绿色，也是因为它是当前所在分支。后面第二项是版本号，第三项中括号里面蓝色的字，表示此分支跟踪的远程分支的名字，当然啦，这也是克隆远程仓库到本地时的默认设置 -- 创建 master 分支并自动跟踪远程同名分支；冒号后面白色文字表示本地分支领先其跟踪的远程分支一个提交。最后一项是提交时填写的备注信息。
第二行，是 Git 指针信息，它指向远程仓库的 master 分支，这行信息暂不重要。
第三行，远程分支信息，详见第一行的解释。
在执行 commit 命令时，再介绍一个我并不推荐的选项 -a ，它的作用是将未添加到暂存区的修改，也就是工作区的修改也一并提交，但会略过未被跟踪的文件，比如新建文件 one.txt，此命令的完整格式：git commit -am xxxxx 。谨慎的做法是按照前文的顺序，修改工作区 - 提交到暂存区 - 随时使用 git status 查看仓库状态 - 将暂存区的修改提交到版本区生成一次新的提交。
最后一个环节，将本地新增的提交推送到 GitHub 远程仓库中，命令是 git push，后面不需要任何选项和参数，此命令会把本地仓库 master 分支上的新增提交推送到远程仓库的同名分支上，因为当前所在的分支就是 master，而且上文提到，它已经跟踪了远程仓库的同名分支：
此命令需要再次输入用户名和密码，密码为隐藏数据，输入时看不到。推送成功后执行 git branch -avv 查看分支情况：
如上图所示，本地分支 master 与远程分支 origin/master 的版本号一致，通常看两个版本号是否一致，只需比对前四位。看一下网页上的情况：
以上就是一次完整的修改 - 提交 - 推送操作。一次推送中可以包含多个 git commit 操作，也就是多个提交可以一起推送。
如果发现 one.txt 文件内容有误，怎么做？可以修改此文件然后再次添加到暂存区、提交、推送，也可以撤销最近一次提交，修改文件后重新提交推送。现在使用后一种方法来演示撤销提交的操作流程。
首先执行 git reset --soft HEAD^ 撤销最近的一次提交，将修改还原到暂存区。--soft 表示软退回，对应的还有 --hard 硬退回，后面会讲到，HEAD^表示撤销一次提交，HEAD^^ 表示撤销两次提交，撤销 n 次可以简写为 HEAD~n。软退回一个提交后执行 git branch -avv 命令查看分支信息：
可以看到本地仓库的 master 分支的版本号已经发生了变化，变成了前一次提交的版本号，中括号里也有提示信息，本地分支 master 落后其跟踪的远程分支 origin/master 一个提交。
执行 git status 查看仓库状态，果然上一个提交中的修改全部扔回了暂存区：
再次修改 one.txt 文件，执行 git add . 命令将新的修改添加到暂存区，然后执行 git commit 命令生成新的提交：
执行 git status 和 git branch -avv 查看仓库状态和分支状态：
可以看到本地仓库的 master 分支与远程仓库的 origin/master 分支在提交版本上有了冲突，又叫做提交时间线分叉。因为刚才的提交操作不是基于远程仓库 origin/master 分支的最新提交版本，而是撤回了一个版本。这种情况下也是可以将本地 master 分支推送到远程仓库的，需要加一个选项 -f ，它是 --force 的简写，这就是强制推送：
执行 git branch -avv 看一下分支信息，本地 master 与远程 master 的版本号一致，前四位都是 e290，在浏览器上刷新 GitHub 页面，结果如预期：
假设此时发现情况不对，之前的那次版本号为 11c3 的提交是正确的，刚才的版本回退操作全都是误操作，怎么办？再次执行一次版本回退吗？当然不需要啦，我们有 git reflog 命令，它会记录本地仓库所有分支的每一次版本变化。实际上只要本地仓库不被删除，随你怎么折腾，都能回退到任何地方。reflog 记录只存在于本地仓库中，本地仓库删除后，记录消失。执行此命令如下图所示：
怎么回退到 11c3 那个版本呢？可以直接执行命令 git reset --hard [版本号] ，如果记不清版本号，也可以根据上图第 3 行的信息，执行 git reset --hard HEAD@{2} 命令，其中 HEAD@{2} 就是上图第 3 行第 2 列所示，这个命令的意思是回到当前分支最近两次提交版本变化前：
还想反悔，刚才还是改对了，怎么办？再执行一次即可，这次大括号里就是 1 了：
重要的一点，本节全部命令中，只有 push 是需要联网执行的，它对远程仓库进行了修改。