⑴ 关于git和github版本管理的疑问，先谢谢大家了，80分~~
楼主 我一个问题一个问题的回答哈1、git是分布式管理，也就是说服务器上的和本地内的可以随时同步容更新，当你提交不成功时，你所更改的文件会放在缓存区，别人来提交的时候会一起把所有更改的文件提交，建议代码入库不要多个人来操作 一个人就好了 这样子不容易出错。2、git分支间的合并—是把两个分之间不同的修改合并到一起，如果遇到冲突(比如修改到了同一个文件)，就会提示你，让你忽略或者是手动处理。（建议手动处理）3、不用，你就在本地客户端克隆一个代码库，然后进行本地修改，到时候代码入库的时候注意一个先后顺序就行了。4、为什么要在服务器上改呢？直接在本地进行开发，然后在进行服务器的代码同步不就好了吗
⑵ 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对象一一对应。
⑶ Git底层数据结构和原理之三：存储模型
git 区别与其他 vcs 系统的一个最主要原因之一是：git 对文件版本管理和其他 vcs 系统对文件版本的实现理念完成不一样。这也就是 git 版本管理为什么如此强大的最核心的地方。
SVN 等其他的 VCS 对文件版本的理念是以文件为水平维度，记录每个文件在每个版本下的 delta 改变。 Git 对文件版本的管理理念却是以每次提交为一次快照，提交时对所有文件做一次全量快照，然后存储快照引用。
Git 在存储层，如果文件数据没有改变的文件，Git 只是存储指向源文件的一个引用，并不会直接多次存储文件，这一点可以在 pack 文件中看见。如下图所示：
存储随着需求和功能的不断复杂，git 版本的不断更新，但是主要的存储模型还是大致不变。如下图所示：
⑷ git的文件系统与底层原理
由于工作中使用git作为版本管理，之前对git的了解不多，特别是底层方面的原理方面的知识。为了能更好的使用git，有必要学习并梳理下相关知识。
步入正题：
执行git init 初始化后，会在.git文件夹下会创建多个目录，每个文件夹功能划分的很清晰。
Git 是一套内容寻址文件系统.通过键值对的方式存储和查找。
下面操作一遍，直观的看到整个过程，以便理解。
参考： https://git-scm.com/docs/git-hash-object
参考： http://man.linuxde.net/find
可以见到文件名称为数字和字母组成的字符串。这个是根据文件内容和头信息（Header），通过SHA-1算法计算得出的40位十六进制校验和。
SHA-1是一种加密哈希函数（cryptographic hash function）。SHA-1将文件中的内容通过其hash算法生成一个160bit的报文摘要，即40个十六进制数字（每个十六进制数字占4位）。它几乎可以保证，如果两个文件的SHA-1值是相同的，那么它们确是完全相同的内容（类似于生活中的指纹识别）；SHA-1主要有两种用途，一个是加密，一个是数据完整性校验。Linux kernel开创者和Git的开发者——Linus说，Git使用了SHA-1并非是为了安全性，而是为了数据的完整性。理论上SHA-1会在2^51攻击下实现哈希碰撞，所以也不是完全的安全。
参考： https://git-scm.com/docs/git-cat-file
模拟bolb对象存储流程
以上，说明了git的数据存储的基本方式。主要步骤：
下面是创建文件，修改文件，恢复文件的相关过程。
git会记录每个版本的修改，根据校验和可恢复到相应的版本。
小结： 这个过程中包括文件创建、文件修改、文件恢复，跟我们平时工作中使用的高级命令功能很相似。git会把整个过程转化为底层操作，同时对用户透明。
相关引用参考： http://smilejay.com/2012/08/git-commit-sha-1/ https://git-scm.com/book/zh/v1/Git-%E5%86%85%E9%83%A8%E5%8E%9F%E7%90%86-Git-%E5%AF%B9%E8%B1%A1
