| 版本控制
版本控制是什么已不用在说了，就是记录我们对文件、目录或工程等的修改历史，方便查看更改历史，备份以便恢复以前的版本，多人协作。。。
一、原始版本控制
最原始的版本控制是纯手工的版本控制：修改文件，保存文件副本。有时候偷懒省事，保存副本时命名比较随意，时间长了就不知道哪个是新的，哪个是老的了，即使知道新旧，可能也不知道每个版本是什么内容，相对上一版作了什么修改了，当几个版本过去后，很可能就是下面的样子了：
二、本地版本控制
手工管理比较麻烦且混乱，所以出现了本地版本控制系统，记录文件每次的更新，可以对每个版本做一个快照，或是记录补丁文件。比如RCS。
三、集中版本控制
但是本地版本控制系统偏向于个人使用，或者多个使用的人必须要使用相同的设备，如果需要多人协作就不好办了，于是，集中化的版本控制系统（
Centralized Version Control Systems，简称 CVCS ）应运而生，比如Subversion，Perforce。
在CVCS中，所有的版本数据都保存在服务器上，一起工作的人从服务器上同步更新或上传自己的修改。
但是，所有的版本数据都存在服务器上，用户的本地设备就只有自己以前所同步的版本，如果不连网的话，用户就看不到历史版本，也无法切换版本验证问题，或在不同分支工作。。
而且，所有数据都保存在单一的服务器上，有很大的风险这个服务器会损坏，这样就会丢失所有的数据，当然可以定期备份。
四、分布式版本控制
针对CVCS的以上缺点，出现了分布式版本控制系统( Distributed Version Control
System,简称 DVCS )，如GIT，Mercurial。
DVCS不是复制指定版本的快照，而是把所有的版本信息仓库全部同步到本地，这样就可以在本地查看所有版本历史，可以离线在本地提交，只需在连网时push到相应的服务器或其他用户那里。由于每个用户那里保存的都是所有的版本数据，所以，只要有一个用户的设备没有问题就可以恢复所有的数据。
当然，这增加了本地存储空间的占用。
GIT
必须要了解GIT的原理，才能知道每个操作的意义是什么，才能更容易地理解在什么情况下用什么操作，而不是死记命令。当然，第一步是要获得一个GIT仓库。
一、获得GIT仓库
有两种获得GIT仓库的方法，一是在需要用GIT管理的项目的根目录执行：
执行后可以看到，仅仅在项目目录多出了一个.git目录，关于版本等的所有信息都在这个目录里面。
另一种方式是克隆远程目录，由于是将远程服务器上的仓库完全镜像一份至本地，而不是取某一个特定版本，所以用clone而不是checkout：
二、GIT中版本的保存
记录版本信息的方式主要有两种：
1.记录文件每个版本的快照
2.记录文件每个版本之间的差异
GIT采用第一种方式。像Subversion和Perforce等版本控制系统都是记录文件每个版本之间的差异，这就需要对比文件两版本之间的具体差异，但是GIT不关心文件两个版本之间的具体差别，而是关心文件的整体是否有改变，若文件被改变，在添加提交时就生成文件新版本的快照，而判断文件整体是否改变的方法就是用SHA-1算法计算文件的校验和。
GIT能正常工作完全信赖于这种SHA-1校验和，当一个文件的某一个版本被记录之后会生成这个版本的一个快照，但是一样要能引用到这个快照，GIT中对快照的引用，对每个版本的记录标识全是通过SHA-1校验和来实现的。
当一个文件被改变时，它的校验和一定会被改变（理论上存在两个文件校验和相同，但机率小到可以忽略不计），GIT就以此判断文件是否被修改，及以些记录不同版本。
在工作目录的文件可以处于不同的状态，比如说新添加了一个文件，GIT发觉了这个文件，但这个文件是否要纳入GIT的版本控制还是要由我们自己决定，比如编译生成的中间文件，我们肯定不想纳入版本控制。下面就来看下文件状态。
三、GIT文件操作
版本控制就是对文件的版本控制，对于Linux来说，设备，目录等全是文件，要对文件进行修改、提交等操作，首先要知道文件当前在什么状态，不然可能会提交了现在还不想提交的文件，或者要提交的文件没提交上。
文件状态
GIT仓库所在的目录称为工作目录，这个很好理解，我们的工程就在这里，工作时也是在这里做修改。
在工作目录中的文件被分为两种状态，一种是已跟踪状态(tracked)，另一种是未跟踪状态(untracked)。只有处于已跟踪状态的文件才被纳入GIT的版本控制。如下图：
当我们往工作目录添加一个文件的时候，这个文件默认是未跟踪状态的，我们肯定不希望编译生成的一大堆临时文件默认被跟踪还要我们每次手动将这些文件清除出去。用以下命令可以跟踪文件：
git add <file>
上图中右边3个状态都是已跟踪状态，其中的灰色箭头只表示untracked<-->tracked的转换而不是untracked<-->unmodified的转换，新添加的文件肯定算是被修改过的。那么，staged状态又是什么呢？这就要搞清楚GIT的三个工作区域：本地数据（仓库）目录，工作目录，暂存区，如下图所示：
git directory就是我们的本地仓库.git目录，里面保存了所有的版本信息等内容。
working driectory，工作目录，就是我们的工作目录，其中包括未跟踪文件及已跟踪文件，而已跟踪文件都是从git
directory取出来的文件的某一个版本或新跟踪的文件。
staging area，暂存区，不对应一个具体目录，其时只是git directory中的一个特殊文件。
当我们修改了一些文件后，要将其放入暂存区然后才能提交，每次提交时其实都是提交暂存区的文件到git仓库，然后清除暂存区。而checkout某一版本时，这一版本的文件就从git仓库取出来放到了我们的工作目录。
文件状态的查看
那么，我们怎么知道当前工作目录的状态呢？哪些文件已被暂存？有哪些未跟踪的文件？哪些文件被修改了？所有这些只需要一个命令，git
status，如下图所示:
GIT在这一点做得很好，在输出每个文件状态的同时还说明了怎么操作，像上图就有怎么暂存、怎么跟踪文件、怎么取消暂存的说明。
文件暂存
在上图中我们可以很清楚地看到，filea未跟踪，fileb已被暂存（changes to be committed），但是怎么还有一个fileb是modified但unstaged呢？这是因为当我们暂存一从此文件时，暂存的是那一文件当时的版本，当暂存后再次修改了这个文件后就会提示这个文件暂存后的修改是未被暂存的。
接下来我们就看怎么暂存文件，其实也很简单，从上图中可以看到GIT已经提示我们了：use "git
add <file>..." to update what will be committed，通过
git add <file>...
就可以暂存文件，跟踪文件同样是这一个命令。在这个命令中可以使用glob模式匹配，比如"file[ab]"，也可以使用"git
add ."添加当前目录下的所有文件。
取消暂存文件是
git reset HEAD <file>...
若修改了一个文件想还原修改可用
git checkout -- <file>...
查看文件修改后的差异
当我们修改过一些文件之后，我们可能想查看我们都修改了什么东西，用"git status"只能查看对哪些文件做了改动，如果要看改动了什么，可以用：
git diff
比如下图：
---a表示修改之前的文件，+++b表示修改后的文件，上图表示在fileb的第一行后添加了一行"bb"，原来文件的第一行扩展为了修改后的1、2行。
但是，前面我们明明用"git status"看到filesb做了一些修改后暂存了，然后又修改了fileb，理应有两次修改的，怎么只有一个？
因为"git diff"显示的是文件修改后还没有暂存起来的内容，那如果要比较暂存区的文件与之前已经提交过的文件呢，毕竟实际提交的是暂存区的内容，可以用以下命令：
/dev/null表示之前没有提交过这一个文件，这是将是第一次提交，用：
git diff --staged
是等效的，但GIT的版本要大于1.6.1。
再次执行"git add"将覆盖暂存区的内容。
忽略一些文件
如果有一些部件我们不想纳入版本控制，也不想在每次"git status"时看到这些文件的提示，或者很多时候我们为了方便会使用"git
add ."添加所有修改的文件，这时就会添加上一些我们不想添加的文件，怎么忽略这些文件呢？
GIT当然提供了方法，只需在主目录下建立".gitignore"文件，此文件有如下规则：
所有以#开头的行会被忽略 可以使用glob模式匹配 匹配模式后跟反斜杠（/）表示要忽略的是目录 如果不要忽略某模式的文件在模式前加"!" 比如：
# 此为注释 – 将被 Git 忽略 *.a # 忽略所有 .a 结尾的文件 !lib.a # 但 lib.a 除外 /TODO # 仅仅忽略项目根目录下的 TODO 文件,不包括 subdir/TODO build/ # 忽略 build/ 目录下的所有文件 doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
移除文件
当我们要删除一个文件时，我们可能就直接用GUI删除或者直接rm [file]了，但是看图：
我们需要将文件添加到暂存区才能提交，而移除文件后是无法添加到暂存区的，那么怎么移除一个文件让GIT不再将其纳入版本控制呢？上图中GIT已经给出了说明：
git rm <file>...
执行以上命令后提交就可以了，有时我们只是想将一些文件从版本控制中剔除出去，但仍保留这些文件在工作目录中，比如我们一不小心将编译生成的中间文件纳入了版本控制，想将其从版本控制中剔除出去但在工作目录中保留这些文件（不然再次编译可要花费更多时间了），这时只需要添加"--cached"参数。
如果我们之前不是通过"git rm"删除了很多文件呢？比如说通过patch或者通过GUI，如果这些文件命名没有规则，一个一个地执行"git
rm"会搞死人的，这时可以用以下命令：
移动文件
和移除文件一样，移动文件不可以通过GUI直接重命令或用"mv"命令，而是要用"git
mv"，不然同移除文件一样你会得到如下结果：
如果要重命名文件可以使用
git mv old_name new_name
这个命令等效于
mv old_name new_name
git rm old_name
git add new_name
交互式暂存
使用git add -i可以开启交互式暂存，如图所示，系统会列出一个功能菜单让选择将要执行的操作。
移除所有未跟踪文件
git clean [options] 一般会加上参数-df，-d表示包含目录，-f表示强制清除。
储藏-Stashing
可能会遇到这样的情况，你正在一个分支上进行一个特性的开发，或者一个Bug的修正，但是这时突然有其他的事情急需处理，这时该怎么办？不可能就在这个工作进行到一半的分支上一起处理，先把修改的Copy出去？太麻烦了。这种情况下就要用到Stashing了。假如我们现在的工作目录是这样子的
$ git status
# On branch master
# Changes to be committed:
#
(use "git reset HEAD <file>..." to unstage)
#
#
modified:
index.html
#
# Changed but not updated:
#
(use "git add <file>..." to update what will be committed)
#
#
modified:
lib/simplegit.rb |
此时如果想切换分支就可以执行以下命令
$ git stash
Saved working directory and index state \
"WIP on master: 049d078 added the index file"
HEAD is now at 049d078 added the index file
(To restore them type "git stash apply") |
这时你会发现你的工作目录变得很干净了，就可以随意切分支进行其他事情的处理了。
我们可能不只一次进行"git stash"，通过以下命令可以查看所有stash列表
$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051... Revert "added file_size" |
当紧急事情处理完了，需要重新回来这里进行原来的工作时，只需把Stash区域的内容取出来应用到当前工作目录就行，命令就是
如果不基参数就应用最新的stash，或者可以指定stash的名字，如：stash@{1}，可能通过
显示stash的内容具体是什么，同git stash apply一样，可以选择指定stash的名字。
git stash apply之后再git stash list会发现，apply后的stash还在stash列表中，如果要将其从stash列表中删除可以用
丢弃这个stash，stash的命令参数都可选择指定stash名字，否则就是最新的stash。
一般情况下apply stash后应该就可以把它从stash列表删除了，先apply再drop还是比较繁琐的，使用以下一条命令就可以同时完成这两个操作
如果我们执行git stash时工作目录的状态是部分文件已经加入了暂存区，部分文件没有，当我们执行git
stash apply之后会发现所有文件都变成了未暂存的，如果想维持原来的样子操持原来暂存的文件仍然是暂存状态，可以加上--index参数
还有这么一种情况，我们把原来的修改stash了，然后修复了其他一些东西并进行了提交，但是，这些提交的文件有些在之前已经被stash了，那么git
stash apply时就很可能会遇到冲突，这种情况下就可以在stash时所以提交的基础上新建一个分支，然后再apply
stash，当然，这两个步骤有一人简单的完成方法
git stash branch <branch name> |
|
