Этапы жизненного цикла GIT

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

Рабочий каталог (Working directory)
Плацдарм (Staging area)
Каталог Git (Git directory)

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

Рабочий каталог

Рассмотрим проект, находящийся в вашей локальной системе. Этот проект может быть отслежен Git, а может и не отслеживаться. В любом случае этот каталог проекта называется рабочим каталогом.

Рабочий каталог — это каталог, содержащий скрытую папку .git.

примечание: git init – команда для инициализации репозитория Git

Для дальнейшего обсуждения предположим, что этот каталог теперь отслеживается Git. То есть мы создали репозиторий Git в этом существующем каталоге проекта. В этом состоянии Git просто знает о файлах в проекте. Он еще не отслеживает файлы. Чтобы отслеживать файлы, мы должны зафиксировать эти файлы, предварительно добавив их в промежуточную область. Это приводит нас к следующему состоянию в жизненном цикле Git.

Этапы жизненного цикла GIT: Плацдарм

Пока мы находимся в рабочем каталоге, мы выбираем файлы, которые должны быть отслежены Git. Зачем нам это нужно? Почему бы нам не отслеживать все в проекте? Это связано с тем, что некоторые файлы в проекте, такие как файлы классов, файлы журналов, файлы результатов и временные файлы данных, создаются динамически. Нет смысла отслеживать версии этих файлов. В то время как файлы исходного кода, файлы данных, файлы конфигурации и другие артефакты проекта содержат бизнес-логику приложения. Эти файлы должны отслеживаться Git, поэтому их необходимо добавить в промежуточную область.

Другими словами, промежуточная область — это площадка, где вы группируете, добавляете и организуете файлы, которые будут переданы в Git для отслеживания их версий.

Здесь важно быстро отметить термин, называемый индексацией. Индексирование — это процесс добавления файлов в промежуточную область. Другими словами, индекс состоит из файлов, добавленных в промежуточную область.

Примечание: git add — команда для добавления файлов в промежуточную область.

Каталог Git

Теперь, когда файлы, подлежащие фиксации, сгруппированы и готовы в промежуточной области, мы можем зафиксировать эти файлы. Итак, мы фиксируем эту группу файлов вместе с сообщением о фиксации (commit), объясняющим, что мы изменили. Помимо сообщения о фиксации, этот шаг также записывает автора и время коммита. Затем, моментальный снимок файлов фиксируется с помощью Git. Информация, связанная с этим коммитом (имена файлов, дата и время коммита, автор коммита, сообщение о коммите), хранится в каталоге Git.

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

примечание: git commit-m «ваше сообщение» — команда для фиксации файлов в репозиторий Git с сообщением.

Дополнительный этап жизненного цикла с Github

Имейте в виду, что мы изучаем жизненный цикл исключительно в Git. То есть важно отметить, что три стадии, рассмотренные выше, предназначены только для Git, а не для Github. Почему? Потому что вы можете отслеживать версии ваших файлов, используя только Git. То есть Github необходим, когда вы хотите сотрудничать и публиковать свой код в команде или сообществе. Таким образом, полезно помнить, что цикл Git обычно не включает Github.

Допустим, что мы работаем в командах и сотрудничаем с несколькими людьми над данным проектом. Это делает необходимым понять дополнительную стадию, связанную с Github. При работе с Github существует понятие удаленного хранилища и связанный с ним процесс, называемый Pushing the files.

Жизненный Цикл Git

Как видно на рисунке выше, после фиксации кода в локальном репозитории Git он должен быть перемещен в удаленный репозиторий. Здесь под удаленным репозиторием подразумевается зеркало или клон локального репозитория Git в Github. А push означает загрузку коммитов из локального репозитория Git в удаленный репозиторий, размещенный в Github. Это позволит другим сотрудникам просматривать код. Таким образом, любые изменения, внесенные вами в локальное хранилище Git, будут видны другим сотрудникам, когда вы переместите свой код в удаленное хранилище. Команда для отправки кода в удаленный репозиторий в Github — это git push.

Примечание: git push-команда для отправки коммитов из локального репозитория Git в удаленный репозиторий Git, размещенный в Github.

Необходимость в промежуточной области

Узнав об этих стадиях, можно, естественно, спросить – зачем нужна промежуточная зона? Почему мы не можем непосредственно зафиксировать код вместо того, чтобы сначала добавить его в промежуточную область? Давайте разберемся в причинах этого с помощью следующих моментов:

Быстрота. commit — это, по сути, ресурсоемкое взаимодействие с базой данных Git. Операции фиксации имеют тенденцию быть медленными. Однако в случае git, размещение файлов не требует взаимодействия с базой данных Git. Только когда файлы должны быть зафиксированы, Git проверяет наличие коммитов, сделанных другими пользователями. Таким образом, staging помогает записывать изменения еще до их фиксации в базе данных Git.

Визуализация фиксации перед фактической фиксацией. Как обсуждалось ранее, промежуточная область — это состояние, в котором находятся файлы до их фиксации. То есть промежуточная область фактически позволяет визуализировать группу изменений, которые будут записаны Git. По сути, это дает вам четкий контроль над тем, что попадает в Git, а что нет.

Разделение работы на отдельные связанные коммиты. Кроме первого коммита, когда все файлы проекта фиксируются одновременно, вы должны записывать (делать снимок проекта) через регулярные промежутки времени. То есть предположим, что вы работаете над новой функцией, срок разработки которой составляет несколько дней. Таким образом, пока вы работаете над функцией, вам необходимо выполнить рефакторинг небольшой части кода. В этом случае вы можете быстро внести необходимые изменения, создать необходимый файл и возобновить работу над функцией. Все изменения, т. е. изменения функций и рефакторинг кода могут быть зафиксированы сразу из промежуточной области.

Git Pull