标签： Git
描写性文字：
不要问我为何用这类骚猪风格的标题，现在写博文，标题不骚，人家都不乐意看~
接触Git到现在有1年多了，对Git使用也是日渐精进，虽然说不上很熟络，但也算
入门，决定年前总结下，所以有了此文。Git博大精深，还有很多的东西需要学习，
比如自己搭建啊，1些便利工具的使用啊，1些疑问杂症解决方案啊等等，固然
这就是下1话的事了。本文讲述的是Git基础的1些东西，没有Git大法那个系列
那末通熟易懂，但是还是对关键性的知识点进行了浅析，相信看完本文你的Git
使用会更进1步，谢谢~
按大类划分，分为两种状态：Tracked(已跟踪)和Untracked(未跟踪)，
根据是：该文件是不是已加入版本控制？
流程简述：
假定某个项目已加入版本控制系统
- 1.新建1个文件，该文件处于 Untracked 状态；
- 2.通过git add命令添加到缓存区，此时文件处于Tracked状态又或说
此时这个文件已被版本控制系统所跟踪，而且他处于Staged(暂存)状态；- 3.通过git commit命令把暂存区的文件提交提交到本地仓库，此时文件
处于Unmodified(未修改)状态；- 4.此时如果去编辑这个文件，文件又会变成Modified(修改)状态；
Git关心的是：文件整体是不是产生变化，而SVN关心的是：文件内容的具体差异！
SVN每次提交记录的是：哪些文件进行了修改，和修改了哪些行的哪些内容
如图：版本2中记录的是文件A和C的变化，而版本3中记录文件C的变化，以此类推；
而Git中，其实不保存这些前后变化的差异数据，而是保证全部缓存区中的所有文件，
又叫快照，有变化的文件保存，没变化的文件不保存，而是对上1次的保存的快照
做1个链接！由于这类不同的保存方式，Git切换分支的速度比SVN快很多！
分为4个对象：
blob对象：寄存文件数据；
tree对象：目录，内容为blob对象的指针或其他tree对象的指针
commit对象：快照，包括指向前1次提交对象的指针，commit相干的信
通过索引找到文件快照。
tag对象：1种特殊的commit对象，1般对某次重要的commit加TAG，以示重要(方便找)
辨别global 和 local，前者代表 全局设置，就是设置了在全部系统中，
所有的带Git版本管理的项目都是这样的配置；后者代表 本地设置 即在某个项目
中独立的设置，后者优先级高于前者。比如全局设置的用户名是”Coder-pig”，本地
设置的是”Jay”，commit的时候author就是Jay而不是Coder-pig。
处理命令行，还可以直接修改对应文件：
全局配置文件：etc/gitconfig
本地配置文件：当前仓库/.git/config
# 安装完Git后第1件要做的事，设置用户信息(global可换成local在单独项陌生效)： git config --global user.name "用户名" # 设置用户名 git config --global user.email "用户邮箱" #设置邮箱 git config --global user.name # 查看用户名是不是配置成功 git config --global user.name # 查看邮箱是不是配置 # 其他查看配置相干 git config --global --list # 查看全局设置相干参数列表 git config --local --list # 查看本地设置相干参数列表 git config --system --list # 查看系统配置参数列表 git config --list # 查看所有Git的配置(全局+本地+系统)
git help 命令 # 如：git help init
git init 仓库名 # 创建1个新的带Git仓库的项目 git init # 为已存在的项陌生成1个Git仓库
可使用git add 文件名，将工作空间的文件添加到暂存区，或批量添加文件
git add 文件名 # 将工作区的某个文件添加到暂存区 git add -u # 添加所有被tracked文件中被修改或删除的文件信息到暂存区，不处理untracked的文件 git add -A # 添加所有被tracked文件中被修改或删除的文件信息到暂存区，包括untracked的文件 git add . # 将当前工作区的所有文件都加入暂存区 git add -i # 进入交互界面模式，按需添加文件到缓存区
附：交互界面模式示例
上图流程：
1.先在GitForTest的文件夹里创建了两个文件
2.键入git add -i，进入后，键入4，选择添加untracked的文件
3.他给我们列出了untracked的文件，然后我们根据序号来添加文件
4.输入?会弹出相干提示，然后直接回车，结束选择！
5.然后再次输入git add -i，输入4，可以看到已不存在untacked的文件了！
将未tracked的文件添加到缓存区后，Git就会开始跟踪这个文件了！
对1些比如：自动生成的文件，日志，临时编译文件等，就
没必要进行跟踪了，这个时候可以编写.gitignore文件，在里面
把不需要跟踪的文件或文件夹都写上，git就不会对这些文件进行跟踪！
另外.gitignore文件与.git文件夹在同级目录下！
如果不想自己写，可以直接到：https://github.com/github/gitignore 复制粘贴！
也能够自行编写，支持简化了的正则表达式(规范与示例模板摘自：Git王者超神之路)
- * ： 匹配零个或多个任意字符
- [abc]：只匹配括号内中的任意1个字符
- [0⑼]：- 代表范围，匹配0⑼之间的任何字符
- ?：匹配任意1个字符
- *：匹配任意的中间目录，例如a/*/z可以匹配:a/z,a/b/z,a/b/c/z等
示例模板：
# 疏忽所有以 .c结尾的文件 *.c # 但是 stream.c 会被git追踪 !stream.c # 只疏忽当前文件夹下的TODO文件, 不包括其他文件夹下的TODO例如: subdir/TODO /TODO # 疏忽所有在build文件夹下的文件 build/ # 疏忽 doc/notes.txt, 但不包括多层下.txt例如: doc/server/arch.txt doc/*.txt
# 疏忽所有在doc目录下的.pdf文件
doc/**/*.pdf
git commit -m "提交说明" # 将暂存区内容提交到本地仓库 git commit -a -m "提交说明" # 跳过缓存区操作，直接把工作区内容提交到本地仓库
如果不加-m “提交说明”，git会让用你让默许编辑器(如vi)来编写提交说明，
vi难用(最少我不会用)，要末别漏掉-m “提交说明”，要末自己设置编译器：
git config --global core.edit 喜欢的编辑器
除此以外，有时可能需要修改上次提交的内容，比如修改提交说明，或修改文件等：
# 合并暂存区和最近的1次commit，生成新的commit并替换掉老的
# 如果缓存区没内容，利用amend可以修改上次commit的提交说明
# 注：由于amend后生成的commit是1个全新的commit，旧的会被
# 删除，所以别在公共的commit上使用amend！切记！
git commit --amend
git commit --amend --no-edit # 沿用上次commit的提交说明
git status # 查看工作区与暂存区确当前情况 git status -s # 让结果以更简短的情势输出
git diff # 工作区与缓存区的差异 git diff 分支名 #工作区与某分支的差异，远程分支这样写：remotes/origin/分支名 git diff HEAD # 工作区与HEAD指针指向的内容差异 git diff 提交id 文件路径 # 工作区某文件当前版本与历史版本的差异 git diff --stage # 工作区文件与上次提交的差异(1.6 版本前用 --cached) git diff 版本TAG # 查看从某个版本后都改动内容 git diff 分支A 分支B # 比较从分支A和分支B的差异(也支持比较两个TAG) git diff 分支A...分支B # 比较两分支在分开后各自的改动 # 另外：如果只想统计哪些文件被改动，多少行被改动，可以添加 --stat 参数
git log # 查看所有commit记录(SHA-A校验和，作者名称，邮箱，提交时间，提交说明) git log -p -次数 # 查看最近多少次的提交记录 git log --stat # 简略显示每次提交的内容更改 git log --name-only # 仅显示已修改的文件清单 git log --name-status # 显示新增，修改，删除的文件清单 git log --oneline # 让提交记录以精简的1行输出 git log –graph –all --online # 图形展现分支的合并历史 git log --author=作者 # 查询作者的提交记录(和grep同时使用要加1个--all--match参数) git log --grep=过滤信息 # 列出提交信息中包括过滤信息的提交记录 git log -S查询内容 # 和--grep类似，S和查询内容间没有空格 git log fileName # 查看某文件的修改记录，找背锅专用
除此以外，还可以通过 –pretty 对提交信息进行定制，比如：
更多规则与定制以下(摘自：Git王者超神之路)，或参见：Viewing the Commit History：
format对应的经常使用占位符：(注：作者是指最后1次修改文件的人，提交者是提交该文件的人)
| 占位符 | 说明 | 占位符 | 说明 |
|---|---|---|---|
| %H | 提交对象（commit）的完全哈希字串 | %h | 提交对象的简短哈希字串 |
| %T | 树对象（tree）的完全哈希字串 | %t | 树对象的简短哈希字串 |
| %P | 父对象（parent）的完全哈希字串 | %p | 父对象的简短哈希字串 |
| %an | 作者（author）的名字 | %ae | 作者的电子邮件地址 |
| %ad | 作者修订日期（可以用 –date= 选项定制格式） | %ar | 按多久之前的方式显示 |
| %cn | 提交者(committer)的名字 | %ce | 提交者的电子邮件地址 |
| %cd | 提交日期 | %cr | 提交日期，按多久之前的方式显示 |
| %s | 提交说明 |
|
|
1些其他操作：
| 选项 | 说明 |
|---|---|
| -p | 按补钉格式显示每一个更新之间的差异 |
| –stat | 显示每次更新的文件修改统计信息(行数) |
| –shortstat | 只显示 –stat 中最后的行数修改添加移除统计 |
| –name-only | 仅在提交信息后显示已修改的文件清单 |
| –name-status | 显示新增、修改、删除的文件清单 |
| –abbrev-commit | 仅显示 SHA⑴ 的前几个字符，而非所有的 40 个字符 |
| –relative-date | 使用较短的相对时间显示（比如，“2 weeks ago”） |
| –graph | 显示 ASCII 图形表示的分支合并历史 |
| –pretty | 格式定制，可选选项有：oneline，short，full，Fullerton和format(后跟指定格式) |
还有1些限制log输出的选项
| 选项 | 说明 |
|---|---|
| -(n) | 仅显示最近的 n 条提交 |
| –since, –after | 仅显示指定时间以后的提交。 |
| –until, –before | 仅显示指定时间之前的提交。 |
| –author | 仅显示指定作者相干的提交。 |
| –committer | 仅显示指定提交者相干的提交。 |
| –grep | 仅显示含指定关键字的提交 |
| -S | 仅显示添加或移除某个关键字的提交 |
git brame 文件名 # 查看某文件的每行代码的作者，最新commit和提交时间
可以为常见的命令起个简单的别名，就不用每次都敲完全命令，比如可以设置：
status为st，checkout为co ; commit为ci ; branch为br等
git config --global alias.st status
对某些提交，我们可以为它打上Tag，表示这次提交很重要，
比如为1些正式发布大版本的commit，打上TAG，当某个版本
出问题了，通过TAG可以快速找到此次提交，拿到SHA1值，再
去查找问题，比起1个个commit看，省事很多！
Git标签分两种：轻量标签 和 附加标签
前者只是在提交上加个Tag，指向提交的Hash值；
而后者还会保存打标签者的信息，时间和附加信息；
git tag 标记内容 # 轻量标签 git tag -a 标记内容 -m "附加信息" # 附加标签
如果想为之前的某次commit打TAG的话，可以先找出SHA1值，设置调下述命令：
git tag -a 标记内容 版本id # 比如：git tag -a v1.1 bcfed96
默许情况，git push不会把标签推送TAG到远程仓库，如果想推送到服务器，可以：
git push origin 标记内容 # 推送某标签到 # 删除所有本地仓库中不存在的TAG： git push origin --tags
另外，可以在新建分支的时候也加上TAG
git checkout -b 分支名 标记内容
最后，还可以用show命令查看标签对应的信息
git show 标记内容
如果在工作区直接删除被Git Tracked的文件，暂存区中还会存在该文件，
此时键入：git status，会是这样：
Git告知你工作区的文件被删除，你可以 删掉暂存区里的文件或 恢复被删文件
# 删除暂存区中的文件： git rm 文件名
git commit -m "提交说明" # 误删恢复文件 git checkout -- 文件名 # 另外注意：git checkout会抛弃当前工作区的更改!!!不可恢复！！！务必谨慎！！！
如果更改后add到了暂存区，想恢复原状，下述指令可让文件恢复原状：
git reset HEAD 文件名
git checkout 文件名
文件已commit了，想恢复成上次commit的版本或上上次，可以：
git reset HEAD^ # 恢复成上次提交的版本 git reset HEAD^^ # 恢复成上上次提交的版本，就是多个^，以此类推或用~次数 git reset --hard 版本号 # git log查看到的SHA1值，取前7位便可，根据版本号回退
reset命令其实就是：重置HEAD指针，让其指向另外一个commit
而这个动作可能会对工作区与缓存区造成影响，举个例子
- 本来的分支线：- A - B - C (HEAD, master)
- git reset B后：- A - B (HEAD, master)
解释：看不到C了，但是他还是存在的，可以通过git reset C版本号找回，条件是
C没有被Git当作垃圾处理掉(1般是30天)。
reset3个可选参数解析：
- –soft：只是改变HEAD指针指向，缓存区和工作区不变；
- –mixed：修改HEAD指针指向，暂存区内容丢失，工作区不变；
- –hard：修改HEAD指针指向，暂存区内容丢失，工作区恢复之前状态；
Git会记住你输入的每一个Git指令，比如上面的git reset 切换成1个旧的
commit，然后git log后发现新提交的记录没了，想切换回新的那次commit，
可以先调git reflog 获得新commit的SHA1码，然后git reset 回去。
git reflog
注意：这个指令记录不会永久保存！Git会定时清算用不到的对象！！！
有时可能我们想撤消某次提交所做的更改，可使用revert命令
git revert HEAD # 撤消最近的1个提交 git revert 版本号 # 撤消某次commit
不是真的把提交给撤消了，而是生成1个新的提交来覆盖旧的提交，被撤消的提交
和新的提交记录都会保存！！！不信你再调1次revert HEAD 会发现被撤消的更改
又变回来了，另外，每次revert后，都需要发起新的commit！
简单点说，撤消的只是文件变化，提交记录照旧是存在的！
git show 提交id # 查看某次commit的修改内容
git rev-parse 分支名 # 查看分支commit的版本号，可以写HEAD
由于你的某次误操作致使commit丢失，如果git reflog都找不到，你
可以斟酌使用git fsck，找到丢失的对象的版本id，然后恢复便可。
git fsck --lost-found
提交记录串成的时间线，默许初始创建的分支(时间线) —— master分支，
如果不切换到其他分支上，每次commit生成的快照都会串在这条分支上！
另外还有个 —— HEAD指针，该指针指向正在工作的本地分支，前面的版
本回退其实修改的就是这个HEAD指针的指向！
比如：在master分支上履行4次commit，分支的状态图以下
不难发现这样的规律：
- 每次commit，master都会向前移动1步，指向最新的提交
- HEAD则指向正在工作的本地分支，而git reset修改的就是HEAD指针的指向！
通过两个场景来体会创建其他分支的必要性
- 场景1：
项目1般都是1步步迭代升级的，有大版本和小版本的更新：大版本1般是改
头换面的更新，比如UI大改，架构大改，版本是：v2.0.0这样；小版本的更新
1般是UI小改，Bug修复优化等，版本是：v2.0.11这样；
只有1条master分支，意味着：你的分支线会非常非常的长,假设你已发布
到了第2个大版本，然后用户反馈第1个版本有很严重的BUG，这时候候想切回
第1个版本改BUG，然后改完BUG切会第2个大版本，想一想够戗。- 场景2：
只有1个master分支的话，假设某次提交冲突了，而这个冲突很难解决或
解决不了， 那末，那个全部开发就卡住在这里了，没法继续向落后行了！
为了解决只有1个master分支引发的问题，可以引入分支管理，最简单的1种策略以下：
在master分支上开辟1个新的develop分支，然后我们根据功能或业务，再在develop
分支上另外开辟其他分支，完成份支上的任务后，再将这个分支合并到develop分支上！
master与develop分支都作为长时间分支，而其他创建的分支作为临时性分支！
简述各个分支的划分：
git branch 分支名 # 创建分支 git branch # 查看本地分支
比如在master分支上创建develop分支，此时的分支状态以下：
git checkout 分支名 # 切换分支 git checkout -b 分支名 # 创建分支同时切换到这个分支
切换到develop分支后，改点东西，再commit，此时的分支状态以下：
git checkout master 切回master分支，打开之前修改的文件，发现内容
并没有产生更改，由于刚刚的更改是在develop上提交的，而master上没有
变化，此时的分支状态以下：
Git中，可使用 git merge 和 git rebase 两个命令来进行分支的合并
git merge合并分支
合并的方式分为两种：快速合并 和 普通合并，二者的区分在于：
前者合并后看不出曾做过合并，而后合并后的历史会有分支记录，如图：
快速合并：
普通合并 ：
示例：
快速合并，把develop分支合并到master分支上，来到master分支后，键入下述命令
git merge develop
打开文件：
普通合并，切到develop分支下，修改note_2.txt的内容，再通过下述指令合并分支：
注：–no-ff参数表示禁用快速合并！
git merge --no-ff -m "合并的信息(TAG)" develop
分支线情况：
git reabse合并分支
rebase(衍合)，发现很多所谓的教程把这个东西写得太深奥了，其实并没有
那末复杂，只是这类合并会使得树整洁，易于跟踪，举个简单的例子来对照下
有1个项目由两个人同时开发， 当前远程仓库的提交记录是这样的：
然后A和B各自开了1个条分支来完成相应功能，接着他们在自己的
分支上都做了屡次的commit，此时两人的分别分支线是这样的：
A先合并，再到B合并，这里我们假定两人做的是完全不关联的模块，合并没有冲突
merge合并
rebase合并
用法：
git rebase 想合并到哪一个分支的分支名
在我们合并分支的时候，有时会遇到合并冲突，然后合并失败的问题，
此时需要我们先解决冲突后才能进行合并，个人开发倒很少会遇到，多人
开发的时候遇到合并冲突则是家常便饭。
1个最简单的例子，A和B在develop分支上开辟出两个分支来完成相干的
功能，A做完了，把自己的分支合并到develop分支，此时develop分支向前
移动了几次commit，接着B也完成了他的功能，想把自己分支合并到develop
分支，如果改动的文件和和A改动的文件相同的话，此时就会合并失败，
然后需要处理完冲突，才能够继续合并！简单摹拟下这个例子，先试试merge！
merge分支后处理冲突
打开冲突文件，然后处理冲突部份，保存甚么代码你自己决定，处理完后把
<<< 和 >>> 这些去掉：
处理后：
然后add，然后commit便可，合并结束：
此时的分支线：
接着试试
rebase分支后处理冲突
重新来1遍，然后把A直接merge到master，再切到B，rebase master，此时出现
合并冲突，这里有3个可选的操作：
git rebase --continue # 处理完冲突后，继续处理下1个补钉 git rebase --abort # 放弃所有的冲突处理，恢复rebase前的情况 git rebase --skip # 跳过当前的补钉，处理下1个补钉，不建议使用，补钉部份的commit会丢失！
好的，有3次补钉要处理，1个个来：
处理后：
接着git add 添加修改后的文件，git rebase –continue继续处理补钉：
接侧重复之前的进程：
处理后：
第3个补钉是与A分支无关联的改动，所以没有冲突，所以也就直接合并了！
如果合并中途出了甚么过失可以git rebase –abort 恢复rebase前的状态！
最后看下分支线会发现是1条直线，这也是用rebase合并分支的优点：
附上栗子，可以自己试试：GitTest.7z
对合并完的分支，基本都没甚么作用了，可使用下述命令删除：
git branch -d 分支名 # 删除分支，分支上有未提交更改是不能删除的 git branch -D 分支名 # 强行删除分支，虽然这个分支上有未提交的更改
两步，找出被删除分支的最新commit的版本号，然后恢复分支
git log --branches="被删除的分支名" # 找到被删分支最新的commitb版本号 git branch 分支名 版本号(前7位便可) # 恢复被删分支
有时我们可能在某个分支上正编写着代码，然后有1些突发的情况，需要
我们暂时切换到其他分支上，比如要紧急修复bug，或切换分支给同事
review代码，此时如果直接切换分支是会提示切换失败的，由于这个分支
上做的更改还没有提交，你可以直接add后commit，然后再切换，不过我们
习惯写完某个功能再提交，我们想：
先暂存这个分支上的改动，切去其他分支上弄完事，然后回来继续
继续在之前的改动上写代码。
那末可使用：
git stash # 保存当前的改动
然后放心的切换分支，然后再切换回来，接着使用：
git stash apply # 恢复保存改动
另外有1点1定要注意！！！可以stash多个改动！！如果你切换
到另外一个分支又stash了，然后切换回来stash apply是恢复成另外一个
分支的stash！！！
如果你这样stash了屡次的话，我建议你先键入：
git stash list # 查看stash列表
找到自己想恢复的那个
比如我这里恢复的应当是netword上的stash，而第1个stash是devlop上的
直接git stash apply恢复的就是这个，但是恢复的应当是network的那个stash：
git stash apply stash@{1}
就是这样，按自己需要恢复便可！
git branch -m 老分支名 新分支名 # 分支重命名
用于代码托管，可以自己搭建远程仓库，或选择专业的代码托管平台：
自己搭建的好处有：可控，内网安全，可以做1些定制，比如集成编译，IM等，
固然，肯定是需要1些学习本钱的，(PS：我厂就是自己搭的Gitlab)
常见的代码托管平台(自己搜关键字去~)：
Github，Git@OSC，GitCafe，GitLab，coding.net，gitc，BitBucket，Geakit，Douban CODE
首先建立好与本地仓库同名的远程仓库，然后复制下远程仓库的地址，比如：
键入下述命令关联本地与远程仓库
git remote add origin 远程仓库地址
可以键入下述命令可查看远程仓库状态
接着把本地仓库推送到远程仓库，这里的 -u参数 作为第1次提交使用，
作用是把本地master分支和远程master分支关联起来(设置默许远程主机)，
后续提交不需要这个参数！
git push -u origin master
另外，如果想修改远程仓库地址，可键入：
git remote set-url origin 远程仓库地址 # 也能够先删除origin后再添加 git remote rm origin # 删除仓库关联 git remote add origin 远程仓库地址 # 添加仓库关联
或直接修改.git文件夹中的config文件，直代替换圈住位置
还要说明1点，origin 其实不是固定的东西，只是后面仓库地址的1个 别名！！
可以写成其他的东西，然后你也能够设置多个仓库关联，用不同的别名标志，比如：
git remote add github https://github.com/coder-pig/SimpleTea.git git remote add osc git@git.oschina.net:coder-pig/SimpleTea.git
把项目推送到远程仓库后，其他开发者就能够把项目clone到本地
git clone 仓库地址 # 克隆项目到当前文件夹下 git clone 仓库地址 目录名 # 克隆项目到特定目录下
关于获得远程服务器更新的方式有两种，他们分别是fetch和pull，
虽然都可以获得远程服务器更新，但是二者却又是不1样的。
git fetch：
仅仅只是从远处服务器获得到最新版本到本地，假设你不去合并(merge)
的话，本地工作空间是不会产生变化的！比如：
我们在Github上创建1个README.md文件，然后调 git fetch 去获得远程
仓库的更新。
git pull：
1步到位，或说：pull = fetch + merge，比如：一样修改Github上的
README.md 文件，然后git pull 同步远程仓库的更新
区分不言而喻，实际开发中，使用git fetch会更安全1些，毕竟merge的时候
我们可以查看更新的情况，再决定是不是进行合并，固然看实际需要吧！
依照前面所讲，在本地开辟分支来完成某些工作，本地提交了屡次后，
你想把分支推送到远程仓库，此时远程仓库并没有这个分支，你可以：
git push origin 分支名 # 推送本地分支的内容到远程分支
git branch -r # 查看所有分支
git checkout -b 本地分支 远程分支 # 会在本地新建分支，并自动切换到该分支 git fetch origin 远程分支:本地分支 # 会在本地新建分支，但不会自动切换，还需checkout git branch --set-upstream 本地分支 远程分支 # 建立本地分支与远程分支的链接
git push origin :分支名 # 就是前面的本地分支名改成1个问号而已
先删除远程分支，然后重命名本地分支，接着再Push到远程仓库
不知道仔细的你有无发现，仓库地址除Https外，还有1个SSH，
这里我们简单介绍下二者的区分，第1点：使用Https url可以任意克隆
Github上的项目；而是用SSH url克隆的话，你必须是项目的具有者或
管理员，而且还要添加SSH Key，否则会没法克隆。还有1点是，
Https每次push都需要输入用户名和密码，而使用SSH则不需要输入
用户名如果配置SSH Key时设置了密码，则需要输入密码，否则直接
git push就能够了！
另外，SSH，Secure shell(安全外壳协议)，专为远程登陆会话
与其他网络服务提供安全性的协议，而SSH传输的数据是可以经过紧缩的，
可以加快传输的速度，出于安全性与速度，我们优先斟酌使用SSH协议，
而SSH的安全验证规则又分为基于密码和基于密钥两种！
我们这里用的是基于第2种的，即在本地创建1对密钥，
公钥(id_rsa.pub)和私钥(id_rsa),然后把公钥的内容贴到
Github账号的ssh keys中，这样就建立了本地和远程的认证关系，
当我们再push到远程仓库，会将你本地的公共密钥与服务器的进行匹配，
如果1致验证通过直接推送更新！
下面我们来建立ssh key，首先来到电脑的根目录下，这里假定我们没
创建过SSH key：
履行完ssh-keygen那个指令后，后面顺次要你输入文件名，
直接回车会生成两个默许的秘钥文件，接着提示输入密码，
直接回车，如果这里你输入密码了的话，那末push的时候
你还是需要输入密码，接着又输多1次密码，一样回车，
然后出现最下面的这串东西就说明ssh key已创建成功了！
我们接着可以用编辑器打开id_rsa.pub文件或键入:
