1. Git系列之底层原理篇
本章节是Git的核心知识点，主要是介绍Git底层原理与在使用Git过程中的几个重要区域，弄懂Git的整个使用流程，以及数据的存储过程。
工作区（Working Directory）:
工作区就是我们平时编写文本文件的地方
暂存区（Stage/Index）:
暂存区是我们提交文本文件到本地仓库的来源地，只有把工作区的文件添加至暂存区，才可以被提交至本地仓库。
本地仓库（Repository）：
本地仓库是保存每次文件更新的记录，包括提交人，提交时间，提交的内容等详细信息，方便追溯历史版本。
远程仓库（Remote Repository）：
远程仓库算是本地仓库的一个副本，主要是方便合作伙伴之间的仓库文件同步。
因此它的使用流程可以简单的概括为：
1、在本地搭建一个目录，用来创建git仓库
$ git init gitDirectory
2、在仓库目录下创建文本文件（工作区）
$ cd gitDirectory
$ echo "first txt" > first.txt
3、把工作区的first.txt文件添加至git暂存区
$ git add first.txt
4、将暂存区中的文件first.txt提交至本地仓库
$ git commit -m "first commit"
5、将文件保存至本地仓库就已经可以记录我们每次提交的历史信息了，但是为了方便其他伙伴一起协作，还需要搭建一个远程服务。（本次以GitHub为例）
在GitHub创建一个和本地一样名称的仓库，创建成功后会生成一个仓库地址：
https://github.com/mr-kings/gitDirectory.git
6、将本地仓库和远程仓库关联起来
$ git remote add origin https://github.com/mr-kings/gitDirectory.git
7、第一次将本地仓库提交至远程仓库
$ git push -u origin master
第一次需要添加 -u 参数，即把本地的master分支和远程仓库的master分支对应上
8、此时本地仓库和远程仓库就已经实现了同步，其他协作伙伴只需到远程仓库把仓库克隆到自己的电脑即可进行协作编辑
$ git clone https://github.com/mr-kings/gitDirectory.git
9、克隆下来以后会在本地生成本地仓库以及工作区，后续的操作和2步骤及以后步骤一致
需要注意的是：远程仓库有两种连接方式https/ssh，上面的例子使用的https，其实ssh方式会比https快的多，它还可以通过添加密钥的方式省去每次提交时都要输入用户名和密码的问题，这里不做详细介绍。https也是可以通过配置省去每次推送都需要输入用户名和密码的问题。
Git安装成功后，在本地新建一个Git仓库，$ git init Gitstudy会生成一个.git文件夹，如果你创建的时候没有发现.git目录那应该是你的电脑默认隐藏了.git文件夹，有两种方式可以查看它：
第一种方式：
命令行工具，在当前目录下，在命令行里输入 $ ll -a 即可查看
第二种方式：
在当前目录下，点击查看菜单，然后勾选上隐藏的项目即可
.git目录就是暂存区和本地仓库的位置，所以它的核心就在这里，下面看看它有哪些内容：
由上图可知，初始化的时候.git目录下有以下文件及文件夹：
config(文件)：存放当前仓库的一些配置信息，比如记住用户名和密码，别名等
下面是它的常用选项：
[core] ignorecase 是否忽略文件大小写
[remote "origin"] url 配置远程仓库地址
[remote "origin"] fetch 远程分支映射关系
[user] name 用户名
[user] email 邮箱
[alias] 命令别名配置 ： cmt = commit
description(文件)：创建仓库的描述文件
HEAD(文件)：指示当前被检出(所在)的分支，如当前在test分支，文件内容则为ref: refs/heads/test。
hooks/(文件夹)：包含客户端或服务端的钩子脚本(hook scripts)，如pre-commit，post-receive等
info/ (文件夹)：用以存储一些有关git仓库的信息，如exclude
objects/ (文件夹)：用以存储git仓库中的所有数据内容
refs/(文件夹)：包含 heads 文件夹，remote文件夹。heads 记录本地相关的各 git分支操作记录，remote 记录远程仓库相关的各git分支 操作记录
当第一次提交的时候还会生成以下文件及文件夹：
index (文件) -- （在git add file的时候生成）：是当前版本的文件索引，包含生成当前树(唯一确定的)对象的所虚信息，可用于快速比对工作树和其他提交树对象的差异(各commit和HEAD之间的diff)，可用于存储单文件的多个版本以有效的解决合并冲突。可使用git ls-files 查看index文件内容
COMMIT_EDITMSG(文件) -- （在git commit -m "first commit"的时候生成）：最近一次的 commit edit message
logs/ (文件夹) -- （在git commit -m "first commit"的时候生成）：放置git仓库操作记录的文件夹，包含HEAD文件 和 refs文件夹
以上简单介绍了.git目录下的文件及文件夹，重点则是objects文件夹：
经过第一次提交后objects文件夹下多出了3个文件夹：44/、d0/、f6/。通过提交的日志我们发现，commit后会生成一个40位的16进制字符串（前两位作为文件夹名称，后38位为内容哈希值）
官方描述：这是一个 SHA-1 哈希值——一个将待存储的数据外加一个头部信息(header)一起做 SHA-1 校验运算而得的校验和（前2位作为文件夹名称 -- 后面38位作为内容的哈希值）
通过cat-file -t sha-1 命令查看当前哈希值所属的类型：
由图可知它是一个commit对象
再通过命令cat-file -p sha-1查看该commit对象包含有哪些信息
由图知一个commit对象包含了tree对象，本地仓库信息，提交人信息及提交时的备注信息。
再通过上述命令查看tree对象又包含又哪些信息：
由图知tree对象又包含了blob对象，在多目录的情况下tree对象还会包含其他tree对象。
由此得出结论：刚才提交的时候生成的那个3个文件夹分别对应的是3个对象即：44/文件夹对应的是commit对象，f6/文件夹对应的是tree对象，d0/文件夹对应的是blob对象。层级关系是：commit对象对应一个tree对象，tree对象可以包含一个或多个其他tree对象和blob对象。
下面就简单介绍git中的几个对象：
blob：
blob对象只跟文本文件的内容有关，和文本文件的名称及目录无关，只要是相同的文本文件，会指向同一个blob。
tree:
tree对象记录文本文件内容和名称、目录等信息，每次提交都会生成一个顶层tree对象，它可以指向其引用的tree或blob。
commit:
commit对象记录本次提交的所有信息，包括提交人、提交时间，本次提交包含的tree及blob。
tag:
标签引用，它指向某一个commit。
用下面的图可以把今天的内容概括起来：上半部分描述了git的操作流程图，下半部分描述git底层数据存储结构图
Git流程及底层结构图
下面就对图的下半部分做个详细说明：
1、在与.git同级目录下新建文件夹directory，再在directory目录下新建一个文本文件first.txt，里面的内容为1。当执行$ git add first.txt 的时候就会在.git/objects/生成一个blob对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的第一个d00491 -- blob对象。
2、当执行$ git commit -m "first commit" 的时候就会在.git/objects/下新生成了2个tree对象和一个commit对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的f6589b -- tree对象,4a2e3e -- tree对象,6b18a7 -- commit对象。之所以生成两个tree对象是因为directory目录为一个tree对象还有与commit对象一一对应的顶层tree对象。这个时候HEAD游标指向的是当前master分支的first commit。并且在这次提交的时候打个v1.0版本的标签。
3、在与.git同级目录下新建一个新的文本文件second.txt，内容为2。当执行$ git add second.txt 的时候就会在.git/objects/生成一个新的blob对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的0cfbf0 -- blob对象。
4、当执行$ git commit -m "second commit" 的时候就会在.git/objects/下新生成了1个tree对象和一个commit对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的35e40c -- tree对象,d6dca9 -- commit对象。只生成一个与commit对象一一对应的顶层tree对象。由于本次提交directory目录下的first.txt内容没有变化，所以上图的35e40c -- tree对象还会指向f6589b -- tree对象。这个时候HEAD游标指向的是当前master分支的second commit(HEAD索引向前移动)，second commit 会指向上一次的提交即 parent指向first commit。
后续的操作以此类推，但需要注意的点是：
1、blob对象只对文件的内容有关，和文件名称无关，如果不同的文件名称，内容相同只会有一个blob对象，生成的新tree对象会指向该blob对象。例如上图的third.txt和four.txt里面的内容都为3。所以不会生成新的blob对象，新的tree对象只会指向同一个blob。
2、如果每次提交的时候包含的某些文件并没有改动（更新），那么就会直接指向它原来的索引，不会重新生成。例如上图的directory/first.txt，second.txt
3、每次commit对象都会和顶层的tree对象一一对应。
2. git清除历史纪录
若我想删除历史记录里比较考前的提交，而后面还有很多需要保留的提交，则：
1.2 如果要删除的历史记录是分散的，则可以考虑 Interactive Rebase，自行挑拣／合并等。如git rebase -i <ref>
1.1 如果要删除的历史记录是连续的，比如说从最开始到某一刻全部都删除或者是中间一截可以删除，则可以考虑 Onto Rebase，如 git rebase --onto <ONTO_BASE_ref> <START_ref> <END_ref>，其中 START 到 END 之间的是需要保留的部分，而 ONTO_BASE 则是最新的基点；换言之，从 ONTO_BASE 到 START 之间的历史记录会被干掉。
若我要删除的历史记录很多，要保留的则很少（比如说就保留最近的一个，以前都不想要了），那索性可以直接创建 Orphan Branch 来重建历史记录。如 git checkout --orphan new_start，这条命令会创建一个叫做 new_start 的分支，该分支没有任何历史记录，但是所有的文件都会原封不动的存在，你可以据此开始重新提交。完成之后甚至可以把旧的分支直接废弃。另外，也可以指定新分支的起点，默认当然是从 HEAD 开始了。
你还可以把历史记录分成两份（或更多份），其中有的完整，有的则简化等等，具体参见这篇关于 git replace 的文档：http://git-scm.com/2010/03/17/replace.html
其实还有很多种场景可以说道，Git 的用法非常灵活，即使暂时用不到也值得细细过一遍知道它能做什么样的事情，然后遇到各种复杂的场景就可以自己推导出解决方案了。
3. 一个Git仓库管理多个Git项目
平时我会把所有需要储存的资料都用git进行管理.
我需要使用一个命令, 把工作中所有git仓库都提交到自己的阿里云或Dropbox上, 在不同的地方使用它.
使用git配合Dropbox的另外一个好处是, 由于 .gitignore 忽略了许多公共资源, Dropbox只需要储存很少的内容:
如图, 我的所有项目文件有8.75GB, 但是Dropbox上只保存着430MB的仓库, 并且还拥有Git的版本管理功能.
如果你有和我一样的需求, 这篇文章会帮到你.
首先得确保当前有 Nodejs 环境, 安装 merge-sub-gits
思路很简单:
其中添加 -l 参数会打印重命名日志
每次都需要使用 merge-sub-gits 命令包括 git 提交操作很是繁琐, 我们可以在 ~/.bash_profile 文件中添加以下内容:
我们平时会有需要把工作文件放入各类网盘中, 方便在公司和家里进行同步, 但是Dropbox\iCloud等网盘都没有给予文件夹忽略和更细腻的Git的文件历史.
例如一个React前端项目大概有几百MB, 如果忽略 node_moles 文件夹就只剩下十几MB.
我们可以把所有工作和电脑环境相关的资料都放入一个work文件, 使用 merge-sub-gits 把改文件夹的内容同步到网盘中:
我们已经在Dropbox中创建了一个仓库, 并且clone到了本地, 接下来我们拷贝所有需要备份的文件都放入 ~/backup-all 文件夹中, 然后继续下面的操作:
如前文所述, 通过.gitignore文件和git的压缩, 把8.75GB的内容, 变为430MB进行网盘管理, 并且还有Git的版本管理功能.
由于Git仓库中保存了许多历史信息, 随着长时间的使用, Git 仓库会缓慢的逐步增大, 由于我们所有子项目都保留着自己的Git历史, 所以如果有一天根Git仓库太冗余了, 我们只需要删除Dropbox的Git,重新提交即可.
如果曾经在根git项目中使用过 git commit , 会把子git项目标记为忽略提交
这种情况需要清空git记录:
欢迎 Star: github.com/ymzuiku/merge-sub-gits
4. Git比SVN相比有什么区别
区别1、GIT是分布式的，SVN不是
这是GIT和其它非分布式的版本控制系统，最核心的区别；GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chectout代码后会在自己的机器上克隆一个自己的版本库。
区别2、Git直接记录快照，而非差异比较
Git和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。Git 并不保存这些前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照 的索引。为提高性能，若文件没有变化，Git不会再次保存，而只对上次保存的快照作一链接。
区别3、近乎所有操作都是本地执行
在 Git 中的绝大多数操作都只需要访问本地文件和资源，不用连网。但如果用 CVCS 的话，差不多所有操作都需要连接网络。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快。
5. Git 清除所有历史记录
有些时候，git 仓库累积了太多无用的历史更改，导致 clone 文件过大。如果确定历史更改没有意义，可以采用下述方法清空历史，
‘完’
6. git回滚历史版本后面版本的数据还在吗
git回滚历史版本后面版本的数据还在
下面详细介绍这些函数。
1. csvread、csvwrite
csvread函数的调用格式如下：
● M = csvread('filename')，将文件filename中的数据读入，并且保存为M，filename中只能包含数字，并且数字之间以逗号分隔。M是一个数组，行数与filename的行数相同，列数为filename列的最大值，对于元素不足的行，以0补充。
● M = csvread('filename', row, col)，读取文件filename中的数据，起始行为row，起始列为col，需要注意的是，此时的行列从0开始。
● M = csvread('filename', row, col, range)，读取文件filename 中的数据，起始行为 row，起始列为col，读取的数据由数组 range 指定，range 的格式为：[R1 C1 R2 C2]，其中R1、C1为读取区域左上角的行和列，R2、C2为读取区域右下角的行和列。
csvwrite 函数的调用格式如下：
● csvwrite('filename',M)，将数组M中的数据保存为文件filename，数据间以逗号分隔。
● csvwrite('filename',M,row,col)，将数组M中的指定数据保存在文件中，数据由参数 row和col指定，保存row和col右下角的数据。
● csvwrite写入数据时每一行以换行符结束。另外，该函数不返回任何值。
7. Git修改提交历史
Git的一个优势在于，当你在和别人共享你的工作之前，可以随便修改你的提交历史，当然不管在什么时候，最好不要改动已经推送到central server的commit，否则会产生一次变更的两个版本。
在推送到central server之前，你可以选取staging area（暂存区）中的任意文件进行提交，也可以通过stash命令决定不与某些内容工作，也可以偷梁换柱地重写已经发生的commits，这包括：改变commit信息，拆分commit，压缩多条commit，改变提交的顺序，甚至移除某些不再需要的commit等。
为了对于上面的描述有宏观的了解，笔者在本地新建了一个仓库且提交了三个commit，it seems like this：
其中SecondCommit中包含两个txt文件，其余两个commit都只包含一个txt文件。
接下来就来篡改一下历史吧！
（注：--pretty=format 表示格式化输出，%h 表示提交对象的简短哈希字串，%s 表示提交说明，为了方便后面的展示，笔者用alias命令简化上面的命令： git config --global alias.last "log --pretty=format:"%h,%s"",之后如果需要查看log信息，git last 或者 git last -n 即可）
修改最后一条commit是所有修改提交历史操作中最常见的一个。它的命令很简单： git commit --amend
从英文单词amend的字面意思（修改，改正）就可以理解此命令。
执行此命令会进入一个编辑框：
了解vim的同学可能对这不会感觉到陌生，这里简单介绍一下，首先在键盘输入i（i 表示insert插入，由此进入编辑模式），更改title信息，按Esc退出编辑模式，最后输入 :wq (保存并且退出)，收工。
如果对索引区的内容作了修改，先执行git add 命令，再执行git commit --amend , 效果是一样的，更改后的log信息如下：
Git提供了交互式变基工具，可以在任何想要修改的commit后停止，做任何想做的事。
通过git rebase -i 命令来交互式的运行变基（注：-i 是--interactive的缩写）。同时需要指定想要重写多久远的历史，比如修改最近三次提交：git rebase -i HEAD~3 ，因为笔者的FirstCommit是repository里面的第一个提交，所以笔者采用的是git rebase -i --root命令，有兴趣的同学可以看看这个： http://stackoverflow.com/questions/2246208/change-first-commit-of-project-with-git/2309391#2309391.
执行git rebase -i --root命令，弹出如下编辑框：
需要注意的是commit显示顺序刚好和git log的显示顺序相反。尤其注意Commands，之后所有的操作都是基于这些命令, 这里笔者依次解释一下：
p , pick = use commit: 直接使用commit 不做任何修改，其中p 是pick的缩写，以下雷同；
r , reword = use commit, but edit the commit message: 使用commit，但是会更改commit 信息；
e , edit = use commit, but stop for amending :使用commit，但是遇到此命令时会停止合并；
s , squash = use commit, but meld into previous commit: 使用commit,但是会合并到前一个commit中；
f , fixup = like "squash", but discard this commit's log message：和squash类似，但是会抛弃commit的log信息
x , exec = run command (the rest of the line) using shell：使用shell运行命令
d , drop = remove commit：丢弃commit
整个其实就是一个脚本，每一行就相当于一个命令，位置可以互换，命令是从上往下执行的。如果移除某一行，对应的commit就丢失了，但是如果把所有的行都移除的话，整个rebase就被终止了。
了解了上面的命令，修改多条commit就显得很简单了。
由于篇幅的限制，这里笔者就改变第一条commit的提交信息：
之后便会执行rebase过程，然后弹出一个编辑框，修改commit信息即可。
现在的log信息如下：
上面我们提到SecondCommit中包含两个文件，现在笔者将其拆分成两个commit，这个时候需要用到edit命令。
同样的先进入交互式变基： git rebase -i --root
当从上往下执行rebase的时候，遇到edit命令将会暂停rebase。
此时我们要做的就是reset SecondCommit的提交 git reset HEAD~
这时候用git status 查看最新的状态：
交互式变基正在执行，SecondCommit的提交已经从索引区变成untrcked的状态了。我们需要做的就是将这两个文件分别add到暂存区然后commit到索引区。
$ git add newfile1.txt
$ git commit -m "SecondCommitSplit-1
$ git add newfile2.txt
$git commit -m "SecondCommitSplit-2
完成上面的操作后还是处于rebase的状态，让rebase继续执行即可
git rebase --continue
现在log信息如下：
上面我们说过squash和fixup命令具有合并commit的功能，笔者习惯用的是fixup命令，只保存一个message信息。
比如我们现在要合并最近的两个commit：
中间还给SecondCommitSplit-2更改了commit 信息
合并后的log信息如下：
上面讲过，更改行的位置即可改变commit的提交顺序，比如说把第一条和第三条commit的顺序互换：
修改顺序后的log信息如下：
当然，如果commit之间有相互依赖关系的话就没有这么简单了。
其实整篇文章都是围绕pick，reword，edit，squash，fixup等几个常用的命令进行的简单实践，实际开发过程中的情况还要复杂，具体问题还是要具体分析，笔者只是抛砖引玉，如果有不妥当的地方，还请各位看官指点一二。
8. 彻底清除git所有历史提交记录使其为“新”库
以前开发中未制定、遵循 git 管理项目标准，随意(不规范)的提交 严重“污染了”提交历史，使开发主线 “脏乱”;
基于以前的仓库重新开发，这样可保留以前的配置等文件，但是需要删除全部的历史记录、tag、分支等;
由于自己或其他方面特殊需求，需要保留仓库的部分属性(创建时间，说明，主页等)，但需要清除历史记录，使其为“新库”。
基于以上3方面的需求，需要提供一个 在不删除原仓库的前提下，清除原仓库的所有历史提交记录(包含：分支、tag) 解决方案。
语法： git checkout --orphan <new_branch>
例句： git checkout --orphan latest_branch
使用 --orphan 选项，可创建1个"清洁"分支(无任何的提交历史，但是当前分支的内容一应俱全。但严格意义上说，这样创建的分支还不是一个真正的分支，因为HEAD指向的引用中没有commit值，只有在进行一次提交后，它才算得上真正的分支。
新的分支名可以随意命名，但不能和以前的分支名冲突。这儿特别强调是因为很多人习惯默认将分支名创建为 master .
本文以 latest_branch 作为新分支名，这个名称没有任何特殊含义，你可自定义，只要保证和以后的使用一致即可。
一般仓库默认的主分支为 master 分支，如果原来的主分支不是 master, 用实际的主分支名代替。
注意 ： 有些仓库有 master 分支保护，不允许强制 push，需要在远程仓库项目里暂时把项目保护关掉才能推送。
注意 ： 推送前 需要使用 git remote -v 查看关联的远程仓库的信息（主要是远程库的别名）。虽然远程库的别名默认是 origin ,但你可能设置过其他的别名（而非 origin）.
推送前，有的情况需要设置： git branch --set-upstream-to=origin/master master 。
如果别人pull不下来可以敲
可登录远程仓库再次确认。
这儿将上面的步骤封装为 bat 批处脚本(针对windows)，双击即可运行。
文件名： fetch_push_clear_all_history.bat
将文本内容保存为 UTF-8 格式，文件最好放在 git 仓库外。如果放在 git 仓库内，需要将此文件在 .gitignore 中过滤。
抄袭此篇文章
9. 程序员必备技能-git 不会到还有人不会用吧，不会吧不会吧
版本控制 ：版本控制最重要的作用是记录一个文件的修改 历史 记录，并且根据该记录可以切换到对应的 历史 版本，这个也是由个人开发到团队开发重要的工具。
集中式版本控制系统 ：具有一个统一的中央服务器，里面存放着项目的源码。各个客户端都从该服务器中拉取代码和上传自己编写的代码到服务器中。
优点：各个客户端可以查看其他客户端在该项目中做了什么，一定程度上了解项目的进度。同时，管理员可以控制各个程序员的权限。
缺点：无法应对中央服务器的单点故障问题，当中央服务器宕机后，各个客户端都不能提交代码和拉取代码，同时在宕机的期间，做不到版本的 历史 记录。
分布式版本控制系统 ：每个客户端都是一个版本库（本地库），各个客户端维护自己的版本 历史 记录。各个客户端的协作是通过使用远程库（GitHub等）进行的，push把代码推送到远程库中，pull把远程库的代码拉取下来。
优点：解决了集中式版本控制的缺点。在远程库宕机的情况下（虽然说这个概率极低），客户端还是能进行开发的，因为版本的控制是在本地进行的。同时，每个客户端保存的是整个项目，包括 历史 记录，使得更加安全。
Git的工作机制
代码托管中心（远程库） :
底层：head指针指向分支，分支指针指向版本号。当版本号发生变化时，分支指针指向对应的版本号
（1）配置git的忽略文件
（2）在idea中配置git
（3）初始化项目
10. git 文件移动 修改历史还在吗
不会在的了，在新文件夹里看到的历史是从移动的那一刻起的。
但可以在移动前的历史里找到，再从日志文件里查看此文件的日志。