Git目录分析
1、Git是什么？
git是一款用于版本控制的系统。其是一个开源的分布式版本控制系统。可以有效、高速地处理从很小到非常大的项目版本管理。使用起来也比较方便。学习链接传送门
其主要包括下面几个特性：
(1) 在服务器上克隆整个git仓库到本地，可以在本地看代码和修改。
(2) 开发者可以根据需求在本地创建分支，修改代码。
(3) 本地可以在自己的分支上提交代码。
(4) 可以在本地合并分支等操作。
(5) 同步服务器上最新的代码，和自己本地做同步。
(6) 生成补丁，方便加入提交修改。
(7) 参看提交状态，提交代码，通知所有开发人员。
优点：
(1) 适合分布式开发，强调个体。
(2) 公共服务器压力和数据量都不会太大。
(3) 速度快、灵活。
(4) 任意两个开发者之间可以很容易的解决冲突。
(5) 离线工作。
缺点：
(1) 资料少（起码中文资料很少）。
(2) 学习周期相对而言比较长。
(3) 不符合常规思维。
(4) 代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
2、Git主要目录和说明
一般我们使用git进行版本控制，当前仓库下都有个.git的文件夹，我们进去之后可以看到关于git的有关目录，具体每个目录下都包含什么？都有哪些作用，还是需要查一下的。
git目录如下：
drwxr-xr-x 2 bjsoftware 4096 Jun 7 17:08 branches
-rw-r--r-- 1 bjsoftware 292 Jun 7 17:12 config
-rw-r--r-- 1 bjsoftware 73 Jun 7 17:08 description
-rw-r--r-- 1 bjsoftware 411 Jun 7 17:12 FETCH_HEAD
-rw-r--r-- 1 bjsoftware 26 Jun 7 17:12 HEAD
drwxr-xr-x 2 bjsoftware 4096 Jun 7 17:08 hooks
-rw-r--r-- 1 bjsoftware 5411 Jun 7 17:29 index
drwxr-xr-x 2 bjsoftware 4096 Jun 7 17:08 info
drwxr-xr-x 3 bjsoftware 4096 Jun 7 17:12 logs
drwxr-xr-x 4 bjsoftware 4096 Jun 7 17:12 objects
-rw-r--r-- 1 bjsoftware 41 Jun 7 17:12 ORIG_HEAD
-rw-r--r-- 1 bjsoftware 296 Jun 7 17:08 packed-refs
drwxr-xr-x 4 bjsoftware 4096 Jun 7 17:08 refs
| 目录 | 作用 |
|---|---|
| config | 存放当前仓库的配置信息。 |
| description | 仓库描述信息。 |
| HEAD | HEAD指针，它指向了当前分支，这个文件记录了当前分支是哪个分支。 |
| hooks | 存放可执行的shell脚本。 |
| index | 暂存区(stage)，是一个二进制文件。 |
| info | 包含仓库的信息。 |
| logs | 保存所有更新的引用记录，见下文。 |
| objects | 存放git对象。 |
| refs | 引用，见下文。 |
3、比较重要的目录分析
3.1 logs目录
log目录下有两个文件，一个是HEAD，一个是refs。
HEAD ：记录下本地的操作。
refs目录下有两个文件夹：
heads： 存储所有本地分支的对象，每个本地分支名对应一个文件名称。在分支文件夹中存储着本地的操作记录。git banch -a 就是列出heads目录下的名字。
remotes： 存储所有远程分支的对象，每个远程分支对应一个文件名称。这些分支文件中存储的是对应远程分支下的操作记录。
3.2 refs目录
heads： 存储所有本地分支的对象，每个本地分支名对应一个文件名称，文件里面是最近提交的commit id。
remotes： 远程仓库信息，其中\refs\remotes\origin\HEAD记录了当前分支指向的远程分支，即当前分支提交到的远程分支。
3.3 config目录
config是包含你的仓库配置文件。具体如下所示：
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = /*远程URL*/
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "branch_name"]
remote = origin
merge = branch_name
[branch "本地branch_name"]
remote = origin
merge = 远程branch_name
3.4 hooks 钩子目录
上文介绍了hooks存放的是脚本，具体脚本和作用如下：
-rwxr-xr-x 1 1049089 478 Apr 11 09:34 applypatch-msg.sample*
-rwxr-xr-x 1 1049089 896 Apr 11 09:34 commit-msg.sample*
-rwxr-xr-x 1 1049089 4655 Apr 11 09:34 fsmonitor-watchman.sample*
-rwxr-xr-x 1 1049089 189 Apr 11 09:34 post-update.sample*
-rwxr-xr-x 1 1049089 424 Apr 11 09:34 pre-applypatch.sample*
-rwxr-xr-x 1 1049089 1643 Apr 11 09:34 pre-commit.sample*
-rwxr-xr-x 1 1049089 416 Apr 11 09:34 pre-merge-commit.sample*
-rwxr-xr-x 1 1049089 1374 Apr 11 09:34 pre-push.sample*
-rwxr-xr-x 1 1049089 4898 Apr 11 09:34 pre-rebase.sample*
-rwxr-xr-x 1 1049089 544 Apr 11 09:34 pre-receive.sample*
-rwxr-xr-x 1 1049089 1492 Apr 11 09:34 prepare-commit-msg.sample*
-rwxr-xr-x 1 1049089 2783 Apr 11 09:34 push-to-checkout.sample*
-rwxr-xr-x 1 1049089 3650 Apr 11 09:34 update.sample*
提交工作流钩子
前四个钩子涉及提交的过程。
pre-commit 钩子在键入提交信息前运行。 它用于检查即将提交的快照，例如，检查是否有所遗漏，确保测试运行，以及核查代码。 如果该钩子以非零值退出，Git 将放弃此次提交，不过你可以用 git commit --no-verify 来绕过这个环节。 你可以利用该钩子，来检查代码风格是否一致（运行类似 lint 的程序）、尾随空白字符是否存在（自带的钩子就是这么做的），或新方法的文档是否适当。
prepare-commit-msg 钩子在启动提交信息编辑器之前，默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。 该钩子接收一些选项：存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。 它对一般的提交来说并没有什么用；然而对那些会自动产生默认信息的提交，如提交信息模板、合并提交、压缩提交和修订提交等非常实用。 你可以结合提交模板来使用它，动态地插入信息。
commit-msg 钩子接收一个参数，此参数即上文提到的，存有当前提交信息的临时文件的路径。 如果该钩子脚本以非零值退出，Git 将放弃提交，因此，可以用来在提交通过前验证项目状态或提交信息。 在本章的最后一节，我们将展示如何使用该钩子来核对提交信息是否遵循指定的模板。
post-commit 钩子在整个提交过程完成后运行。 它不接收任何参数，但你可以很容易地通过运行 git log -1 HEAD 来获得最后一次的提交信息。 该钩子一般用于通知之类的事情。
电子邮件工作流钩子
你可以给电子邮件工作流设置三个客户端钩子。 它们都是由 git am 命令调用的，因此如果你没有在你的工作流中用到这个命令，可以跳到下一节。 如果你需要通过电子邮件接收由 git format-patch 产生的补丁，这些钩子也许用得上。
第一个运行的钩子是 applypatch-msg 。 它接收单个参数：包含请求合并信息的临时文件的名字。 如果脚本返回非零值，Git 将放弃该补丁。 你可以用该脚本来确保提交信息符合格式，或直接用脚本修正格式错误。
下一个在 git am 运行期间被调用的是 pre-applypatch 。 有些难以理解的是，它正好运行于应用补丁 之后，产生提交之前，所以你可以用它在提交前检查快照。 你可以用这个脚本运行测试或检查工作区。 如果有什么遗漏，或测试未能通过，脚本会以非零值退出，中断 git am 的运行，这样补丁就不会被提交。
post-applypatch 运行于提交产生之后，是在 git am 运行期间最后被调用的钩子。 你可以用它把结果通知给一个小组或所拉取的补丁的作者。 但你没办法用它停止打补丁的过程。
其它客户端钩子
pre-rebase 钩子运行于变基之前，以非零值退出可以中止变基的过程。 你可以使用这个钩子来禁止对已经推送的提交变基。 Git 自带的 pre-rebase 钩子示例就是这么做的，不过它所做的一些假设可能与你的工作流程不匹配。
post-rewrite 钩子被那些会替换提交记录的命令调用，比如 git commit --amend 和 git rebase（不过不包括 git filter-branch）。 它唯一的参数是触发重写的命令名，同时从标准输入中接受一系列重写的提交记录。 这个钩子的用途很大程度上跟 post-checkout 和 post-merge 差不多。
在 git checkout 成功运行后，post-checkout 钩子会被调用。你可以根据你的项目环境用它调整你的工作目录。 其中包括放入大的二进制文件、自动生成文档或进行其他类似这样的操作。
在 git merge 成功运行后，post-merge 钩子会被调用。 你可以用它恢复 Git 无法跟踪的工作区数据，比如权限数据。 这个钩子也可以用来验证某些在 Git 控制之外的文件是否存在，这样你就能在工作区改变时，把这些文件复制进来。
pre-push 钩子会在 git push 运行期间， 更新了远程引用但尚未传送对象时被调用。 它接受远程分支的名字和位置作为参数，同时从标准输入中读取一系列待更新的引用。 你可以在推送开始之前，用它验证对引用的更新操作（一个非零的退出码将终止推送过程）。
Git 的一些日常操作在运行时，偶尔会调用 git gc --auto 进行垃圾回收。 pre-auto-gc 钩子会在垃圾回收开始之前被调用，可以用它来提醒你现在要回收垃圾了，或者依情形判断是否要中断回收。
服务器端钩子
除了客户端钩子，作为系统管理员，你还可以使用若干服务器端的钩子对项目强制执行各种类型的策略。 这些钩子脚本在推送到服务器之前和之后运行。 推送到服务器前运行的钩子可以在任何时候以非零值退出，拒绝推送并给客户端返回错误消息，还可以依你所想设置足够复杂的推送策略。
pre-receive
处理来自客户端的推送操作时，最先被调用的脚本是 pre-receive。 它从标准输入获取一系列被推送的引用。如果它以非零值退出，所有的推送内容都不会被接受。 你可以用这个钩子阻止对引用进行非快进（non-fast-forward）的更新，或者对该推送所修改的所有引用和文件进行访问控制。
update
update 脚本和 pre-receive 脚本十分类似，不同之处在于它会为每一个准备更新的分支各运行一次。 假如推送者同时向多个分支推送内容，pre-receive 只运行一次，相比之下 update 则会为每一个被推送的分支各运行一次。 它不会从标准输入读取内容，而是接受三个参数：引用的名字（分支），推送前的引用指向的内容的 SHA-1 值，以及用户准备推送的内容的 SHA-1 值。 如果 update 脚本以非零值退出，只有相应的那一个引用会被拒绝；其余的依然会被更新。
post-receive
post-receive 挂钩在整个过程完结以后运行，可以用来更新其他系统服务或者通知用户。 它接受与 pre-receive 相同的标准输入数据。 它的用途包括给某个邮件列表发信，通知持续集成（continous integration）的服务器， 或者更新问题追踪系统（ticket-tracking system） —— 甚至可以通过分析提交信息来决定某个问题（ticket）是否应该被开启，修改或者关闭。 该脚本无法终止推送进程，不过客户端在它结束运行之前将保持连接状态， 所以如果你想做其他操作需谨慎使用它，因为它将耗费你很长的一段时间。
4、总结
整体git的内容大概就是这些了，我也罗列的比较粗糙，但是git使用起来还是很方便的。用它做学习笔记、写demo测试程序等还是相当的可以，非常的银杏。