GitHub安装和使用
GitHub是一个基于git的代码托管平台，付费用户可以建私人仓库，一般的免费用户只能使用公共仓库，也就是代码要公开。
Github 由Chris Wanstrath, PJ Hyett 与Tom Preston-Werner三位开发者在2008年4月创办，主要提供基于git的版本托管服务。
GitHub对于程序员的帮助如下图所示：
一.GitHub下载与安装
要想使用github，第一步是注册github账号，github官网地址：https://github.com/。 之后就可以创建仓库了（免费用户只能建公共仓库）Create a New Repository，填好名称后Create，之后会出现一些仓库的配置信息。
以win7 32位系统为例，下载对应版本的GitHub（下载地址: https://git-for-windows.github.io/），在官方下载完后，安装到Windows Explorer integration的时候，将选项中的“Git Bash here”和“Git GUI here”打对勾。
然后就一直next直到Finish即可。
安装完成后，在开始菜单里找到“Git”->“Git Bash”，出现一个类似命令行窗口的东西，就说明Git安装成功。如下图所示：
安装完成后，还需要最后一步设置，在命令行输入：
$ git config --global user.name "Your Name" $ git config --global user.email "email@example.com"
因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。你也许会担心，如果有人故意冒充别人怎么办？这个不必担心，首先我们相信大家都是善良无知的群众，其次，真的有冒充的也是有办法可查的。
注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。
二.GitHub使用
我们先来创建一个版本库。
什么是版本库呢？版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。
其实，创建一个版本库非常简单。
第一步，选择一个合适的地方，创建一个空目录：
Administrator@LZY-PC MINGW32 /e/Git (master) $ mkdir test2 Administrator@LZY-PC MINGW32 /e/Git (master) $ cd test2 Administrator@LZY-PC MINGW32 /e/Git/test2 (master) $ pwd /e/Git/test2
pwd命令用于显示当前目录。在Windows系统下，为了避免遇到各种莫名其妙的问题，请确保目录名（包括父目录）不包含中文。
第二步，通过git init命令把这个目录变成Git可以管理的仓库：
$ git init Initialized empty Git repository in E:/Git/test2/.git/
这样的话，Git瞬间就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），细心的读者可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。
如果你没有看到.git目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看见。
$ ls -an total 4 drwxr-xr-x 1 197108 197121 0 五月 1 13:34 ./ drwxr-xr-x 1 197108 197121 0 五月 1 13:30 ../ drwxr-xr-x 1 197108 197121 0 五月 1 13:34 .git/
当然，我们也不一定必须在空目录下创建Git仓库，选择一个已经有东西的目录也是可以的。
第三步，把文件添加到版本库。
首先这里再明确一下，所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。
不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，前面我们举的例子只是为了演示，如果要真正使用版本控制系统，就要以纯文本方式编写文件。
因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。
建议你下载Notepad++代替记事本，不但功能强大，而且免费！记得把Notepad++的默认编码设置为UTF-8 without BOM即可：
接着，我们编写一个test2.txt文件，内容如下：
Hellow my friend! Where are you from?
一定要放到test2目录下（子目录也行），因为这是一个Git仓库，若放到其他地方，Git再厉害也找不到这个文件。
把一个文件放到Git仓库只需要两步：
①用命令git add告诉Git，把文件添加到仓库：
$ git add test2.txt
执行上面的命令，没有任何显示，这就对了，Unix的哲学是“没有消息就是好消息”，说明添加成功。
②用命令git commit告诉Git，把文件提交到仓库：
$ git commit -m "create a new txt file" [master (root-commit) 7795d01] create a new txt file 1 file changed, 2 insertions(+) create mode 100644 test2.txt
简单解释一下，git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。
如果嫌麻烦不想输入-m "xxx"行不行？确实有办法可以这么干，但是强烈不建议你这么干，因为输入说明对自己、对别人阅读都很重要。
git commit命令执行成功后会告诉你，1个文件被改动（我们新添加的readme.txt文件），插入了两行内容（readme.txt有两行内容）。
另外，commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：
Administrator@LZY-PC MINGW32 /e/Git/test2 (master) $ git add test2.txt test3.txt Administrator@LZY-PC MINGW32 /e/Git/test2 (master) $ git commit -m "2 files" [master fc816cb] 2 files 1 file changed, 1 insertion(+) create mode 100644 test3.txt
总的来说，初始化一个Git仓库，使用git init命令。
添加文件到Git仓库，分两步：
-
第一步，使用命令
git add <file>，注意，可反复多次使用，添加多个文件； -
第二步，使用命令
git commit，完成。
现在，我们已经成功地添加并提交了一个test2.txt文件，我们继续修改该文件，改成如下内容：
Hellow my friend!! Where are you from? 关关雎鸠，在河之洲， 窈窕淑女，君子好逑。
接着，运行git status命令看看结果：
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: test2.txt
no changes added to commit (use "git add" and/or "git commit -a")
git status命令可以让我们时刻掌握仓库当前的状态，上面的命令告诉我们，test2.txt被修改过了，但还没有准备提交的修改。
虽然Git告诉我们test2.txt被修改了，但如果能看看具体修改了什么内容，自然是很好的。比如你休假两周从国外回来，第一天上班时，已经记不清上次怎么修改的test2.txt，所以，需要用git diff这个命令看看：
$ git diff diff --git a/test2.txt b/test2.txt index fd65289..a84a92a 100644 --- a/test2.txt +++ b/test2.txt @@ -1,2 +1,4 @@ Hellow my friend!! -Where are you from? \ No newline at end of file +Where are you from? +关关雎鸠，在河之洲， +窈窕淑女，君子好逑。 \ No newline at end of file
git log命令显示从最近到最远的提交日志。
$ git log
commit fc816cbfbb61bf90d66bf01e3ad67b08f07de80e (HEAD -> master)
Author: lzy666 <75671905@qq.com>
Date: Tue May 1 13:57:30 2018 +0800
2 files
commit 7795d017ddd7d11b2d9959acaad734a8877ac3bd
Author: lzy666 <75671905@qq.com>
Date: Tue May 1 13:49:31 2018 +0800
create a new txt file
如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数：
$ git log --pretty=oneline fc816cbfbb61bf90d66bf01e3ad67b08f07de80e (HEAD -> master) 2 files 7795d017ddd7d11b2d9959acaad734a8877ac3bd create a new txt file
需要友情提示的是，上面显示的一大串类似3628164...882e1e0的是commit id（版本号），和SVN不一样，Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示。为什么commit id需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本号，那肯定就冲突了。
每提交一个新版本，实际上Git就会把它们自动串成一条时间线。如果使用可视化工具查看Git历史，就可以更清楚地看到提交历史的时间线：
Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本。上一个版本是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。
比如说，我们要把当前版本回退到上一个版本“add distributed”，就可以使用git reset命令：
$ git reset --hard HEAD^
如果要查看当前版本的文件的内容，则操作如下：
$ cat test2.txt Hellow my friend!! Where are you from?
总的来说，HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id；在穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本；要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
Git有工作区和暂存区两个区域，即工作区和暂存区。相比较而言，其他版本控制系统如SVN无暂存区的概念。
工作区（Working Directory）是我们在电脑里能看到的目录，比如我的test2文件夹就是一个工作区：
工作区内有一个隐藏目录.git，这个.git其实不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
前面讲了，我们把文件往Git版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
现在，我们修改test2.txt里的内容，再创建LICENSE文件（内容随意），然后查看状态：
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: test2.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
LICENSE
这时，暂存区的状态就变成这样了：
所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。
$ git commit -m "aa"
现在版本库变成了这样，暂存区就没有任何内容了：
应该说，暂存区是Git非常重要的概念，弄明白了暂存区，就弄明白了Git的很多操作到底干了什么。
git checkout -- file可以丢弃工作区的修改：
$ git checkout -- test2.txt
命令git checkout -- test2.txt意思就是，把test2.txttest2.txttest2.txt
总之，就是让这个文件回到最近一次git commit或git add时的状态。
git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令。
另外，命令git rm file用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
到目前为止，我们已经掌握了如何在Git仓库里对一个文件进行时光穿梭，你再也不用担心文件备份或者丢失的问题了。
Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。
由于我们的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：
第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：
$ ssh-keygen -t rsa -C "youremail@example.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文件的内容；然后点“Add Key”，你就应该看到已经添加的Key：
为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。
当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。
最后友情提示，在GitHub上免费托管的Git仓库，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放进去。
如果你不想让别人看到Git库，有两个办法，一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。另一个办法是自己动手，搭一个 Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。这个方法我们后面会讲到的，相当简单，公司内部开发必备。
确保你拥有一个GitHub账号后，我们就即将开始远程仓库的学习。
现在的情景是，你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。
首先，登陆GitHub，然后，在右上角找到“Create a new repo”按钮，在Repository name填入test2，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库。
目前，在GitHub上的这个test2仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。
为了测试方面，我在本地再新建一个test3的文件夹，在里面再新建一个名称为a.txt的文件，操作如下：
$ git init Initialized empty Git repository in E:/Git/test3/.git/ $ touch a.txt $ vim a.txt $ cat a.txt hello world how do you do? $ git add a.txt warning: LF will be replaced by CRLF in a.txt. The file will have its original line endings in your working directory. $ git commit -m ppp [master (root-commit) 95bc7cc] ppp 1 file changed, 2 insertions(+) create mode 100644 a.txt
接着，在GitHub里再建一个Git仓库test3。
现在，我们根据GitHub的提示，在本地的test3仓库下运行命令：
$ git remote add origin3 git@github.com:lzy666/test3.git
添加后，远程库的名字就是origin3，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
下一步，就可以把本地库的所有内容推送到远程库上：
$ git push -u origin3 master
把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
推送成功后，可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样：
从现在起，只要本地作了add与commit提交，也就是可以通过下述命令：
$ git add c.txt $ git commit -m ee $ git push origin3 master
便可以把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！
另外，在SSH警告方面，当你第一次使用Git的clone或者push命令连接GitHub时，会得到一个警告：
The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established. RSA key fingerprint is xx.xx.xx.xx.xx. Are you sure you want to continue connecting (yes/no)?
这是因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。
Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：
Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
这个警告只会出现一次，后面的操作就不会有任何警告了。
如果你实在担心有人冒充GitHub服务器，输入yes前可以对照GitHub的RSA Key的指纹信息是否与SSH连接给出的一致。
要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，给我们的工作和学习提供了很多方便。
总的来说，我们上面学习的内容是：先有本地库，后有远程库的时候，如何关联远程库。
接下来，我们学习从远程库克隆。
首先，登陆GitHub，创建一个新的仓库，名字叫test4；我们勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件：
现在，远程库已经准备好了，下一步是用命令git clone克隆一个本地库：
这时，在E：\Git目录下会增加一个名称为test4.txt：
如果有多个人协作开发，那么每个人各自从远程克隆一份就可以了。
你也许还注意到，GitHub给出的地址不止一个，还可以用 https://github.com/lzy666/test4.git 这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。
GitHub里有个分支的概念。分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
在版本回退里，我们已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：
每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长：
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，再把HEAD指向dev，就表示当前分支在dev上：
不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
可见，Git合并分支也很快，就是改改指针，工作区内容也不变。合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
接下来，我们就进行操作分支的实践。
首先，我们创建dev分支，然后切换到dev分支：
$ git checkout -b dev Switched to a new branch 'dev'
git checkout命令加上-b参数表示创建并切换。
$ git branch * dev master
git branch命令会列出所有分支，当前分支前面会标一个*号。如果要从dev分支切换到master分支，执行如下：
$ git checkout master Switched to branch 'master'
接下来，我们先在dev分支上增加一行并提交后，在该分支下可以看到，如果切换到master分支上，就会看不到：
$ cat README.md # test4 从远程库克隆 gggg xxxxxxxx dev下的一行，哈哈 $ git branch * dev master $ git add README.md $ git commit -m dd [dev 9ae2ae0] dd 1 file changed, 1 insertion(+) $ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 1 commit. $ cat README.md # test4 从远程库克隆 gggg
可见，我们从dev切换回master分支后，再查看一个README.md文件，刚会发现dev分支下添加的内容不见了。这是因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：
现在，我们把dev分支的工作成果合并到master分支上：
$ git merge dev Updating 00c0186..9ae2ae0 Fast-forward README.md | 2 ++ 1 file changed, 2 insertions(+) $ git branch dev * master $ cat README.md # test4 从远程库克隆 gggg xxxxxxxx dev下的一行，哈哈
git merge命令用于合并指定分支到当前分支。合并后，再查看README.md的内容，就可以看到，和dev分支的最新提交是完全一样的。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。合并完成后，就可以放心地删除dev分支了：
$ git branch -d dev Deleted branch dev (was 9ae2ae0). $ git branch * master
删除后，查看branch，就只剩下master分支了。因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
查看分支：git branch 创建分支：git branch <name> 切换分支：git checkout <name> 创建+切换分支：git checkout -b <name> 合并某分支到当前分支：git merge <name> 删除分支：git branch -d <name>
另外，当分支dev修改一个文件并提交，master也修改该文件并提交后，master在执行合并分支时，会出现冲突：
$ git merge dev Auto-merging b.txt CONFLICT (add/add): Merge conflict in b.txt Automatic merge failed; fix conflicts and then commit the result.
这说明，两个分支各有提交，如下图所示：
打开工作区的文件：
$ cat b.txt <<<<<<< HEAD from master ======= from dev >>>>>>> dev
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容。
我们根据需要修改后再次提交，如下图所示：
这时再合并分支就会显示正常：
$ git merge dev Already up to date. $ cat b.txt from master from dev
关于GitHub的操作，先介绍到这里。以后待续。
