1、git init 初始化一个git仓库，即把这个文件夹下面所有的文件纳入到版本控制之中
2、添加一个read.TXT文件，内容如下：
Git is a version control system.
Git is free software.
3、git add read.TXT 可以反复使用，添加多个文件
4、git commit -m "wrote a readme file" 可以一次提交多个文件
修改文件如下：
Git is a distributed version control system.
Git is free software distributed.
4、git status 查看状态，下图是我修改文件，但是没有使用add命令的时候，调用该命令出现的结果
5、
git diff readme.TXT查看差异，在4的基础上，没有进行add，此时查看不同结果如下：
6、执行完git add命令之后，再查看状态如下：
执行git diff命令结果如下：
可以得出结论：git status是查看工作区是否有被修改的文件以及被修改文件被提交到哪一步了，而git diff是用来比较工作区与暂存区的文件的差异
调用完git commit之后，再调用git status，结果如下：
可以看到此时工作区没有修改的文件了，也就是工作区跟版本库保持一致了。
7、修改readme文件如下：
Git is a distributed version control system.
Git is free software distributed under the GPL.
8、git add
9、git commit -m "append GPL"
10、
11、
git log查看提交历史
当使用
git log --pretty=oneline的时候，结果如下：
在第一张图中的commit后面（也就是标黄的那部分）的是commit id，是git计算的一个数，用来区别每次操作
12、版本回退
在git中，用HEAD表示当前版本，也就是最新的提交，上一个版本就是HEAD，上上一个版本就是HEAD，当然往上100个版本写100个比较容易数不过来，所以写成HEAD~100。
git reset --hard HEAD^，结果如下：
可以看到，现在版本回退到上一个版本了。
此时查看文件内容：
可见，内容确实回退到上一个版本了。
但是此时调用git log的时候，结果如下：
最后的那次提交不见了，只剩下了两次，此时如果想要到那个版本，该怎么办？
如果此时你没有关掉命令行窗口，则可以往上翻到最后一次提交，找到那次提交的commit id，然后调用命令
git reset --hard 58b58，结果如下：
查看文件内容：
确实回来了。
如果关掉了命令行窗口，该怎么办？因为之前已经到最后的版本了，所以这里先进行一次版本回退操作，到 add distributed版本。
此时使用
git reflog命令查看命令历史，结果如下：
可以看到我所有的提交以及版本回退操作，在这里就能找到最后一次提交的commit id了，然后进行版本回退即可：
13、工作区、暂存区与版本库
- 工作区可以理解为ide工具写的代码放的地方，比如eclipse每次进入的时候你选的那个文件夹。
- 在工作区中有一个隐藏目录：
.git文件，这个是git的版本库，Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。 -
暂存区拥有跟上一个版本完全一样的目录结构和文件
image.png
前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
14、接13
修改readme文件如下：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
新增一个LICENSE文本文件（内容随便写）。
This is LICENSE file.
然后查看状态如下：
Git非常清楚地告诉我们，readme.txt被修改了，而LICENSE还从来没有被添加过，所以它的状态是Untracked。
调用两次add命令再查看状态如下：
下面这个图中stage中没有完全把目录结构写出来
提交之后如下：
这个版本控制有点厉害啊，应该是我操作的时候复制粘贴删除等，虽然内容一样，但是这都能整出来。。
15、针对暂存区再做一次测试：
现在版本库和工作区中的文件是：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
修改文件如下：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
此时未执行add命令，调用git diff readme.TXT，结果如下：
再一次修改文件如下：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
2
结果如下：
因为暂存区中有完整的上一个版本的内容，所以git diff比较的就是工作区跟暂存区之间的差异。
此时调用git diff --cached readme.TXT，结果如下：
说明该命令是比较版本库与暂存区的差异。
此时调用
git diff HEAD，结果如下：
跟git diff的结果完全一致，说明：确实是跟版本库做对比，查看当前工作区修改的内容。
16、接15
执行一次add命令，
修改readme文件如下：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
2
3
此时分别执行git diff和gitdiff head和git diff --cached readme.TXT，如下：
可以看到，git diff比较的是工作区与暂存区的差异，git diff head比较的是上一个版本与工作区的差异。
综上：git diff在没有add之前比较的是上一个版本跟当前工作区的差异，在add之后比较的是工作区与暂存区的差异；git diff HEAD 一直比较的是上一个版本跟当前工作区的差异，git diff caches比较的是暂存区与上一个版本的差异。
这样理解是错的，git diff一直比较的是工作区跟暂存区的差异，只是因为暂存区中有上一个版本而已，所以在没add之前，跟add之后会出现差异。
git diff 本身只显示尚未暂存的改动，而不是自上次提交以来所做的所有改动。尚未暂存的改动，用词真的是精辟
17、修改的撤销
首先将文件恢复至原始状态：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
修改文件：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
此时没有add操作，调用
git checkout -- readme.TXT命令之后，结果如下：
可以看到修改被撤销了。
然后再进行如下操作：
修改文件：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
add之后再修改文件：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
2
调用git checkout 命令结果如下：
说明
git checkout -- readme.TXT命令是让这个文件回到最近一次git commit或git add时的状态。这个时候文件已经进暂存区了，还没有提交，要想撤销暂存区的修改，可以使用
git reset HEAD readme.TXT命令，结果如下：
此时调用git status和gitdiff结果如下：
可以看到文件恢复至未add的状态，此时再调用checkout命令，结果如下：
可以看到修改被完全撤销了。
如果已经commit了，则可以使用版本回退功能。
18、删除
执行rm命令，删除文件，如下所示：
这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了。现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit。
另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：
此时文件就恢复了。
19、远程仓库
首先注册github'账号，因为这里是使用ssh加密，所以要先进行一些设置：
第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：
ssh-keygen -t rsa -C "431370446@qq.com"，然后一路回车，使用默认值即可。如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面：
然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容：
为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。
当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。
第三步：具体推送
20、分支基础知识
在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即
master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：
master其实是一个分支名而已，指向这个分支下的最新的版本，head指向当前分支。
21、分支测试
目前文件内容如下：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
首先，创建dev分支：
查看分支：
此时修改文件为：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
在dev分支上进行提交：
切换回master分支查看文件：
因为那个提交是在dev分支上，而master分支此刻的提交点并没有变。
合并分支之后再查看：
22、解决冲突
首先先建立一个分支然后feature1然后再回到master分支，则会提示比远程多一次提交：
然后转到feature1分支上，在该分支上修改文件如下：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
featrue1
然后提交，再转到master分支上：
修改文件如下，然后提交：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
master
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
这时候再去看工作区的readme文件会发现：变成了这个样子：
我们修改为以下，然后保存提交：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
master
featrue1
可以查看合并冲突的记录：
最后删除分支：
23、分支管理策略
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
测试：
在dev分支上岸原来的模式提交，在dev3上不用Fast forward模式模式提交：
可以看到保留了dev3的分支历史。
24、bug分支
首先在dev3分支干活，但是做的修改没add，这时候调用
git stash来保修现场，然后转到maste分支，生成dev4分支，在该分支上干完活病提交之后，在返回dev3分支，调用git stash apply来恢复现场
25、远程推送
