Общие сведения о журнале 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, где новые ветви тяжелые и редко создаются. Первым шагом является проверка out в новую ветвь с помощью следующей команды:

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, который более тесно похож на код в активной разработке в команде. Существует три человека, которые объединяют фиксации из своих собственных ветвей в основную ветвь примерно в то же время.

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