Git的工作原理

我们使用Git来记录每一次文件内容的变更，版本的更新，清晰地比较出不同版本的内容差异；可以使用Git在项目的历史版本自如地进行切换；还可以使用Git从当前项目的更改中撤销一些操作，可以新建分支，合并分支甚至关联远程服务器仓库等，这一切的背后都是怎么实现的？了解Git的思想以及基本原理这些操作也就略知一二了。

Git的分区

workspace: 工作区直接编辑的地方，开发者可见具体的项目，可以直接操作项目文件
index(stage): 暂存区数据暂存的地方
repository: 本地仓库存放已提交的数据
remote: 远程仓库在远程服务器上存放本地仓库的数据

.git文件夹

.git下的文件夹
- hooks 文件夹则存放项目的客户端或服务端钩子脚本
- info 文件夹下的exclude文件包含项目全局忽略匹配模式，与.gitignore文件互补
  - exculd 文件
- logs 保存所有更新的引用记录
  - refs
  - HEAD # 最后一次的提交信息
- objects 文件夹存储着Git数据库的所有内容，存储所有Git的对象
  - info 记录对象存储的附加信息
  - pack 以压缩形式（.pack）存储许多对象的文件，附带索引文件（.idx）以允许它们被随机访问
- refs 文件夹存储着所有分支指向各自提交对象的指针；本地分支，远端分支，标签等
  - heads 记录commit分支的树根
    - master 标识了本地项目中的master分支指向的当前commit的哈希值
  - remotes 记录从远程仓库copy来的commit分支的树根（只读）
    - origin
      - HEAD
      - master 标识了远端项目中的master分支指向的当前commit的哈希值。
  - tags 记录任何对象名称（不一定是提交对象或指向提交对象的标签对象）

.git下的文件

HEAD 文件指向当前分支，包含了一个分支的引用，通过这个文件Git可以得到下一次commit的parent，可以理解为指针
index 文件存储着暂存区的内容信息
config 文件包含项目的配置信息
description 存储着仓库的描述信息，主要给gitweb等git托管系统使用
packed-refs 打包标头和标签以便高效的存储库访问
FETCH_HEAD 是一个版本链接，指向着目前已经从远程仓库取下来的分支的末端版本
ORIG_HEAD 记录的是在进行危险（drastic）操作（如合并merge，回退reset等）时，此操作之前HEAD所指向的位置，便于我们在发生毁灭性失误时进行回退
COMMIT_EDITMSG 保存最新的commit message，Git系统不会用到这个文件，只是给用户一个参考

Git数据库

Git本质上是一个内容寻址文件系统 （就是根据文件内容的hash码来定位文件。这就意味着同样内容的文件，在这个文件系统中会指向同一个位置，不会重复存储。）Git 的核心部分是一个简单的键值对数据库，可以向该数据库插入任意类型的内容，它会返回一个键值，通过该键值可以在任意时刻再次检索（retrieve）该内容
Git 保存的不是文件的变化或者差异，而是一系列不同时刻的文件快照。在进行提交操作时，Git 会保存一个提交对象（commit object）。该提交对象会包含一个指向暂存内容快照的指针。但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。
git通过一种安全散列算法1(SHA-1)可以得到任意文件的SHA-1哈希值(40位的字符)，也就是commit ID,然后通过文件哈希值存取数据，存取的数据都位于objects目录，SHA-1哈希值的前两个字符作为子目录名称，后 38 个字符则作为子目录内文件的名称。

Git的数据存储原理

Git对象

数据对象(blob object) 存储的是一个文件的具体内容
树对象(tree object) 存储的文件的目录，一大坨指针，指向子级tree，或者blob
提交对象(commit object) 存储作者信息，提交者信息，注释，指向一个 big tree 的指针
标签对象（tag object）它包含一个标签创建者信息、一个日期、一段注释信息，以及一个指针。

Git的底层命令、高层命令

Git常用命令共有30多个，可运行git help查看；但Git总共有130多个命令，可以通过git help -a查看，这些命令可以分为高层命令和底层命令，底层命令被设计成unix风格，不常用

- - 往Git数据库存入数据
  - 往Git数据库取出数据
  - 首次提交 testA.txt文件
  - 第二次提交，修改了test.txt文件内容
  - 第三次提交，增加一个新文件 testB.txt ，一个新目录 lib ，lib 里增加一个文件 testC.txt
  - 第四次提交，新建一个分支 branchB，并且在新分支中做了一次 commit
  - 第五次提交, 合并一分支

Git的引用(reference或refs)

浏览完整的提交历史,但为了能遍历那段历史从而找到所有相关对象,需要记住最后提交的SHA-1值 。我们需要一个文件来保存 SHA-1 值，并给文件起一个简单的名字，然后用这个名字指针来替代原始的 SHA-1 值。文件被称为"引用（references，或缩写为 refs）"，使用git branch (branchname) 这样的命令时，Git 实际上会运行 update-ref 命令，取得当前所在分支最新提交对应的 SHA-1 值，并将其加入你想要创建的任何新引用中。
标签引用
远程引用
- 如果你添加了一个远程版本库并对其执行过推送操作，Git 会记录下最近一次推送操作时每一个分支所对应的值，并保存在 refs/remotes 目录下
HEAD引用
- 分支和标签都是指向提交对象的指针,所有的本地分支都存储在 git/refs/heads 目录下，每一个分支对应一个文件
- Git 分支的本质：一个指向某一系列提交之首的指针或引用

Git的对象模型

5. Gitflow工作流

Gitflow工作流约定使用的分支简介

master 分支为项目的核心分支，也是最终对外发布的分支，唯一且稳定。仅提供可读，不可在该分支上直接修改代
develop 分支是项目的开发主干分支，唯一。仅提供可读，不可在该分支上直接修改代码。新功能的开发需从该分支拉取新的分支展开。develop分支应该包含项目完整的全部历史记录。
featrue分支项是目的需求开发分支，可多个，从develop分支或其他featrue分支拉取。程序员的多人分工协作即通过featrue来实现，是代码具体实现的一线程序员接触最多的分支。需求开发完成后，要合并回develop分支。
release 分支为预发布分支，通常被叫做测试分支 ，主要用于开发阶段的测试及bug修复。当feature分支开发完毕后会合并回develop分支，然后再从develop分支拉取release分支提测。测试并修复后的release分支要合并回develop分支以及master分支，并打上合适的tag标记(包含必要的releaseNote)。
hotfix 分支为紧急线上修复分支，即当对外发布的master分支出现重大bug，影响线上使用时，从master分支拉取hotfix分支进行紧急修复。修复后的hotfix分支要合并回master分支和develop分支。

GitFlow工作流程

先，完成中央仓库的初始化，将新项目搭建起框架后的工程代码或要转gitflow的项目代码上传至git中央仓库。项目负责人克隆中央仓库到本地形成master分支，并拉取develop分支(步骤①)推送至服务器。一般的实际场景，开发团队中只有项目负责人有权限操作master分支，拉取develop分支，并将develop分支的代码合并到master分支中。

然后，开发团队中的其他人克隆中央仓库的develop分支到本地，形成全体成员统一的唯一的develop分支轨迹。之后，按照需求及成员各自的分工，各个成员可以从develop分支拉取出各自的featrue分支(步骤②)进行独立的开发；若涉及到多人合作开发同一分支，拉取的分支要及时推送至服务器，便于各成员共享。

当各成员完成各自的功能开发后，需将完成后的代码提交到featrue分支，然后合并到develop分支(步骤③)。代码合并后，featrue分支可以不再保留。

功能累积足够且稳定或到达约定的提测周期时，项目负责人应当从develop分支拉取出release分支(步骤④)，打包提交相应的版本给测试人员进行部署测试，测试中提交的bug全部在该release分支完成修改。

测试结束并完成bug修复后，release分支应该合并回develop分支和master分支(步骤⑤)，代码合并后，release分支可以不再保留。合并后的master分支，应由项目负责人及时推送到中央仓库(步骤⑥)。同时全体成员要及时同步自己develop分支。

有上线需求时，直接从master分支打包提交应用版本进行部署。当线上版本出现重大bug，项目负责人需从master分支拉取hotfix分支(步骤⑦)，进行线上的紧急修复。

最后，修复后的hotfix分支要合并回develop分支和master分支(步骤⑧)。并推送到中央仓库(步骤⑨)。

DevOps系列文章之 Git知识大全