git init
图例中首先创建了一个空的文件夹gitDemo，进入该文件夹，运行git init命令，提示创建了一个空的git仓库。这时候我们查看gitDemo，发现多了一个.git目录，它是用来跟踪管理版本库的。由于.git这个目录默认是隐藏的，所以需要用ls -ah命令才能查看。
git add & git commit
在介绍这两个命令之前我们先来了解一下工作区(Working Directory)和版本库(Repository)，
其中Working Directory就指当前在电脑上看到的所有目录，如例子中的gitDemo目录；
对于Repository，首先
Working Directory有一个隐藏目录.git，这个不算工作区，而是Git的版本库。Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。——from https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013745374151782eb658c5a5ca454eaa451661275886c6000
了解了Working Directory以及Repository，我们就能更明白git add 和 git commit 都是针对什么进行操作。
简单总结就是：
git add把文件修改添加到暂存区；
git commit把暂存区的所有内容提交到当前分支。
但起初我还是很疑惑的，为什么在git commit之前要增加一个git add操作，这样不是很繁琐吗？？？
最后在网上查阅资料时看到这样一个生动的总结，让我瞬间明白了其中的道理：
git add就好比逛淘宝的时候将要购买的商品添加到购物车，而git commit相当于将购物车里的商品一并结账，试想如果每往购物车加入一件商品就要结一次账，岂不是更麻烦。
git add <file> 表示将指定文件的修改添加到暂存区 e.g.: git add test.txt
git add . 表示将涉及到的所有修改都添加到暂存区
git commit -m '这里是相关说明' 表示将暂存区中所有内容提交到当前分支，其中-m 后面跟着的是这次提交内容的相关注释，不建议省略。
git diff
用来查看文件具体都有了些什么修改
git status
这是git命令中很重要的一个命令，它让我们时刻掌握仓库当前的状态，同时会给出一些接下来我们可能会进行的操作的相关提示。
在上面的例子中，我重新编辑了之前创建的test.txt文件，做了一些文件内容的修改，之后使用git status命令，得出上图。上图诉我们如下信息：
git checkout -- <file>
对文件的修改还没有添加到暂存区，以便之后的提交；
可以使用git add <file>将修改添加到暂存区，更新暂存区内容，以便之后提交
可以使用git checkout -- <file> 来撤销工作区中发生的修改
因此，如果修改还没被添加到暂存区，那么可以通过git checkout -- <file>来将工作区的内容恢复到上一次git add 之前。
git reset HEAD
如果修改已经被添加到暂存区，那么可以根据提示通过git reset HEAD <file>，这里的HEAD值的是当前分支。
此操作只是将上一次的git add 操作撤销，添加到暂存区的修改移出暂存区，要进一步删除当前工作区的修改，根据提示继续执行git checkout -- <file>操作，回到上上次git add后的状态。
可以看到我修改了test.txt文件，并且执行了git add操作，这时候查看git status，提示说——修改以及添加到暂存区，等待提交。同时可以使用git reset HEAD <file>将修改移出暂存。
执行git reset --hard <file>将之前移入暂存的修改移出，可以看到git reset --hard <file>执行前后，相关文件test.txt内容并没有什么改变，但此时运行git status提示说——有存在未添加到暂存的修改，如果确认要移入暂存则执行git add，若要撤销工作区修改，则执行git checkout -- <file>。
可以看到执行git checkout -- <file>之后，test.txt恢复到了上上次git add后的状态。
git reset --hard HEAD^/id
如果再糟糕一点，修改不仅已经被添加到暂存区还被提交到了分支上，那么怎样回退到上一个版本？
不知道大家有没有注意到，每当我们执行一次git commit时，同时会创建一个版本id，有了这个id我们就能通过id和相关指令回到指定版本。
上图中，我们先修改了test.txt文件，之后执行了git add 以及 git commit 操作，可以看到git commit时创建了一个7位数的版本id／commit id，实际的id并不是7位数，这里只是展示出来前7位。之后执行git reset --hard HEAD^回退到了前一个版本，可以看到命令执行前后test.txt文件内容的改变。
其中HEAD^表示当前版本的上一个版本，依此类推，HEAD^^表示上一个版本的上一版本，但如果我们想回退到很久以前的版本，一直HEAD^也很麻烦，所以git也提供了根据版本id来回退到指定版本的指令。
那如何知道要回退的版本的id呢？纯靠自己记是不现实的。
git log / git log --pretty=online
可以帮助我们，git log可以查看提交历史,其中git log --pretty=online得到的是简洁版的提交历史。
通过git log我吗可以清楚的看到提交历史，包括提交时的注释、时间、提交人之类的信息，同时包括很重要的提交id，有了提交id我们就可以任意回退到指定版本了～
回退成功。
git reflog
因为如果回退到以前的版本后，再执行git log，那么没回退前的那个版本就不会再出现在提交历史中了。那如果这个时候我们又想去到没回退前的版本怎么办，需要的依然是id，那id去哪儿找呢？
执行git reflog可以查到命令历史，就可以去命令历史里找回退前的id。
在命令历史中我们可以找到回退前的版本号为commit：add again所对应的id——abd342c，因此就很好去到回退前的版本了。
git rm
这个命令表示删除文件
根据提示你也可以撤销删除，此时相关文件会恢复到最新版本，但是会丢失最后一次提交后修改的内容。
一直在操作本地仓库，是时候过渡到远程仓库了
对于远程仓库有两种情况：
git remote add origin git@server-name:path/repo-name.git
git push -u origin master
1. 你已经在本地创建了一个Git仓库，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步。
此时你需要打开github创建一个远程仓库，仓库名和本地仓库名一致。本例中的仓库名为gitDemo。
GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。
根据github提示，我们进行了下面两个操作：
关联远程仓库，使用命令git remote add origin git@server-name:path/repo-name.git；
关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
git clone
2. 此时我们没有本地仓库，打算从一开始创建远程仓库，再从远程仓库克隆
也是在github创建一个远程仓库，之后拿到克隆的链接，执行相关命令
git branch
查看分支
git branch <name>
创建分支
git checkout <name>
切换分支
git checkout -b <name>
创建并切换分支
git merge <name>
将指定分支合并到当前分支
git branch -d <name>
删除指定分支
git branch -D <name>
强制删除指定分支，即使还没有merge
git stash
git stash pop
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。
git tag <name>
新建tag
默认为HEAD版本打tag
git tag <name> id
为指定版本打tag
git tag -a <name> -m "" id
创建带有说明的标签，用-a指定标签名，-m指定说明文字
git show <name>
可以看到说明文字
git tag
参看所有tag
git tag -d <name>
删除指定tag，此时tag还没被推送到远程仓库
git push origin <name>
将指定tag推送到远程仓库
git tag -d <name>
git push origin:refs/tags/<name>
如果标签已经推送到远程，要删除远程标签得先从本地删除，再删除远程分支
git配置别名
每个仓库的Git配置文件都放在.git/config文件中，别名就在[alias]后面，要删除别名，直接把对应的行删掉即可。
后面的命令没有一步一步的用demo演示，以后可以慢慢加上，主要是觉得这些比较容易一使用就会了，所以建议大家随便弄一个文件来实际操作一下这些命令。遇到问题积极解决，在过程中感触比较深的一点就是出问题的时候看看提示，根据提示一步步都能把问题解决。注意用git status来实时掌控修改，同时git status会有很多接下来可能会发生的操作的提示。
