DevOps полезные советы по работе с Git
Рабочий каталог Git
Рабочий каталог Git — это каталог в вашей локальной файловой системе, в котором расположены файлы вашего проекта. Он содержит все файлы и папки вашего проекта, включая те, которые отслеживаются Git, и те, которые не отслеживаются.
Когда вы вносите изменения в свои файлы, создаете новые файлы или удаляете файлы, вы делаете это в рабочем каталоге. Рабочий каталог представляет текущее состояние файлов вашего проекта, которые, возможно, еще не зафиксированы в репозитории Git.
Рабочий каталог важен, потому что он позволяет вам вносить изменения, тестировать свой код и экспериментировать с новыми функциями, не затрагивая немедленно зафиксированную историю в вашем репозитории. Как только вы будете удовлетворены своими изменениями, вы можете подготовить их (добавить их в область подготовки), а затем зафиксировать их в репозитории, создав новый снимок истории вашего проекта.
Промежуточная область Git
Промежуточная область Git, также известная как индекс или кеш, представляет собой промежуточную область, в которой хранятся изменения в отслеживаемых файлах до того, как они будут зафиксированы в репозитории. Он служит способом организации и просмотра изменений, которые вы внесли в свой проект, перед созданием нового коммита.
Промежуточная область Git, также известная как индекс или кеш, представляет собой промежуточную область, в которой хранятся изменения в отслеживаемых файлах до того, как они будут зафиксированы в репозитории. Он служит способом организации и просмотра изменений, которые вы внесли в свой проект, перед созданием нового коммита.
Площадка позволяет:
- Выборочное добавление изменений: вы можете выбрать определенные изменения в вашем рабочем каталоге, которые будут подготовлены для следующего коммита, что позволит вам создавать целенаправленные и хорошо организованные коммиты.
- Просмотр изменений. Перед фиксацией вы можете просмотреть изменения в тестовой области, чтобы убедиться в их правильности и полноте.
- Изменение поэтапных изменений: если вы обнаружите, что вам нужно внести дополнительные изменения в промежуточный файл, вы можете изменить файл в рабочем каталоге и снова подготовить его, чтобы обновить промежуточную версию.
- Разделите изменения на несколько коммитов. Если вы внесли несколько изменений в свой проект, вы можете подготовить и зафиксировать их по отдельности, что поможет сохранить чистую и понятную историю коммитов.
Процесс использования промежуточной области обычно включает следующие этапы:
- Внесите изменения в файлы в рабочем каталоге.
- Внесите изменения с помощью
git add <file>
илиgit add -p
(для интерактивного размещения определенных изменений). - Просмотрите поэтапные изменения, используя
git status
илиgit diff --staged
. - Если вас устраивают изменения, зафиксируйте их с помощью
git commit -m "Commit message"
. Это создает новую фиксацию в репозитории с изменениями из промежуточной области.
Рабочий каталог Git для промежуточного процесса
Из приведенной выше диаграммы мы видим, что
- Разработчик вносит изменения в файлы в рабочем каталоге.
- Разработчик использует
git add <files>
для промежуточного хранения измененных файлов, перемещая их в промежуточную область. - Разработчик использует
git commit -m "Commit message"
для фиксации промежуточных файлов в репозиторий. - Разработчик использует
git checkout -- <files>
для отмены изменений в рабочем каталоге, если это необходимо. - Разработчик использует
git restore --staged <files>
для удаления файлов и перемещения их обратно в рабочий каталог, если это необходимо.
Git-индексный файл
.git/index
— это двоичный файл, расположенный в каталоге .git
вашего репозитория Git. Он представляет собой индекс Git (также известный как промежуточная область или кеш) и хранит информацию о файлах и их состояниях, которые будут включены в следующую фиксацию.
Файл .git/index
— это внутренняя структура данных, используемая Git для отслеживания различий между рабочим каталогом и репозиторием, помогая вам более эффективно управлять изменениями в файлах проекта. Он играет решающую роль в рабочем процессе Git, поскольку помогает поэтапно вносить определенные изменения, просматривать поэтапные изменения, модифицировать поэтапные изменения и разделять изменения на несколько коммитов.
Если вы напрямую откроете файл .git/index
, вы увидите следующее:
$ cat .git/index DIRCdK��20]dK��20]����������L�0U��������D�test.txtdK��+��WdK��+��W����������L�0U��������D�� test2.txt��]"�[�Fv���ә
Однако вы можете использовать команду git ls-files
для проверки:
$ git ls-files -s 100644 9daeafb9864cf43055ae93beb0afd6c7d144bfa4 0 test.txt 100644 9daeafb9864cf43055ae93beb0afd6c7d144bfa4 0 test2.txt
Команда «git ls-files» используется для вывода списка всех файлов, которые в настоящее время отслеживаются Git в репозитории. Эта команда отображает имена всех файлов в репозитории, включая те, которые находятся в рабочем каталоге, промежуточной области и зафиксированы в репозитории Git.
Как Git знает, что файл изменился
Git использует комбинацию методов для обнаружения изменений в файлах и определения того, какие файлы необходимо подготовить и зафиксировать в репозитории. Вот несколько ключевых механизмов, которые Git использует для обнаружения изменений:
- Временные метки: Git отслеживает время модификации каждого файла в рабочем каталоге. Когда вы изменяете файл, меняется его временная метка, и Git может использовать эту информацию, чтобы определить, был ли файл изменен.
- Хеширование содержимого: Git вычисляет значение хеш-функции для содержимого каждого файла в рабочем каталоге. Когда вы изменяете файл, меняется его хеш-значение, и Git может использовать эту информацию, чтобы обнаружить, что файл был изменен.
Когда вы запускаете команду «git status», Git сравнивает текущее состояние рабочего каталога с состоянием промежуточной области репозитория и историей фиксации, чтобы определить, какие файлы были изменены, добавлены или удалены. Затем эта информация отображается в выводе команды «git status», позволяя вам увидеть, какие файлы готовы к фиксации в репозитории.
Например, допустим, у нас есть два файла: file1.txt
и file2.txt
:
$ git ls-files -s 100644 a5bce3fd2565d8f458555a0c6f42d0504a848bd5 0 file1.txt 100644 180cf8328022becee9aaa2577a8f84ea2b9f3827 0 file2.txt $ tree .git/objects/ .git/objects/ ├── 18 │ └── 0cf8328022becee9aaa2577a8f84ea2b9f3827 ├── a5 │ └── bce3fd2565d8f458555a0c6f42d0504a848bd5 ├── info └── pack 4 directories, 2 files
Теперь давайте внесем некоторые изменения в file1.txt
:
$ echo "new test" > file1.txt $ $ git ls-files -s 100644 efbee594d27c2e2cfc9dcea464acc9904bc34a4d 0 file1.txt 100644 180cf8328022becee9aaa2577a8f84ea2b9f3827 0 file2.txt
Теперь вы можете видеть, что хэш file1.txt
изменился, а также папка объектов:
$ tree .git/objects/ .git/objects/ ├── 18 │ └── 0cf8328022becee9aaa2577a8f84ea2b9f3827 ├── a5 │ └── bce3fd2565d8f458555a0c6f42d0504a848bd5 ├── ef │ └── bee594d27c2e2cfc9dcea464acc9904bc34a4d ├── info └── pack
Теперь у нас есть объекты дерева, a5/
и ef/
принадлежат file1.txt
, а 18/
принадлежат file2.txt
.