Git快速入门

什么是版本控制工具？有哪些版本控制工具?

版本控制工具是项目开发中必不可少的，以此进行的版本控制可以确保在软件项目开发中，不同的开发人员所涉及的同一文档都得到更新。
项目源代码的版本管理工具中，比较常用的主要有：CVS、SVN、Git 和 Mercurial

Git的诞生

同生活中的许多伟大事件一样，Git 诞生于一个极富纷争大举创新的年代。1991年，Linus创建了开源的Linux，并且有着为数众多的参与者。虽然有世界各地的志愿者为Linux编写代码，但是绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。在这期间，所有的源代码都是由Linus手工合并。因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统（集中式和分布式我们会在接下来的内容讲解）不但速度慢，而且必须联网才能使用。虽然有一些商用的版本控制系统，比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。

不过，到了2002 年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是整个项目组启用了一个商业版本的分布式版本控制系统 BitKeeper 来管理和维护代码。BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。安定团结的大好局面在2005年被打破，开发BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，原因是Linux社区牛人聚集，开发Samba的Andrew试图破解BitKeeper的协议，这么干的其实也不只他一个，但是被BitMover公司发现了，于是BitMover公司收回了Linux社区的免费使用权。这就迫使Linux开源社区（ 特别是Linux的缔造者 Linus Torvalds ）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。

他们对新的系统制订了若干目标：速度 、 简单的设计 、 对非线性开发模式的强力支持（允许上千个并行开发的分支）、完全分布式、有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）。自诞生于 2005 年以来，Git 日臻成熟完善，迅速成为最流行的分布式版本控制系统，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，它还有着令人难以置信的非线性分支管理系统，可以应付各种复杂的项目开发需求。2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。

历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。

版本控制系统

Linus一直痛恨的CVS及SVN都是集中式的版本控制系统，而Git是分布式版本控制系统，集中式和分布式版本控制系统有什么区别呢？
集中式版本控制系统（CVS、SVN）
先说集中式版本控制系统，版本库是集中存放在中央服务器的，而大家工作的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始工作，工作完成，再把自己的修订推送给中央服务器。这类系统，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。
分布式版本控制系统（Git）
那分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

Git基本用法

1.git的初始化
在使用git进行代码管理之前，我们首先要对git进行初始化。

使用Git的第一件事就是设置你的名字和email,这些就是你在提交commit时的签名，每次提交记录里都会包含这些信息。使用git config命令进行配置：

$ git config --global user.name "Scott Chacon"
$ git config --global user.email "schacon@gmail.com"

执行了上面的命令后,会在家目录(/home/shiyanlou)下建立一个叫.gitconfig 的文件（该文件为隐藏文件，需要使用ls -al查看到）. 内容一般像下面这样，可以使用vim或cat查看文件内容:

$ cat ~/.gitconfig
[user]
        email = schacon@gmail.com
        name = Scott Chacon

上面的配置文件就是Git全局配置的文件，一般配置方法是git config --global <配置名称> <配置的值>。

如果你想使项目里的某个值与前面的全局设置有区别(例如把私人邮箱地址改为工作邮箱)，你可以在项目中使用git config 命令不带 --global 选项来设置. 这会在你当前的项目目录下创建 .git/config，从而使用针对当前项目的配置。
2.获得一个Git仓库
2.1Clone一个仓库

$ git clone 仓库地址

2.2 初始化一个新的仓库
可以对一个已存在的文件夹用下面的命令让它置于Git的版本控制管理之下。

$ mkdir project
$ cd project
$ git init

通过ls -la命令会发现project目录下会有一个名叫.git 的目录被创建，这意味着一个仓库被初始化了。可以进入到.git目录查看下有哪些内容。
3.正常的工作流程

1. git init //初始化仓库

2. git add .(文件name) //添加创建或修改文件到本地缓存区

3. git commit -m “first commit” //提交创建或修改文件到本地仓库

4. git remote add origin + 远程仓库地址 //链接远程仓库，创建主分支

5. git pull origin master // 把本地仓库的变化连接到远程仓库主分支

6. git push -u origin master //把本地仓库的文件推送到远程仓库

4.分支与合并
Git 的分支可以让你在主线（master分支）之外进行代码提交，同时又不会影响代码库主线。分支的作用体现在多人协作开发中，比如一个团队开发软件，你负责独立的一个功能需要一个月的时间来完成，你就可以创建一个分支，只把该功能的代码提交到这个分支，而其他同事仍然可以继续使用主线开发，你每天的提交不会对他们造成任何影响。当你完成功能后，测试通过再把你的功能分支合并到主线。

1. git branch experimental //创建分支
2. git branch //查看当前的分支列表以及当前的开发环境处在哪个分支上：
3. git checkout experimental //切换分支
4. git merge -m ‘merge exoerimental branch’ experimental
   //合并分支 -m参数是需要填写合并的注释信息。
5. git branch -d experimental //删除分支
6. git reset --hard HEAD^ //撤销一个合并

5.合并冲突问题
如果有冲突，比如两个分支都改了一个文件 file3，则合并时会失败。首先我们在master分支上修改file3文件并提交：

\# 切换到master分支
$ git checkout master
\# 修改file3文件
$ echo "master: update file3" >> file3
\# 提交到master分支
$ git commit -a -m 'update file3 on master'

然后切换到experimental，修改file3并提交：

\# 切换到experimental分支
$ git checkout experimental
\# 修改file3文件
$ echo "experimental: update file3" >> file3
\# 提交到experimental分支
$ git commit -a -m 'update file3 on experimental'

切换到master进行合并：

$ git checkout master
$ git merge experimental
Auto-merging file3
CONFLICT (content): Merge conflict in file3
Automatic merge failed; fix conflicts and then commit the result.

合并失败后先用git status查看状态，会发现file3显示为both modified，查看file3内容会发现：

$ cat file3
test
<<<<<<< HEAD
master: update file3
\=======
experimental: update file3
\>>>>>>> experimental

上面的内容也可以使用git diff查看，先前已经提到git diff不加参数可以显示未提交到缓存区中的修改内容。

可以看到冲突的内容都被添加到了file3中，我们使用vim编辑这个文件，去掉git自动产生标志冲突的<<<<<<等符号后，根据需要只保留我们需要的内容后保存，然后使用git add file3和git commit命令来提交合并后的file3内容，这个过程是手动解决冲突的流程。

\# 编辑冲突文件
$ vim file3
\# 提交修改后的文件
$ git add file3
$ git commit -m 'merge file3'