Git和GitHub
概念
git --- 版本控制工具（命令）。
工具介绍官方网站：http://git-scm.com
工具下载地址：http://git-scm.com/download/
git是一个开源的分布式版本控制系统，用以有效、高速的处理从很小到非常大的项目版本管理。git是个工具，在linux里面也就类似gcc这样的工具一样，是一个shell命令。git是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。Torvalds开始着手开发git是为了作为一种过渡方案来替代BitKeeper，后者之前一直是Linux内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得BitKeeper的许可证并不适合开放源码社区的工作，因此 Torvalds决定着手研究许可证更为灵活的版本控制系统。尽管最初git的开发是为了辅助Linux内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了git。例如：很多Freedesktop的项目也迁移到了git上。
Github --- 一个平台（网站）。
Github官方网站：https://github.com/
提供给用户创建git仓储空间，保存（托管）用户的一些数据文档或者代码等。
Github目前拥有140多万开发者用户。随着越来越多的应用程序转移到了云上，Github已经成为了管理软件开发以及发现已有代码的首选方法。GitHub可以托管各种git库，并提供一个web界面，但与其它像SourceForge或Google Code这样的平台不同，GitHub的独特卖点在于从另外一个项目进行分支的简易性。为一个项目贡献代码非常简单：首先点击项目站点的“fork”的按钮，然后将代码检出并将修改加入到刚才分出的代码库中，最后通过内建的“pull request”机制向项目负责人申请代码合并。已经有人将GitHub称为代码玩家的MySpace。
Github公有仓库免费，私有仓库要收费的！
git和Github的关系
指定了remote链接和用户信息（git靠用户名+邮箱识别用户）之后，git可以帮你将提交过到你本地分支的代码push到远程的git仓库（任意提供了git托管服务的服务器上都可以，包括你自己建一个服务器 或者 GitHub/BitBucket等网站提供的服务器）或者将远程仓库的代码 fetch 到本地。
Github只是一个提供存储空间的服务器，用来存储git仓库。当然现在Github已经由一个存放git仓库的网站空间发展为了一个开源社区（不只具有存储git仓库的功能了），你可以参与别人的开源项目，也可以让别人参与你的开源项目。
Github类似产品
有很多Github类似的平台，用于提供git仓库的存储。
BitBucket
公有、私有仓库都免费。
git和CVS、SVN的区别
git是分布式版本控制系统，代码提交是在本地的（如此速度就快），当然生成补丁（patch）然后push到远程服务器上是需要联网的。
CVS、SVN是集中式版本控制系统，代码提交都是提交到远程服务器上，是需要一直联网的（如此速度就慢）（这里的一直联网不是说你写代码的时候要联网，而是说你提交代码的时候必须联网；但是git不同，git提交代码是本地的不需要联网，生成patch后push patch才需要联网，相当于svn的远程的集中服务器对于git来说，这个集中的远程服务器就在本地）。这个地方比较难理解。
CVS、SVN这样的集中式版本控制系统，它的完整代码仓库（代码仓库不仅仅只包含了代码，还包含各个历史版本的信息等）在中心服务器上，一旦这个中心服务器挂了，也就是完整的代码仓库挂了，虽然你本地可能之前有从中心服务器上取得过代码，但是那些历史版本信息都没有了，而且你也无法再提交代码。
git不同，git没有中心服务器的概念，每一个git客户端（git节点）都含有一个完整的代码仓库（前提是你之前从远程git仓库fetch过代码），所以那些历史版本信息都在你本机上，假如哪一个git节点挂掉了，随意从其他git节点clone一个代码仓库过来就ok了， 那些原来的代码、版本信息之类的都还是完整的（当然如果你在这个挂掉的git节点上新增的代码是没有掉了的）。
综上，git的每一个节点（第一次从远程git仓库取得代码后，该git节点就是一个完整的代码仓库）相当于SVN的中心服务器，都包含完整的代码仓库。
git的工作原理
架构图
功能特性
git的功能特性：
从一般开发者的角度来看，git有以下功能：
1、从远程服务器上克隆clone完整的git仓库（包括代码和版本信息）到自己的机器（单机）上。
2、在自己的机器上根据不同的开发目的，创建分支，修改代码。
3、在单机上自己创建的分支上提交代码。
4、在单机上合并分支。
5、把远程服务器上最新版的代码fetch下来，然后跟自己的主分支合并。
6、生成补丁（patch），把补丁发送给主开发者。
7、看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。
8、一般开发者之间解决冲突的方法，开发者之间可以使用pull命令解决冲突，解决完冲突之后再向主开发者提交补丁。
从主开发者的角度看，git有以下功能：
1、查看邮件或者通过其它方式查看一般开发者的提交状态。
2、打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有用，哪些不用）。
3、向远程服务器（公共的）提交结果，然后通知所有开发人员。
优点：
1、适合分布式开发，强调个体。
2、远程服务器（公共的）压力和数据量都不会太大。
3、速度快、灵活。
4、任意两个开发者之间可以很容易的解决冲突。
5、离线工作。（当然提交远程服务器或者从远程服务器fetch代码是要联网的）。
git中的一些概念和原理
工作区
Working Directory
电脑上能看到的目录即工作目录，比如：/e/git_repo/
版本库
Repository
工作区有一个隐藏目录.git，这个不算工作区，而是git的版本库。
git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。构造参见上面的结构图。
暂存区
Stage
暂存区就是版本库中的一个区域，具体参见上面的结构图。
工作区、版本库、暂存区之间的关系
git工作的流程就是：
第1步，使用git add把文件从工作区添加到版本库中的暂存区，git add命令可以多次用；
第2步，使用git commit提交代码，就是把暂存区的所有内容提交到当前分支。
综上，需要提交的文件修改通通放到暂存区（可能有多次的git add），然后，一次性提交暂存区的所有修改到当前分支（git commit）。
分支
分支（branch）有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
分支内部原理
1、如下图所示，版本的每一次提交（commit），git都将它们根据提交的时间点串联成一条线。刚开始是只有一条时间线，即master分支，HEAD指向的是当前分支的当前版本。
2、当创建了新分支，比如dev分支（通过命令git branch dev完成），git新建一个指针dev，dev=master，dev指向master指向的版本，然后切换到dev分支（通过命令git checkout dev完成），把HEAD指针指向dev，如下图。
3、在dev分支上编码开发时，都是在dev上进行指针移动，比如在dev分支上commit一次，dev指针往前移动一步，但是master指针没有变，如下：
4、当我们完成了dev分支上的工作，要进行分支合并，把dev分支的内容合并到master分支上（通过首先切换到master分支，git branch master，然后合并git merge dev命令完成）。其内部的原理，其实就是先把HEAD指针指向master，再把master指针指向现在的dev指针指向的内容。如下图。
5、当合并分支的时候出现冲突（confict），比如在dev分支上commit了一个文件file1，同时在master分支上也提交了该文件file1，修改的地方不同（比如都修改了同一个语句），那么合并的时候就有可能出现冲突，如下图所示。
这时候执行git merge dev命令，git会默认执行合并，但是要手动解决下冲突，然后在master上git add并且git commit，现在git分支的结构如下图。
可以使用如下命令查看分支合并情况。
- git log --graph --pretty=oneline --abbrev-commit
6、合并完成后，就可以删除掉dev分支（通过git branch -d dev命令完成���。
如此，就是分支开发的原理。其好处也是显而易见的。
分支策略
如何合适地使用分支？
在实际开发中，我们应该按照几个基本原则进行分支管理：
1、master分支应该是非常稳定的，也就是仅用来发布新版本，平时不要在master分支上编码开发。master分支应该与远程仓库保持同步；
2、平常编码开发都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；dev分支也应该与远程保持同步；（git push/git pull也要解决冲突）
3、你和团队成员每个人都在本地的dev分支上干活，每个人都有自己的分支，时不时地往远程dev分支上push/pull就可以了。（push/pull的时候是要解决冲突的.）
上面这个图是大致示意图，其实上面这个图是省略了git push/git pull操作的，比如bob在本地dev分支上，新建了一个feature1分支干完活，在本地的dev分支上合并了feature1分支，然后要把dev分支push到公共服务器上，这样michael才能pull下来bob完成的内容。更详细一点的图如下：
GitHub 教程系列文章：
GitHub 的详细介绍：请点这里
GitHub 的下载地址：请点这里
PS：git本没有公共服务器的概念，git的每个节点都是一个完整的git库，但是公共服务器是方便了git节点之间的代码互相push/pull（要不然每个git节点都需要互相连接，每增加一个git节点就要连接其他的git节点）。如下图所示：
有公共服务器的结构 无公共服务器的结构
有公共服务器的，增加tom节点时候，只需要tom和公共服务器相连接，tom就可以取得（pull）michael提交（push，此处不是commit，commit是本地提交，没有推送到公共服务器）的代码，也可以取得bob提交（push）的代码。
如果没有公共服务器，tom要想取得（pull）michael的代码，则必须在tom和michael之间建立一个网络连接； 要想取得（pull）bob的代码，必须在tom和bob之间建立一个网络连接。