git简介
产生历史
2005年，Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是git。
git的两个特点
- 版本控制：可以解决多人同时开发的代码问题，也可以解决找回历史代码的问题。
- 分布式：Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。首先找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。可以自己搭建这台服务器，也可以使用GitHub网站。
安装与配置
安装命令如下：
sudo apt-get intsall git安装成功后，需要设置你的用户名称与邮件地址：
$ git config --global user.name "Your Name" $ git config --global user.email "[email protected]"
创建一个版本库
新建一个目录 git_test，在 git_test 下新建一个版本库，命令如下：
$ mkdir git_test $ cd git_test $ git init可以看到在 git_test目录下创建了一个.git 隐藏目录，这就是版本库目录。
版本创建与回退
使用
（1）在 git_test 目录下创建一个文件 code.txt，编辑内容如下：
$ touch code.txt
$ vim code.txtcode.txt 里内容为:
this is the first line（2）使用如下两条命令可以创建一个版本：
$ git add code.txt
$ git commit -m 'version1'（3）使用如下命令可以查看版本信息：
$ git log（4）继续编辑 code.txt，在里面增加一行，此时 code.txt 里的内容为：
this is the first line
this is the second line（5）使用如下命令再创建一个版本并查看版本记录：
$ git add code.txt
$ git commit -m 'version2'
$ git log（6）现在如果想回到之前的某一个版本，可以使用如下命令：
$ git reset --hard HEAD^其中 HEAD 表示当前最新版本，HEAD^ 表示当前版本的前一个版本，HEAD^^ 表示当前版本的前个版本，也可以使用 HEAD~1 表示当前版本的前一个版本，HEAD~100 表示当前版本的前100版本。
假如现在想回到 version1，执行命令后使用git log查看版本记录，发现现在只能看到 version1 的记录，cat code.txt查看文件内容，现在只有一行，也就是第一个版本中 code.txt 的内容。
（7）假如我们现在又想回到 version2，可以使用如下命令：
$ git reset --hard 版本号我们需要在之前查询的有关信息上找到 version2 的版本号。
（8）在终端执行如下命令：
$ git log发现 version2 又回来了，可以去cat code.txt 查看里面的内容。
（9） 假如说上面的终端已经关了，该怎么回退版本？
我们在执行$ git reset --hard HEAD^命令将版本回退到版本1。下面把终端关了，然后再打开终端，发现之前 version2 的版本号看不到了。
那么怎么再回到 version2 呢？git reflog命令可以查看我们的操作记录。
git reflog $ git reflog
通过这个可以看到 version2 的版本号，我们再使用版本回退语句就可以让版本重回 version2 了。
工作区和暂存区
工作区(Working Directory)
电脑中的目录，比如我们的 git_test，就是一个工作区。
版本库(Repository)
工作区有一个隐藏目录 .git，这个不是工作区，而是 git 的版本库。
git 的版本库里存了很多东西，其中最重要的就是称为 stage (或者叫 index )的暂存区，还有 git 为我们自动创建的第一个分支 master，以及指向 master 的一个指针叫 HEAD。
因为我们创建 git 版本库时，git自动为我们创建了唯一一个 master 分支，所以现在，git commit就是往 master 分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
前面讲了我们把文件往git版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
（1）下面在 git_text 目录下再创建一个文件 code2.txt，编辑内容如下：
$ touch code2.txt
$ vim code2.txtcode2.txt 里内容为:
the code2 first line（2）然后编辑 code.txt 内容，在其中加入一行，编辑后内容如下：
this is the first line
this is the second line
this is the three line（3）使用如下命令查看工作树的状态：
$ git status会提示我们 code.txt 被修改，而 code2.txt 没有被跟踪。
（4）我们使用如下命令把 code.txt 和 code2.txt 加入到暂存区，然后再执行git status命令，会提示我们 code.txt 被修改，code2.txt 是一个新文件。所有的git add命令是把所有的提交的修改存放到暂存区。
（5）然后执行git commit就可以一次性把暂存区的所有修改提交到分支创建一个版本。
$ git commit -m 'version3'（6）一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的。执行git status命令会提示没有文件需要提交，工作区是干净的。
现在我们的版本库变成了这样：
管理修改
git 管理的文件的修改，它只会提交暂存区的修改来创建版本。
（1）编辑 code.txt，并使用git add命令将其添加到暂存区。
（2）继续编辑 code.txt，并在其中添加一行。
（3）git commit创建一个版本，并使用git status查看，发现第二次修改的 code.txt 内容，并没有将其添加到暂存区，所以创建版本的时候并没有提交。
撤销修改
（1）我们不小心修改了 code.txt，该怎么撤销呢？我们可以使用git checkout -- file来丢弃工作区的改动。
$ git checkout -- code.txt（2）我们修改了 code.txt，并将其添加到缓存区了，该怎么撤销呢？可以使用git reset HEAD file把缓存区的修改撤销，重新放回工作区。
$ git reset HEAD code.txt（3）如果你不但改错了东西，还从暂存区提交到了版本库，则需要进行版本回退。
小结：
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考上面的版本回退 。
对比文件的不同
对比工作区和某个版本中文件的不同：
$ git diff HAD -- code.txt对比两个版本间文件的不同：
$ git diff HEAD HEAD^ -- code.txt删除文件
（1）我们把目录中的 code2.txt 删除。
$ rm code2.txt这个时候，git 知道删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻提示哪些文件被删除了。
（2） 现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git add和git commit创建版本。另一种情况是删错了，可以直接使用git checkout -- code2.txt，这样文件 code2.txt 又回来了。
小结：
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
分支管理
概念
分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。
如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了 git 又学会了 SVN！
分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
git 把我们之前每次提交的版本串成一条时间线，这条时间线就是一个分支。截止到目前只有一条时间线，在git里，这个分支叫主分支，即 master 分支。HEAD 严格来说不是指向提交，而是指向 master，master 才是指向提交的，所以，HEAD 指向的就是当前分支。
创建与合并分支
（1）一开始的时候，master 分支是一条线，git 用 master 指向最新的提交，再用 HEAD 指向 master，就能确定当前分支，以及当前分支的提交点。
每次提交，master 分支都会向前移动一步，这样，随着你不断提交，master 分支的线也越来越长。
（2）当我们创建新的分支，例如 dev 时，git 新建了一个指针叫 dev，指向 master 相同的提交，再把 HEAD 指向dev，就表示当前分支在dev上。
git 创建一个分支很快，因为除了增加一个 dev 指针，改变 HEAD 的指向，工作区的文件都没有任何变化。
（3）不过，从现在开始，对工作区的修改和提交就是针对 dev 分支了，比如新提交一次后，dev 指针往前移动一步，而 master 指针不变。
（4）假如我们在 dev 上的工作完成了，就可以把 de v合并到 master 上。gi t怎么合并呢？最简单的方法，就是直接把 master 指向 dev 的当前提交，就完成了合并。
git 合并分支也很快，就改改指针，工作区内容也不变。
（5）合并完分支后，甚至可以删除 dev 分支。删除 dev 分支就是把 dev 指针给删掉，删掉后，我们就剩下了一条 master 分支。
案例：
（1）执行如下命令可以查看当前有几个分支并且可以看到现在在哪个分支下工作。
$ git branch（2）下面创建一个分支 dev 并切换到其上进行工作。
$ git checkout -b dev
（3）下面我们修改 code.txt 内容，在里面增加一行，并进行提交，创建版本。
（4）dev 分支的工作完成，我们就可以切换回 master 分支。
$ git checkout master
查看 code.txt，发现添加的内容没有了。因为那个提交是在 dev 分支上，而 master 分支此刻的提交点并没有变。
（5）现在，我们把dev分支的工作成果合并到master分支上。
$ git merge devgit merge命令用于合并指定分支到当前分支。合并后，再查看 code.txt 的内容，就可以看到，和 dev 分支的最新提交是完全一样的。
注意到上面的 Fast-forward 信息，Git 告诉我们，这次合并是“快进模式”，也就是直接把 master 指向 dev 的当前提交，所以合并速度非常快。
（6）合并完成后，就可以放心地删除 dev 分支了，删除后，查看 branch，就只剩下 master 分支了。
小结：
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>
解决冲突
合并分支往往也不是一帆风顺。
（1）再创建并切换到 dev。
$ git checkout -b dev（2）修改 code.txt 内容，并进行提交。
（3）切换回 master 分支。
$ git checkout master（4）在 master 的 code.txt 添加一行内容并进行提交。现在，master分支和dev分支各自都分别有新的提交，变成了这样：
这种情况下，git 无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。
（5）执行如下命令尝试将 dev 分支合并到 master 分支上来。git告诉我们，code.txt 文件存在冲突，必须手动解决冲突后再提交。
（6）git status也可以告诉我们冲突的文件。
（7）查看 code.txt 的内容。
（8）git 用 <<<<<<<，=======，>>>>>>> 标记出不同分支的内容，我们修改后保存。
（9）再提交，现在 master 分支和 dev 分支变成了下图所示：
（10）用带参数的git log也可以看到分支的合并情况：
$ git log --graph --pretty=oneline
（11）最后工作完成，可以删除 dev 分支。