Понимание истории Git

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

Примечание.

Если вы не можете найти изменение в истории Git, в котором вы уверены, что сделали, узнайте больше о том, как работает упрощение истории в Git на Git потерял мои изменения: упрощение истории Git.

Основы истории коммитов

Начните с простого примера истории: репозиторий с 3 последовательными коммитами.

Commit A является родителем коммита B, а коммит B является родителем коммита C. Эта история очень похожа на CVCS. Стрелка, указывающая на коммит C, это ветка. Оно называется main, так как это имя по умолчанию для ветви mainline в репозитории Git. Ветви — это указатели на определенные коммиты, поэтому ветвление в Git такое легковесное и простое.

Ключевое различие в Git по сравнению с CVCS заключается в том, что у меня есть собственная полная копия репозитория. Мне нужно поддерживать локальный репозиторий в синхронизации с удаленным репозиторием, получив последние коммиты из удаленного репозитория. Для этого я вытащим основную ветвь со следующей командой:

git pull origin main

Копируются все коммиты из ветки main удаленного репозитория (по умолчанию называемой origin) в ветку main локального репозитория. Операция извлечения скопировала одну новую фиксацию, а ветвь main в локальном репозитории теперь указывает на эту новую фиксацию.

Понимание истории ветки

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

git checkout -b cool-new-feature

Это сочетание двух команд: сначала git branch cool-new-feature для создания ветви, а затем git checkout cool-new-feature для начала работы в этой ветви.

Теперь две ветви указывают на один коммит. Я внесу несколько изменений в ветку cool-new-feature в двух новых коммитах, E и F.

Мои коммиты доступны из ветки cool-new-feature, так как я сделал их в этой ветке. Я закончил со своей функцией и хочу объединить её в main. Для этого я буду использовать следующую команду:

git merge cool-feature main

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

История в реальном мире

Ниже приведен пример истории Git, который более тесно похож на код в активной разработке в команде. Есть три человека, которые объединяют коммиты из своих веток в основную ветку примерно в одно и то же время.

Теперь, когда вы понимаете, как ветви и слияния создают форму графа, это не должно быть слишком страшно!