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

Git представляет историю принципиально иначе, чем централизованные системы управления версиями (CVCS), такие как Team Foundation Version Control, Perforce или Subversion. Централизованные системы хранят отдельную историю для каждого файла в репозитории. Git сохраняет историю как граф моментальных снимков всего репозитория. Эти моментальные снимки, называемые фиксациями в Git, могут иметь несколько родителей, создавая историю, которая выглядит как граф, а не прямая линия. Эта разница в истории невероятно важна и является основной причиной, по которой пользователи, знакомые с CVCS, находят Git запутанным.

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

Начните с простого примера истории: репозиторий с тремя линейными фиксациями.

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

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

git pull origin main

Это объединяет все изменения из основной ветви в удаленном репозитории, которую по умолчанию Git называет origin. Этот запрос принес одну новую фиксацию и основную ветвь в локальном репозитории перемещается к этой фиксации.

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

Теперь пришло время внести изменения в код. Обычно при работе с различными функциями параллельно работают несколько активных ветвей. Это резко контрастирует с 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 ветви, так как они были зафиксированы в этой ветви. Теперь, когда эта функция выполнена, ее необходимо объединить в основную ветвь. Для этого используйте следующую команду:

git merge cool-new-feature main

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

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

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

Дальнейшие шаги

Дополнительные сведения о работе с историей Git в GitHub и Azure Repos или упрощением истории коммитов Git.