Naive Git

国际劳动节又称 “五一国际劳动节”、“国际示威游行日”（International Workers' Day 或者 May Day），是世界上 80 多个国家的全国性节日。定在每年的五月一日。它是全世界劳动人民共同拥有的节日。

1884 年 10 月，美国和加拿大的八个国际性和全国性工人团体，在美国芝加哥举行一个集会，决定于 1886 年 5 月 1 日举行总罢工，迫使资本家实施八小时工作制。这一天终于来到了。1886 年 5 月 1 日，美国 2 万多个企业的 35 万工人停工上街，举行了声势浩大的示威游行，各种肤色，各个工种的工人一齐进行总罢工。仅芝加哥一个城市，就有 4.5 万名工人涌上街头。这下，美国的主要工业部门便处于瘫痪状态，火车变成了僵蛇，商店更是鸦雀无声，所有的仓库也都关门并贴上封条。

1866 年，第一国际日内瓦会议提出八小时工作制的口号。 [4] 1886 年 5 月 1 日，以美国芝加哥为中心，在美国举行了约 35 万人参加的大规模罢工和示威游行，示威者要求改善劳动条件，实行八小时工作制。1886 年 5 月 3 日芝加哥政府出动警察进行镇压，开枪打死两人，事态扩大，5 月 4 日罢工工人在干草市场广场举行抗议，由于不明身份者向警察投掷炸弹，最终警察开枪，先后共有 4 位工人、7 位警察死亡，史称 “干草市场暴乱”（Haymarket Riot）或 “干草市场屠杀”（Haymarket Massacre）。在随后的宣判中有 8 位无政府主义者以谋杀罪被起诉，4 位无政府主义者被绞死，1 位在牢中自杀。

为纪念这次伟大的工人运动及抗议随后的宣判，在世界范围内举行了工人的抗议活动。这些活动成为了 “国际劳动节” 的前身。

1889 年 7 月，在恩格斯组织召开的第二国际成立大会上宣布将每年的五月一日定为国际劳动节。

经过艰苦的流血斗争，终于获得了胜利。为纪念这次工人运动，1889 年 7 月 14 日，由各国马克思主义者召集的社会主义者代表大会，在法国巴黎隆重开幕。大会上，会代表一致同意：把 5 月 1 日定为国际无产阶级的共同节日。这一决定立即得到世界各国工人的积极响应。1890 年 5 月 1 日，欧美各国的工人阶级率先走向街头，举行盛大的示威游行与集会，争取合法权益。从此，每逢这一天世界各国的劳动人民都要集会、游行，以示庆祝，并公众放假。

五一国际劳动节，一起写一个简单的Git吧！

Git的原理是怎么样呢？

Git is a distributed version-control system for tracking changes in source code during software development.

各位读者就算不了解git的原理，想必也会用三把斧git add; git commit; git push，下面就简单说一下git是怎么做的版本管理的：跟踪文件的变化，使用commit作为标记，与远程服务器同步。

跟踪文件变化

假如你来开发git这个工具，在初始化一个文件夹（repository）后，为了记录之后可能的修改，你需要记录当前所有需要跟踪的文件内容，最简单的就是全部复制一份好了。

文件是否变化了？比较一下文件哈希好了。

Commit作标记

顾言思义，就是将当前的repository状态存储起来，作为commit。你可以通过commit恢复到任意状态，git tag本质也只是给这个commit一个tag（别名），git branch 也是一样。

恢复到某一个commit，就是将它所代表的repository状态恢复起来，就是将文件全部内容以及当前commit恢复到那个状态。

与远程服务器同步

git说自己是分布式的版本管理系统，是因为假如A、B、C三个人一起合作，理论上每个人都有一份server的版本，而且可以独立开发，解决冲突。

Git具体是怎么做的呢？

原理说完了，但commit的管理是要用东西来存储读取管理的，Git没有用数据库，直接将其内容放到.git文件夹里。

里面有什么内容呢？

  .
  |-- HEAD //指向branch、tag (ref: refs/heads/devbranch)
  |-- index
  |-- objects
  |   |-- 05
  |   |   `-- 76fac355dd17e39fd2671b010e36299f713b4d
  |   |-- 0c
  |   |   `-- 819c497e4eca8e08422e61adec781cc91d125d
  |   |-- fe
  |   |   `-- 897108953cc224f417551031beacc396b11fb0
  |   |-- fe
  |   |   `-- 897108953cc224f417551031beacc396b11fb0
  |   |-- info
  |  
  `-- refs
      |-- heads //各个branch的heads
      |   `-- master //此分支最新的commit id
      |   `-- devBranch // checkout -b branch就会生成的branch
      `-- tags
          `-- v0.1

各位再结合

下面我展开讲讲：

HEAD: 指向branch或者tag，标记当前是在哪个分支或者tag上；
index： TODO
objects：记录文件的内容，每个文件夹名称是该object的sha1值的前两位，文件夹下的文件名称是sha1值的后18位；(tips:sha1算法，是一种加密算法，会计算当前内容的哈希值，作为object的文件名，得到的哈希值是一个用十六进制数字组成的字符串（长度为40）)
refs
- heads: heads里的就是各个分支的HEAD分别指向哪个commit id；简单说，就是各个branch分别最新的commit是什么，这样子git checkout branch就可以切换到对的地方
- tags: 同理，这个文件夹里存的都是各个tag

那么，新建一个branch的时候，只要在refs/heads文件夹里新建branch 名字的文件，并将当前commit id存进去即可；

新建一个commit时，只要根据HEAD文件，找到当前的branch或者tag 是什么，修改里面的内容即可。

有点不好懂？咱给出一个git的实例，默认在一个文件夹执行git init后，添加一个文件并commit的信息, commit id为017aa3d7851e8bbff78a697566b5f827b183483c：

$ cat .git/HEAD
ref: refs/heads/master
$ cat .git/refs/heads/master
017aa3d7851e8bbff78a697566b5f827b183483c

如上，HEAD指向了master，而master的commit id正是刚刚commit的id。

存储读取解决了，那么commit怎么组织呢？

将当前的repository状态存储起来，作为commit。你可以通过commit恢复到任意状态，git tag本质也只是给这个commit一个tag（别名），git branch 也是一样。

恢复到某一个commit，就是将它所代表的repository状态恢复起来，就是将文件全部内容以及当前commit恢复到那个状态。

上面说了，管理文件夹（repository）状态，但是文件夹是可以嵌套的，与文件不一样，需要有这层级关系，同时也要存文件内容，怎么做来区分呢？

我们可以引入以下概念：

Tree：代表文件夹，因为git init时，就是把当前文件夹./作为项目来管理，那么接下来所有要追踪的项目无非就是./里的文件或者文件夹而已；
Blob：文件，Tree里可以包含它；

关系如下图：

给点我们写的数据结构代码你看看，要注意的是，tree可以拥有blob或者tree，所以用了union；parent与next作为链表使用，作为文件夹目录管理；

struct tree_entry_list {
    struct tree_entry_list *next;
    union {
        struct tree *tree;
        struct blob *blob;
    } item;
    struct tree_entry_list *parent;
};

struct tree {
    struct tree_entry_list *entries;
};

而commit跟树一样，也是有层级的单链表，不过只有

struct commit {
    struct commit *parents;
    struct tree *tree;

    char *commit_id[10];
    char *author;
    char *committer;
    char *changelog;
};

一图胜千言，看图吧：

云风的游戏资源仓库及升级发布

云风参考过git的原理做过一个游戏资源仓库管理，我下面讲一下它跟git的区别，他的文章我觉得比较绕，没有背景知识的人很难看明白。

背景

我们的引擎的一个重要特性就是，在 PC 上开发，在移动设备上运行调试。我们需要频繁的将资源同步到设备上

程序以 c/s 结构运行时，在移动设备上先建立一个空的镜像仓库，同步 PC 端的资源仓库。运行流程是这样的：

首先在客户端启动的时候，向服务器索取一个根索引的 hash ，在本地镜像上设定根。

客户端请求一个文件路径时，从根开始寻找对应的目录索引文件，逐级查找。如果本地有所需的 hash 对象，就直接使用；否则向服务器请求，直到最后获得目标文件。api 的设计上，open 一个资源路径，要么返回最终的文件，要么返回一个 hash ，表示当前还缺少这个 hash 对象；这样，可以通过网络模块请求这个对象；获得该对象后，无须理会这个对象是什么，简单写入镜像仓库，然后重新前面的过程，再次请求未完成的路径，最终就能打开所需的资源文件。

场景是：Client <- 他的游戏服务器，单向同步；

他是这样子做的，客户端的仓库是key-value的文件数据库，key是文件的hash，value就是文件内容；

同步时，会从根到具体hash全量同步文件下载到数据库；

假如客户端使用资源时，发现缺乏这个文件，就用hash去服务器拉下来。

换言之，因为不需要管理本地版本，并且同步到上游，所以无需在本地记录全量的版本状态

跟Git的区别：

场景是：Client <-> gitHub ，双向同步；

git 需要本地组织commit，切换本地有但服务器没有的版本（就是离线操作），同时还需要将变更同步到上游。

最后的建议

如果看完该文，让你跃跃欲试的话，请不要用C写，请不要用C写，请不要用C写。

从零开始写过几个大一点项目，每次都觉得用C写项目太难受了，这次我写git commit时，发现要读写文件，解析内容，我发出了内心的感叹：

太难了，不是写这个难，是C太难用了。。

想到我要遍历这些文件，根据目录得到tree的hash，然后还要update这棵树，把tree跟commit还要blob反序列存到文件里，还要读出来，之后还要组织链表操作，用C写就觉得百般阻挠。。。