Вы когда-нибудь задумывались, для чего, черт возьми, папка .git? Вы этого не сделали? Без проблем. Сегодня мы рассмотрим это подробнее !!

Попутно мы получим обзор системы хранения и поймем, почему фраза «ветвь - это просто указатель» имеет смысл.

Повестка дня

  • .git что ???
  • Структура папки .git
  • Заключение

.git что ???

Вы, наверное, уже знаете, что если вы хотите создать репозиторий git, вам нужно ввести git init в свой терминал. Но знаете ли вы, что в этот момент автоматически создается новая папка .git? Когда вы посмотрите в каталог своего проекта, вы найдете их.

Git хранит все там. Если мы заглянем внутрь, то увидим множество файлов и папок. На первый взгляд это может показаться запутанным, но не волнуйтесь, мы рассмотрим все шаг за шагом.

Структура папки .git

Во-первых, ваша папка может содержать дополнительные файлы и папки. Это потому, что есть еще несколько файлов и папок, помимо показанных выше. Однако вверху вы можете увидеть все те, которые обычно появляются при создании репозитория git. Итак, начнем с каталога объектов.

объекты

Когда мы открываем его, мы видим только папку с информацией и пакетами. Но позже будет добавлено еще много каталогов. Git хранит в нем все подготовленные файлы.

Но это не единственное. Позже мы рассмотрим еще два типа, которые хранятся в папке объектов. В целом можно сказать, что это то, что мы обычно называем хранилищем базы данных. Вернитесь в папку нашего проекта и введите в консоли следующую строку:

echo 'test' >> test.txt
git add test.txt

Сначала мы создаем новый файл test.txt с содержимым test. Затем мы добавляем его в область подготовки.

Не знаете, что такое плацдарм? Сделайте перерыв и прочитайте мою предыдущую статью Git the three worlds system. Здесь я кратко объясню три различных области в Git.

Теперь мы можем вернуться в папку .git / objects.

Вы увидите новый каталог. Git хранит все в хэш-значении 160-бит. Представляется как 40-значное шестнадцатеричное число. Вы, вероятно, задаетесь вопросом: «Подождите. Я вижу только два шестнадцатеричных числа. А где остальные? ». Git использует первые два символа каждого хэша для создания папки, содержащей файл, имя которого состоит из последних 38 символов. Таким образом, вы видите только первые два символа каждого хеша. Git делает это, чтобы ускорить работу системы памяти. Но все 40 цифр являются ключевыми, а значение - содержимым файла. Чтобы проверить хеш, мы можем ввести:

git cat-file -p 9daeafb9864cf43055ae93beb0afd6c7d144bfa4

-p позволяет нам видеть все изменения файлов. В нашем случае вы видите только «тест». Хеш зависит от изменений и метаданных, поэтому ваш хеш будет другим. Если мы хотим связать его с локальной историей git, нам нужно сделать коммит. Давайте сделаем это.

git commit -m "feat: Create a test.txt file with the content test"

Поэтому мы создали нашу первую фиксацию. Вернитесь в папку .git / objects и введите ls -la. У вас должно быть такое же количество каталогов, как показано ниже.

Были созданы две новые папки. Но почему два новых каталога? Мы продвигаем только одну фиксацию. Давайте проанализируем их и посмотрим, к какому типу относится каждый объект. Чтобы получить тип объекта, мы заменяем -p на -t в команде git cat-file.

our tracked changes
---------
git cat-file -t 9daeafb9864cf43055ae93beb0afd6c7d144bfa4
// blob
new commit
-----------
git cat-file -t 2b297e643c551e76cfa1f93810c50811382f9117
// tree
git cat-file -t b9ca915ed5e9507d44dbfaebc8a64b0f2ba52649
// commit

Теперь мы видим, что хэш 2b… хранит что-то под названием tree, а хэш 05… хранит что-то под названием commit. . Чтобы получить более подробное представление, мы должны глубже погрузиться в систему памяти git. Но я думаю, это было бы чересчур. Подробнее об этом мы поговорим в следующей статье. На данный момент, чтобы лучше ориентироваться, мы можем сказать, что blob хранит только контент. В дереве хранится дополнительная информация, например, к какому файлу принадлежит содержимое и что это за файл, и, наконец, фиксация фиксирует изменения в истории.

реф.

Ниже вы можете увидеть структуру папки refs. В нем мы находим два подкаталога. Каталог голов содержит все ветки, а каталог тегов - все закладки из истории.

Heads
Начнем с главного каталога. Заглянув внутрь, мы обнаружим файл под названием master. Он содержит ссылку на последнюю фиксацию - ›b9ca915ed5e9507d44dbfaebc8a64b0f2ba52649.

Но что это значит? Ветви - важная часть git. Каждая ветвь полностью независима от всех остальных.

Если вы хотите узнать больше о ветвях, прочтите мою статью Основы git.

Как только мы создадим новую ветку под названием second_branch и заглянем в каталог Heads, мы найдем второй файл с тем же именем, что и наша новая ветка.

Файл содержит ту же ссылку, что и мастер файла. Теперь мы создаем новый коммит в нашей second_branch и снова отображаем содержимое обоих файлов.

master
---------
b9ca915ed5e9507d44dbfaebc8a64b0f2ba52649
second_branch
-----------
c225e0c7175b7467eb6cc5f283413b2eee027ff3

У мастера ветки по-прежнему есть ссылка - ›b9ca915ed5e9507d44dbfaebc8a64b0f2ba52649, тогда как second_branch теперь имеет ссылку на нашу новую фиксацию.

Подводя итог, можно сказать, что когда вы создаете ветку, в каталоге голов автоматически создается новый файл с таким же именем со ссылкой из текущего коммита. Каждый раз, когда вы создаете новую фиксацию, ссылка, содержащая файл, изменяется.

Итак, ветки - это просто указатель .

теги
Есть два разных типа закладок. Каждый из них хранится в каталоге Теги. Первый известен как легковесные теги и является ссылкой только на фиксацию, как и файлы в каталоге Heads. Второй называется аннотированный тег и хранит гораздо больше информации. Ниже приводится их краткий список:

  • имя теггера
  • Эл. адрес
  • Дата
  • сообщение с тегами

В большинстве случаев рекомендуется использовать аннотированные теги, но это зависит от ситуации.

ГОЛОВА

ГОЛОВА быстро объясняется. Это ссылка на активную ветку. Итак, git знает, какая ветка сейчас используется. Чтобы узнать, что содержится в нашем файле головы, введите cat HEAD.

Информация

В каталоге info мы находим дополнительную информацию о нашем репозитории. Один из самых известных файлов - это файл исключения. Он решает, какой шаблон будет проигнорирован. Чтобы определить игнорируемые файлы и папки, мы используем файл в нашем проекте с именем .gitignore.

config

Файл конфигурации, как следует из его названия, хранит конфигурацию вашего репозитория. Вы можете определить конфигурацию глобально для всех репозиториев или локально. В этом случае он используется только для вашего локального репозитория. Ниже приведены несколько конфигураций, которые вы можете установить в файле конфигурации. Чтобы увидеть полный список, посетите страницу конфигурации git.

  • имя
  • Эл. адрес
  • редактор
  • исключить файлы
  • автокоррекция
  • …

описание

Здесь вы можете создать краткое описание вашего репозитория. Но это не имеет значения, если вы не используете gitweb.

крючки

Есть несколько предопределенных функций git, которые выполняются при определенных событиях. В каталоге хуков мы можем увидеть несколько из них. Примером события может быть завершение всего процесса фиксации.

Выше приведен пример списка хуков из моего репозитория руководств. К названию каждого из них добавлено слово образец. Это гарантирует, что все перехватчики отключены в начале. Если вы хотите включить функцию, вам просто нужно удалить слово образец. Вы также можете редактировать или писать свои собственные хуки git. Нажмите сюда, для получения дополнительной информации".

Заключение

Вот и все. Сегодня мы вместе обнаружили папку .git. В конце концов, вы должны знать, какие файлы / папки вы обычно находите в каталоге .git и что они делают. Кроме того, мы получаем обзор хранилища git и понимаем, почему фраза «ветвь - это просто указатель» имеет смысл. Надеюсь, статья была полезна для более глубокого понимания Git и папки .git. Если у вас есть вопросы или отзывы, дайте мне знать в комментариях.

В моей следующей статье мы рассмотрим, как работает git с памятью. Что ж, до скорой встречи.