git和github的学习
1. 安装Git
1.1 下载安装包
首先我用的是64位的win7系统，先到Git官网，找到download链接，下载 https://git-scm.com/ 选择适合自己的版本。
下载下来，图标是这样
双击安装这个
1.2 安装Git
双击安装，就按默认来
上面那么多选项，我都是默认，也不知道有什么区别，最后出现下面这个界面，等待吧！
至此，安装完成！
我试了下，安装完成后，我再次点开安装包，和第一次安装过程相比，就少了第二个图——选择安装文件夹的过程，等于重新设置了下。
2. 开始简单使用Git，对源代码进行版本管理
2.1 开始配置Git,配置一次后下次并不需要再重复这个步骤了
具体内容
开始菜单中选择Git Bash，点击打开
出现下面这个窗口
接着配置用户名和邮箱，如下图
因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。你也许会担心，如果有人故意冒充别人怎么办？这个不必担心，首先我们相信大家都是善良无知的群众，其次，真的有冒充的也是有办法可查的。
注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。
2.2 建立Git仓库，建立好后，不换仓库的话，是不需要这一步的
我在E盘新建一个文件夹，名字为my_software_code，就是我开发的软件的代码存放目录。
现在，用git init告诉Git，你监控这个文件夹吧！
再看看文件夹下有什么变化，如下：
2.3 在Git仓库中开始工作了
现在我开始努力开发软件了，经过半天的努力，软件终于开发了一部分，于是，仓库E:\my_software_code下有了我写的两个源代码文件。
如下：
问题来了，
1.现在Git记录我的版本了吗？
2.我写错了代码恢复到以前版本？
答案是，还得继续学操作。
先用git status命令查看下git状态
GIT提示的信息意思是：
1.目前在主分支
2.没有要提交的修改（就是游戏存盘的意思）
3.有两个文件没有被跟踪
其中第3条的意思就是，Git并没有记录我的源代码里的文件，我想要的记录没有实现！
=======================================
我每次修改源代码都需要git add一下，等于把工作区的文件修改，放到缓存区，最后一次性的git commit一下，这样等于游戏存盘，等于把缓存区的文件放在正式修改的记录中！先不急着理解概念，跟着一步一步操作，最后再总结理解概念吧！
=======================================
好，那我们就git add一下，然后在git commit一下
好了，我存一次了，现在我发现软件开发的不行，要改进功能。
于是，我修改了file_one.js这个文件，增加了一行，如下：
再来看看git status
git status，告诉我file_one.js有所改动。但是我临时有事，没有再次git add，git commit，过了几天，我回来继续编程，git status告诉我有改动，但我记不得改动了什么，怎么办？如下：
-------------------
git diff 文件名
-------------------
现在，我的软件已经是第2个版本了。现在，我发现了新的bug，要继续改软件，代码改为第3个版本
第3次修改后，接着存一下盘
接下来，关键步骤来了。
2.4 用Git恢复文件到以前的版本
前面可知，我这个软件升级了3次，第3次开发完后，我发现有个严重的bug，需要回到第2个版本重新弄。怎么恢复到第2个版本？
/*--查看最近提交的日志--*/ git log
先用git log，看下都提交过什么版本
可以看到总共改了提交了3次！
/*git的时光机功能，回退到以前的版本所用的命令*/ git reset
这时，用git log查看下版本日志
查看git log，发现没有第3次修改的信息了！
整个过程就类似于，我在21世纪（第3次修改），穿越到了20世纪（第2次修改），现在在20世纪（第2次修改），我又后悔了，还想回21世纪（第3次修改），行吗？
只要刚才那窗口没关掉，找到第3次commit的id即可！
还是用git reset
这就完成了回到第3次修改的状态，再看我的源代码，确实也变成了第3次存盘后的状态。
也就是说：
上面就完成了，从第3版本回退到第2版本，后来后悔了，又从第2版本到第3版本。其中，从第2到第3版本的时候，因为窗口没关，往上翻，找到了commit id，所以，完成了Head指针重新指向，又回到了第3版本。
如果，我窗口关了呢？甚至是关机了呢？
在第2版本的时候，还能回到第3版本吗？就是说，20世纪，还能回到21世纪吗？
答案是：还是有办法的？如下：
/*查看命令历史记录*/ git reflog
可以看到，commit的历史，和HEAD指针指向变化的记录都在里面了。前面的7位就是commit id的前面几位！
找到了，就可以回退了，通过图中可以看到，当前已经在第3个版本了！
2.5 光会恢复文件版本还不够，要学习更深的理论了
首先，要有工作区、暂存区的概念，按上面的例子来说
这个文件夹E:\my_software_code一旦git init后，就变成了Git可以监控的文件夹，里面有个.git目录。
可以这样来理解，如下图：
其中，分支master是Git自动创建的，Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD
我觉得上图中，master理解为存盘区更好，就是游戏过一关存一次盘，不存就不记录。分支及HEAD的概念以后再看。
先复盘3次修改的整个过程。
最开始，这个文件夹E:\my_software_code为空，什么都没有，暂存区和master也是空。
然后，我写了两个文件，在工作区
Git发现，有变化：有新文件。
git add是将文件变化放到暂存区。git add之前，随便你怎么写代码，git也不去记。git add之后，此时的文件情况就复制到暂存区了。
现在开始做实验。
首先修改源代码文件file_one.js，为第4次修改了！修改后保存文件。
1. 如果不git add，就git commit会发生什么?
答案是commit 不成功！
2. 如果git add文件之后，又修改了文件，然后再commit会发生什么？
整个过程是：
第4次修改文件 ----> git add -----> 第5次修改文件 -----> git commit
答案是：commit接收的是第4次修改的内容，第5次修改的内容因为没有add，所以，还是在工作区，也就等同于
第4次修改文件 ----> git add -----> git commit -----> 第5次修改文件
2.6 管理文件修改
首先，git status查看下状态，要在没有改动要提交的情况下开始做实验。
现在的文件内容如下
实验1： 修改文件，不保存 ---> 然后查看git status，是提示文件有变化，需要git add 还是git不不知道文件变化？
实验2： 修改文件，保存下 ---> 然后查看git status，这就是前面学的需要git add的。这个先略，等下讲解其他操作可能
实验3： 修改文件，保存下 ---> git add ----> 再修改文件，再保存下 ---> 再用git diff看看
实验1的结果：git不知道文件变化。也就是说：你没保存呢，在操作系统层面上，文件就没有变化。等同于什么都没发生。如果这时候断电关机了，就等同于你没写过！
实验2是前面着重说的部分。回头再说其他可能性。
实验3重点说说，就不截图了。
修改文件，保存（记为第6版本）----> git add 这时候，暂存区为第6版本，这时候用git status就提醒你要么commit，要么回退。
git add ---> 再修改文件，保存（第7版）这时候，用git status，提醒你，第6版本的要不要commit ,第7版本的要不要add之类的。
如果用git diff 命令，可知，是现在的版本（第7版）和上次add之后暂存区的（第6版）相比较。
也就是说，diff是和暂存区的相比较，如果暂存区没有就和存盘的commit的相比较。
2.7 撤销修改
首先，都已经commit了，暂存区是空的了,文件kk.js是版本1.
场景1.修改文件并保存（工作区的文件kk.js变成版本2） ----> $git checkout -- kk.js ，这时候文件是什么情况？
答曰：git将会修改文件kk.js，将工作区中的kk.js第2版改为第1版，回到最初（commit之后的版本，这里是kk.js的版本1）的样子。等于说刚才没修改！
编辑器如果是打开的，就提醒下面的，文件被另外的程序（也就是Git）修改了。
复盘一下，修改文件kk.js，这时候我可以git add添加到暂存区，这个是以前重点说的，现在说另一个选择，就是git checkout，它的作用就是放弃工作区目前的修改，回到上一个版本（下面再说到底是什么版本,就是让这个文件回到最近一次git commit或git add时的状态。）。
场景2. 修改文件并保存（工作区的文件kk.js变成版本2） ----> git add ----> git reset HEAD <file>（这时候前面常说的是git commit，我们很熟悉，但是这里不，而是反过来！）
复盘一下，修改并保存后（若修改不保存，则视为没修改），工作区有kk.js版本为2，git add，那么暂存区为kk.js第2版，git reset HEAD kk.js 这个命令，将会让暂存区修改撤销掉。此时此刻，等同于修改文件并保存（工作区的文件kk.js变成版本2）然后没有git add, 工作区kk.js是版本2没动，暂存区没有kk.js 。剩下的你是git add（回老路）还是 git checkout（场景1） 你再决定！
场景3. 修改文件并保存（版本2） ----> git add ----> 再修改文件并保存（版本3）-----> git checkout
复盘一下，修改保存后工作区kk.js为版本2，git add后暂存区也为版本2，再修改则工作区为版本3，暂存区为版本2，git checkout则放弃目前工作区的修改，回到最近一次git commit或git add时的状态，则工作区也变成版本2，暂存区没影响，还是版本2
2.8 删除文件
首先，让kk.js回到版本1，该提交的提交，该取消的取消，清空暂存区。
此时，我们在操作系统中删掉了kk.js
用git status提示如下：
Git监控到文件变化：kk.js被删除了！工作区和版本库里的不一致了！
现在，
有两种情况，
一是我确实用不到kk.js这个文件了，那么还需要从版本库中删除，然后commit一下，让工作区和版本库一致。
二是，我刚才不小心删错了，我要恢复。怎么办？看上面的提示，就是git checkout -- kk.js 也就是说，删除也是一种修改，checkout让版本库中的回退下，替换掉工作区的。那么文件有恢复了，等于没修改过。
如果是情况1，图如下
如果是情况2，图如下
3. 远程仓库
3.1 使用GitHub前的准备工作，设置一些项，不换电脑的话，以后并不需要再操作这一步
Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。
你肯定会想，至少需要两台机器才能玩远程库不是？但是我只有一台电脑，怎么玩？
其实一台电脑上也是可以克隆多个版本库的，只要不在同一个目录下。不过，现实生活中是不会有人这么傻的在一台电脑上搞几个远程库玩，因为一台电脑上搞几个远程库完全没有意义，而且硬盘挂了会导致所有库都挂掉，所以我也不告诉你在一台电脑上怎么克隆多个仓库。
实际情况往往是这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。
完全可以自己搭建一台运行Git的服务器，不过现阶段，为了学Git先搭个服务器绝对是小题大作。好在这个世界上有个叫GitHub的神奇的网站，从名字就可以看出，这个网站就是提供Git仓库托管服务的，所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库。
在继续阅读后续内容前，请自行注册GitHub账号。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：
下面是我做第一步的截图
为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。
当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。
最后友情提示，在GitHub上免费托管的Git仓库，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放进去。
如果你不想让别人看到Git库，有两个办法，一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。另一个办法是自己动手，搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。这个方法我们后面会讲到的，相当简单，公司内部开发必备。
确保你拥有一个GitHub账号后，我们就即将开始远程仓库的学习。
3.2 添加一个远程库
现在的情况是，我已经在本地创建了一个Git仓库，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。
首先，登陆GitHub，然后，在右上角找到“Create a new repo”按钮，创建一个新的仓库：接下来如图：
目前，在GitHub上的这个my_software_code仓库还是空的，GitHub告诉我们几个选择，
1. 可以从这个仓库克隆出新的仓库。
2.也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。
推送成功后，可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样：
从现在起，只要本地作了提交，就可以通过命令：
$ git push origin master
把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！
2级标题
具体内容
2级标题
具体内容
2级标题
具体内容
1级标题
2级标题
具体内容
2级标题
具体内容
2级标题
具体内容
2级标题
具体内容
2级标题
具体内容
1级标题
2级标题
具体内容
2级标题
具体内容
2级标题
具体内容
2级标题
具体内容
