#Git под капотом
« Git — это современная распределенная система управления версиями, помогающая разработчикам или всем, кто хочет отслеживать изменения в своей файловой системе». Мы можем назвать ее временной шкалой нашего проекта от начала до конца».
Как инженеры-программисты, многие из нас используют Git, лишь немногие знают точное внутреннее устройство или то, что происходит под капотом.
что происходит внутри, когда вы делаете изменение файла и фиксируете его?
Как git отслеживает все изменения, произошедшие с файлом?
Иногда вы можете столкнуться с проблемами, которые вы не будете знать, как решить, не понимая, как git работает в бэкэнде.
В этой статье я делюсь глубоким пониманием того, как Git работает под капотом, на простых примерах.
Примечание. Эта статья предназначена для понимания того, как git работает с низкоуровневыми командами и что происходит за кулисами. Это не руководство по работе с Git
Инициализировать репозиторий Git
Начнем с инициализации репозитория Git с помощью команды git init.
Он создает скрытую папку с именем .git, которая содержит различные файлы и папки внутри.
Эта папка содержит всю информацию и конфигурацию, необходимые для git для контроля версий. Здесь мы в основном сосредоточены на папке объектов, где она будет содержать информацию об отслеживании нашей файловой системы.
Git 3 состояния или состояния репозитория
Рабочее состояние — когда вы что-то добавляете, удаляете или изменяете в файле. Git заметит изменение, но вы не будете заранее сообщать Git, чтобы сохранить изменения. Традиционно это «Неотслеживаемые/не поэтапные изменения».
Промежуточное состояние — это когда вы сообщаете Git об изменении и просите Git принять к сведению это изменение. Обычно известна как Промежуточная область. Промежуточные изменения можно внести с помощью команды git add. Изменение файла можно выполнить даже после его подготовки, что позволяет видеть файл как в рабочем состоянии, так и в состоянии подготовки.
Этап фиксации — это этап, на котором Git сохранил изменения вашего рабочего состояния в папке .git в форме объектов git. Традиционным способом это достигается с помощью команды git commit.
Здесь давайте посмотрим на Git Internals/За кулисами Как Git хранит изменения
Git — это файловая система с адресацией по содержимому или простая файловая система данных с ключом и значением. Это означает, что если вы вставите какой-либо контент в Git, он вернет вам уникальный ключ, чтобы вы могли использовать его позже для извлечения контента.
Уникальный ключ — это не что иное, как безопасный хэш-алгоритм (SHA-1), представляющий собой криптографическую хеш-функцию, которая принимает входные данные и создает 160-битный (20-байтовый) хеш-значение, обычно отображаемое как шестнадцатеричное число длиной 40 цифр*.*
Используя эту хэш-функцию, мы можем ссылаться на любое содержимое файла, коммиты и т. д.
Однократное изменение содержимого приведет к другому значению хэша/генерации уникального ключа.
Каждое сгенерированное значение хэша будет связано с объектами git в Git, чтобы понять изменения, внесенные разработчиком на рабочем этапе, чтобы сохранить его на этапе фиксации.
Теперь пришло время Git Objects. Файловая система Git использует 4 типа объектов git. Это единственные типы объектов, необходимые git для сохранения необходимых данных.
- Blob — любой тип файлов, будь то фото, видео или файлы с любыми расширениями, хранится в виде большого двоичного объекта.
- Дерево — информация о каталогах хранится в виде дерева. Дерево может содержать набор BLOB-объектов и даже может содержать набор деревьев с BLOB-объектами. Дерево — это представление папки/каталога в Git.
- Commit — с помощью типа объекта фиксации вы можете сохранять разные версии нашего проекта.
- Аннотированный тег — фактически постоянный текстовый указатель на конкретную фиксацию.
Давайте создадим образец файла с именем gitsample.txt. давайте подготовим и зафиксируем его и посмотрим, как файл хранится в папке .git как типы объектов.
Согласно приведенному выше объяснению, при фиксации файла будет создано три типа объектов.
Большой двоичный объект для хранения содержимого, дерево с информацией о последнем большом двоичном объекте, созданном при создании/изменении файла, а затем тип объекта Commit, содержащий информацию о последнем созданном дереве.
Такая иерархия может быть принята для типов объектов.
Действия для воспроизведения описанного выше сценария
- Создайте файл с именем gitsample.txt внутри репозитория git. Сохраните «Hello World» внутри файла
- Запустите команду git status в git bash, указав папку git repo. Как мы ранее обсуждали, измененный/созданный файл будет находиться в рабочем состоянии или также известен как неотслеживаемые изменения, поэтому теперь здесь gitsample.txt будет отображаться как неотслеживаемое изменение.
- Следующий шаг — перевести файл из рабочего состояния в промежуточное, выполнив команду git add . Запустите git status после этой команды. gitsample.txt будет перемещен в состояние подготовки.
Еще одна вещь, на которую следует обратить внимание: в папке .git/objects будет создан новый объект blob с уникальным ключом/ключом SHA 1 в качестве имени файла. Первые 2 цифры хеш-ключа будут использоваться для имени папки.
Сочетание имени папки и имени файла будет хэш-ключом файла gitsample.txt. поэтому хэш-ключ будет 3ee2d77fee2bc1ac806a945df84ad530a5de6fd8
- Чтобы убедиться в этом, запустите низкоуровневую команду git git cat-file -p. Это должно получить содержимое «Hello World», используемое в gitsample.txt.
- Затем из состояния Staging его следует перевести в состояние Committed,
Чтобы зафиксировать, нам нужно запустить команду git commit -m «Initial Commit».
- Когда изменения перемещаются в зафиксированное состояние, он создает два других объекта Tree и объект фиксации.
Дерево также будет иметь свой собственный новый хеш-ключ, и оно будет содержать имя файла и хэш-ключ объекта BLOB-объекта, созданного во время подготовки.
У фиксации также будет сгенерирован собственный хеш-ключ, и он будет содержать хэш-ключ объектов дерева, который был недавно создан, и сообщение фиксации.
Чтобы убедиться, что это дерево и объекты фиксации, запустите низкоуровневую команду git cat-file, используя расширение -t и соответствующие хеш-ключи. Он покажет тип объекта
- С этими изменениями объекта в папке .git/objects файл HEAD в папке .git/refs будет иметь имя ветки имени файла master с последним хэш-ключом фиксации внутри него.
Что происходит, когда есть изменение в том же файле и оно зафиксировано?
- Снова повторяется тот же процесс, который создает новый большой двоичный объект, коммит и дерево со своими собственными хеш-ключами.
- Commit будет содержать информацию о предыдущем ключе фиксации.
Что происходит, когда создается и проверяется новая ветвь?
- Папка .git/refs/HEAD будет иметь другой файл с именем ветки и последним хэш-ключом коммита, полученным из родительской ветки.
- HEAD в папке .git будет указывать на эту ветку.
Подведение итогов
Я надеюсь, что эта статья даст вам четкое представление о том, как Git работает с фоновыми сценами. И, надеюсь, после прочтения этой статьи вы узнаете о наиболее важных частях git.
Если вы дошли до этого момента, спасибо за чтение. Меня зовут Абилаш С. Вы можете проверить мои последние сообщения о технологиях на этих платформах. Не стесняйтесь подключаться на любой из этих платформ
CodeHunt Channel Youtube Abi Aradhya — Medium JavaScript недоступен.
Первоначально опубликовано на https://dev.to 3 октября 2022 г.