Git源码分析

最新推荐文章于 2024-04-25 17:22:31 发布

Tavi_

最新推荐文章于 2024-04-25 17:22:31 发布

阅读量3.1k

点赞数 1

分类专栏： Git 文章标签： git

本文链接：https://blog.csdn.net/ternence_zq/article/details/124141959

版权

Git 专栏收录该内容

6 篇文章 1 订阅

订阅专栏

Git源码分析

获取git源码

在Github上可以找到Git的仓库镜像：
https://github.com/git/git.git

$ git clone https://github.com/git/git.git
$  git log --date-order --reverse 
commit e83c5163316f89bfbde7d9ab23ca2e25604af290
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date:   Thu Apr 7 15:13:13 2005 -0700

    Initial revision of "git", the information manager from hell

# 变更为第一个提交，指定commit-id
$ git reset --hard e83c5163316f89bfbde7d9ab23ca2e25604af290

源码分析

$ ls
cache.h  cat-file.c  commit-tree.c  init-db.c  Makefile  read-cache.c  README  read-tree.c  show-diff.c  update-cache.c  write-tree.c

几个比较重要的文件分析：

cache.h、init-db.c、update-cache.c、write-tree.c、show-diff.c

git-0.1版本源码分析

源码解析：Git的第一个提交是什么样的？

这才是真正的Git——Git内部原理揭秘！

深入理解 git 合并操作

冲突的产生

情景一：多个分支代码合并到一个分支时；
情景二：多个分支向同一个远端分支推送代码时；

其实很多命令都可能出现冲突，但从根本上来讲，都是merge 和 patch（应用补丁）时产生冲突。

而rebase就是重新设置基准，然后应用补丁的过程，所以也会冲突。

git pull会自动merge，repo sync会自动rebase，所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了。

git的合并中产生冲突的具体情况：

两个分支中修改了同一个文件（不管什么地方）
两个分支中修改了同一个文件的名称

Git 是如何发现代码冲突的

git仓下的.git文件夹作用

最初版本的初始化的git仓下是.dircache文件夹，现在的git仓都改为.git文件夹。

$ tree .git/
.git/
├── branches
├── COMMIT_EDITMSG
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── logs
│   ├── HEAD
│   └── refs
│       └── heads
│           ├── after
│           └── master
├── objects
│   ├── 0f
│   │   └── d247c919b0faa824e03cbef3b4b375d804e481
│   ├── 1f
│   │   └── 5a286baf12b33bd5ff2f98d1860bd2c38b0087
│   ├── 33
│   │   └── 12aa8e3e01a58abe1fcad21dc6054e2c193d79
│   ├── 3b
│   │   └── b59edb5254560a4bd29f8b00d53498a91caa1f
│   ├── 4c
│   │   └── aaa1a9ae0b274fba9e3675f9ef071616e5b209
│   ├── info
│   └── pack
├── ORIG_HEAD
└── refs
    ├── heads
    │   ├── after
    │   └── master
    └── tags

index：commit提交的索引

**objects：**sha1值的第一个字节hex值为目录，其余字节的hex值为名称，并且这些内容都是经过压缩的

如：0fd247c919b0faa824e03cbef3b4b375d804e481，0f为目录，d247c919b0faa824e03cbef3b4b375d804e481为文件名称

这里面的值可以通过git cat-file查看，-t是object类型，-p是查看保存的内容

$ git cat-file -t 0fd2
tree
$ git cat-file -p 0fd2
100644 blob 55bd0ac4c42e46cd751eb7405e12a35e61425550	a.txt
100644 blob c200906efd24ec5e783bee7f23b5d7c941b0c12c	b.txt

objects中保存的类型有：blob、tree、commit

blob类型：它只储存的是一个文件的内容，不包括文件名等其他信息。然后将这些信息经过SHA1哈希算法得到对应的哈希值58c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c，作为这个object在Git仓库中的唯一身份证。

tree类型：它将当前的目录结构打了一个快照。从它储存的内容来看可以发现它储存了一个目录结构（类似于文件夹），以及每一个文件（或者子文件夹）的权限、类型、对应的身份证（SHA1值）、以及文件名。

commit类型：它储存的是一个提交的信息，包括对应目录结构的快照tree的哈希值，上一个提交的哈希值（这里由于是第一个提交，所以没有父节点。在一个merge提交中还会出现多个父节点），提交的作者以及提交的具体时间，最后是该提交的信息。

refs/heads：本地的分支

refs/tags：打的标签

logs/HEAD：记录HEAD指向的所有记录

logs/refs/heads/after：同上