Git(三).git 文件夹详解

开源 0

目录

    • 一、初始化新仓库
    • 二、.git 目录
      • 2.1 hooks 文件夹
      • 2.2 info 文件夹
      • 2.3 logs 文件夹
      • 2.4 objects 文件夹【重要】
      • 2.5 refs 文件夹【重要】
      • 2.6 COMMIT_EDITMSG
      • 2.7 config
      • 2.8 description
      • 2.9 FETCH_HEAD
      • 2.10 HEAD【重要】
      • 2.11 index【重要】
      • 2.12 ORIG_HEAD
      • 2.13 packed-refs

在这里插入图片描述

  • 官网地址: https://www.git-scm.com/
  • 官方文档: https://www.git-scm.com/docs
  • 官方电子书: https://git-scm.com/book/zh/v2
  • GitHub: https://github.com/git/git

一、初始化新仓库

命令:git init

解析: 如果需要对现有的某个项目使用 Git 管理,只需要到项目所在目录,执行该命令即可。

作用: 初始化后,在当前目录下会出现一个名为 .git 的目录,所有 Git 需要的数据和资源都存放在这个目录中。不过,目前仅仅是按照既有的结构框架初始化好了所有的文件和目录,还没有开始跟踪管理项目中的文件。

下面展示一下 .git 目录中比较全的内容,单单只执行 git init 命令的话不会一次创建所有文件的,部分文件在使用到某些特殊的场景时才会创建。

二、.git 目录

在这里插入图片描述

2.1 hooks 文件夹

hooks 目录中,存储了 Git 钩子脚本的模板文件。

在这里插入图片描述

Git 钩子是一些可执行的脚本,它们在特定的 Git 操作(如提交、合并、推送等)前后运行,可以用于自定义和控制 Git 操作的行为。

常见的 Git 钩子脚本:

  • pre-commit:在执行提交操作前运行,可以用于代码检查、格式化等操作,以确保提交的代码符合规范。
  • pre-receive:在执行推送操作前执行,可以用于进行服务端校验、权限验证等操作,以控制推送到远程仓库的内容。
  • post-commit:在执行提交操作后运行,可以用于发送通知、执行后续操作等。
  • post-receive:在执行推送操作后运行,可以用于执行服务器端处理、触发自动部署等操作。

注意: Git 钩子脚本在 .git 文件夹中存储的是模板文件,需要将其重命名为去掉 .sample 后缀,并赋予可执行权限,才能生效。每个 Git 仓库的钩子脚本都是独立的,不会被版本控制。

2.2 info 文件夹

info 目录中,存储了一些额外的 Git 配置文件。

在这里插入图片描述

  • exclude:全局性排除文件。

2.3 logs 文件夹

logs 目录用于存储 Git 仓库的引用日志信息。

在这里插入图片描述

  • refs文件夹:存储各个引用(如分支、标签)的引用日志信息。每个应用都对应的一个子目录,如:

    refs/heads 用于存储分支的引用日志,

    refs/tags 用于存储标签的引用日志。

  • HEAD:存储 HEAD 引用的变动记录。每次 HEAD 引用变动时,都会在该文件中记录变动的信息。

这些日志文件记录了引用的变动历史,包括引用的新增、删除、移动等操作。它们可以用于查看仓库中引用的修改历史,以及恢复到之前的引用状态。

注意: logs 目录中的日志文件是 Git 维护的,不应手动修改或删除这些文件,以免导致仓库状态不一致。

2.4 objects 文件夹【重要】

objects 目录是 Git 版本控制系统中一个非常重要的目录,用于存储 Git 仓库中的所有对象(objects)。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在 objects 目录下,有以下几个子目录:

  • info目录:存储一些辅助信息和索引文件,用于加快对象访问速度。
  • pack目录:存储了使用 Git 的打包机制(packing)压缩的对象文件。Git 会定期将一些对象打成一个单独的文件,并使用压缩算法来减小存储空间和提高性能。
  • 哈希目录:除了上述两个子目录外,objects 目录下还包含一系列以两个字符为前缀的子目录,用于存储具体的对象文件。Git 使用 SHA-1 哈希算法对每个对象 进行唯一标识,每个对象的文件名是由哈希值组成的。

在这些哈希目录中,存储了 Git 仓库中的所有对象,包括提交对象、树对象、文件对象等。每个对象都已二进制 格式存储在对应的哈希姆目录中,文件内容经过压缩和哈希计算。

通过这种方式,Git 可以高效地存储和管理大量的对象,使得版本控制和跟踪文件的变化变得高效和可靠。

注意: objects 目录中的内容是 Git 的内部结构,通常不需要直接操作这些文件。

2.5 refs 文件夹【重要】

refs 目录用于存储指向提交对象的引用(reference),如:分支引用(branch references)和标签引用(tag references)等。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在 refs 目录下,有以下几个子目录:

  • heads存储分支引用,每个分支都对应一个文件,文件名与分支名称相同。这些文件中的内容是指向分支最新提交的指针。
  • tags存储标签引用,每个标签都对应一个文件,文件名与标签名称相同。这些文件中的内容是指向标签的对象的指针。
  • remotes存储远程引用,每个远程仓库都对应一个子目录,目录名与远程仓库名称相同。在每个远程仓库目录下,可以存储与该远程仓库相关的引用,如远程分支引用。

这些引用文件(通常是文本文件)记录了指向特定提交对象的指针。通过这些引用,Git 可以跟踪和管理分支、标签以及与远程仓库的交互。

注意: refs 目录中的引用文件是 Git 维护的,不应手动修改或删除这些文件,以免导致仓库状态不一致。

2.6 COMMIT_EDITMSG

COMMIT_EDITMSG 是一个文本文件,用于存储最近一次 Git 提交时的提交消息。

在这里插入图片描述

当你使用 git commit 命令提交代码时,Git 会打开一个文本编辑器,让你输入提交消息。输入的消息会保存在 COMMIT_EDITMSG 文件中。这个文件包含了你最近一次提交的提交消息内容。

通过编辑 COMMIT_EDITMSG 文件,你可以查看、修改或删除之前的提交消息。这对于需要进行提交消息的审查或修改非常有用。

注意: COMMIT_EDITMSG 文件只记录最近一次提交的提交消息。每次提交后,文件内容会被更新为新的提交消息。旧的提交消息不会保留。

2.7 config

config 文件是 Git 仓库的配置文件,用于存储仓库级别的配置选项。

在这里插入图片描述

config 文件是一个文本文件,使用 INI 格式(键值对)来组织配置信息。它包含了一系列配置项,用于定义 Git 仓库的行为和属性。

在 config 文件中,可以找到以下常见的配置项:

  • [core]:包含与 Git 核心功能相关的配置选项,如仓库路径、忽略文件权限等。
  • [remote "<remote-name>"]:用于定义与远程仓库的连接和交互的配置选项,可以指定远程仓库的 URL、分支跟踪等。
  • [branch "<branch-name>"]:用于定义分支相关的配置选项,如分支的追踪关系、合并策略等。
  • [user]:用于设置 Git 用户的姓名和邮箱地址,这些信息会出现在提交记录中。
  • [alias]:用于定义 Git 命令的别名,可以简化常用命令的输入。

除了上述常见的配置项,config 文件还可以包含其他自定义的配置项,用于满足特定的需求和工作流程。

注意: config 文件夹是每个 Git 仓库独立的,不会被版本控制。如果要对全局的 Git 配置进行更改,可以使用 git config --global 命令来修改全局配置文件。

2.8 description

description 是一个纯文本文件,用于提供关于 Git 仓库的简要描述信息。

在这里插入图片描述

description 文件通常包含一行文本,用于描述仓库的目的、用途或其他相关信息。这个描述可以是任意的自由文本,没有特定的格式要求。

在一些 Git 服务提供商(如 GitHub、GitLab 等)中,description 文件的内容可能会显示在仓库的概述页面或其他相关位置,以帮助用户了解仓库的用途和特点。

注意: description 文件是可选的,如果你的仓库中没有,也不会影响 Git 的正常运行和版本控制功能。

2.9 FETCH_HEAD

FETCH_HEAD 是一个特殊的引用文件,用于存储最近一次从远程仓库中获取(fetch)的提交记录。

在这里插入图片描述

git pull --help 说:在默认模式下,git pullgit fetch 的缩写,其后是 git merge FETCH_HEAD

git pull 首先调用 git fetch,通常情况下是从远程获取分支;FETCH_HEAD 指向此分支的尖端(就像分支一样,它存储提交的 SHA-1)。git pull 然后调用 git merge,合并 FETCH_HEAD 到当前分支中。

注意: FETCH_HEAD 文件是 Git 维护的,不应手动修改或删除这个文件,以免导致仓库状态不一致。

2.10 HEAD【重要】

HEAD 是一个特殊的引用文件,用于指示当前所在分支或提交。

在这里插入图片描述

HEAD 文件包含一个引用,可以是以下两种形式之一:

  • 直接指向某个提交的哈希值,表示当前处于分离头指针(detached HEAD)状态,即不再任何分支上工作。
  • 以 ref: refs/heads/<branch-name> 的形式,表示当前所在的分支。

通过查看 HEAD 文件的内容,可以确定当前所在的分支或直接指向的提交。这对于了解当前工作状态、进行分支操作和切换等非常有用。

注意: 不应手动修改或删除 HEAD 文件,以免导致仓库状态不一致。Git 会自动更新 HEAD 文件,以反映当前所在的分支或提交。

2.11 index【重要】

index 是一个二进制文件,也成为暂存区(staging area)或者索引(index)。

在这里插入图片描述

index 文件记录了当前工作目录中被修改的文件的快照信息。当你使用 git add 命令将文件添加到暂存区时,Git 会将这些文件的快照信息保存在 index 文件中。

index 文件的内容包括文件名、文件的元数据(如权限和时间戳)以及文件内容的哈希值。它充当了工作目录和下一次提交之间的桥梁。

通过使用 git status 命令,你可以查看 index 文件的状态,了解哪些文件已经被添加到暂存区,哪些文件被修改但尚未添加。

注意: index 文件是 Git 维护的,不应手动修改或删除这个文件,以免导致仓库状态不一致。Git 会自动更新 index 文件,以反应当前暂存区的状态。

2.12 ORIG_HEAD

ORIG_HEAD 是一个特殊的引用,用于记录最近一次 HEAD 引用的值。

在这里插入图片描述

在 Git 进行一些危险的操作(如 reset、merge 或者 rebase)之前,Git 会将 HEAD 原来所指向的 commit 对象的 SHA-1 值存放于 ORIG_HEAD 文件中。这样做是为了提供一种回退的机制,以防以外操作导致数据丢失或不可逆转的更改。

通过使用 git reset、git merge、git rebase 等命令进行操作后,可以使用 git reset ORIG_HEAD 命令将 HEAD 引用恢复到之前的状态。

2.13 packed-refs

packed-refs 是一个存储远程引用的文件。

在这里插入图片描述

packed-refs 包含了远程分支和标签的引用信息,这些引用指向远程仓库中的特定提交。

packed-refs 文件的目的是提高性能,当引用过多时,会将其中一些引用以压缩形式存储在该文件中,以减少 .git 文件夹的大小和读取时间。在该文件中,每个引用包含一个 SHA-1 值,该值指向特定的提交。这样,在使用 Git 命令时,Git 可以更快速地访问和检索这些引用。

整理完毕,完结撒花~ 🌻





参考地址:

1.Git中的FETCH_HEAD是什么意思?https://www.imooc.com/wenda/detail/592209

2.Git 仓库目录 .git 详解,https://blog.csdn.net/nyist_zxp/article/details/109406589

也许您对下面的内容还感兴趣: