Git on kenji.blog

【Команды Git】Разница между 'rebase' и 'merge', и их правильное использование на практике

Sun, 13 Sep 2026 09:00:00 +0900

1. Введение: почему выбор между «merge» и «rebase» — это вечная проблема

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

В этой статье мы подробно рассмотрим различия в механизмах работы git merge и git rebase, начиная с внутренней структуры Git — DAG (направленного ациклического графа) и математических свойств хешей коммитов. Затем мы тщательно объясним, как правильно использовать их на практике, сопровождая это конкретными рабочими процессами. Понимая не только сами команды, но и то, какие вычисления Git выполняет «под капотом», вы избавитесь от страха перед конфликтами и сможете создавать чистую, легко отслеживаемую историю.

2. Внутренняя структура Git: хеши коммитов и объектная модель

Чтобы понять, как Git интегрирует историю, сначала нужно узнать, как он хранит данные. Git не просто сохраняет различия (патчи) изменений файлов; он сохраняет снимки всей файловой системы на определенный момент времени.

2.1 Криптографические свойства хешей коммитов

Каждый коммит в Git однозначно идентифицируется 40-значным шестнадцатеричным числом, вычисленным на основе его содержимого с помощью хеш-функции SHA-1 (Secure Hash Algorithm 1). Объект коммита состоит из следующих элементов:

Указатель на объект Tree: снимок структуры каталогов и файлов (Blob) на тот момент времени.
Указатель на родительский коммит: хеш-значения одного или нескольких родительских коммитов (первый коммит не имеет родителя, а коммит слияния имеет два или более родителей).
Информация об авторе (Author): кто написал код и когда.
Информация о коммитере (Committer): кто создал и применил коммит, и когда.
Сообщение коммита: текст, объясняющий цель изменений.

В математическом выражении хеш-значение $H(C)$ для объекта коммита $C$ определяется следующим образом:

$$ H(C) = \text{SHA-1}( \text{tree} \parallel \text{parent} \parallel \text{author} \parallel \text{committer} \parallel \text{message} ) $$

Здесь $\parallel$ обозначает конкатенацию данных. Из-за свойств хеш-функции изменение даже одного символа в сообщении коммита или другой родительский коммит приведут к генерации совершенно иного хеш-значения. Это означает, что коммиты неизменяемы (Immutable). Когда говорят, что rebase «переписывает историю» (о чем пойдет речь позже), на самом деле это означает создание новых коммитов с похожим содержимым, но с другими хеш-значениями.

Размер хеш-пространства составляет $2^{160}$, и вероятность коллизии (когда разные коммиты имеют одинаковое хеш-значение) $P$ можно приблизительно вычислить, используя парадокс дней рождения (Birthday Paradox), следующим образом (где $n$ — количество коммитов):

$$ P(\text{collision}) \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{160}}\right) $$

Эта вероятность крайне мала, и на практике коллизия хешей коммитов Git практически невозможна.

3. Теория графов и DAG: математическая модель истории Git

История коммитов Git моделируется как «направленный ациклический граф» (Directed Acyclic Graph, DAG) в теории графов.

3.1 Что такое DAG (направленный ациклический граф)

В графе $G = (V, E)$, $V$ — это множество коммитов (вершин), а $E$ — множество направленных ребер, указывающих на отношения родитель-ребенок между коммитами. В Git ребра направлены от «дочернего коммита к родительскому коммиту». Это связано с тем, что новые коммиты хранят указатели на предыдущие коммиты.

graph BT
A["Коммит A (Начальный)"]
B["Коммит B"]
C["Коммит C (Main)"]
D["Коммит D (Feature)"]
E["Коммит E (Merge)"]
B --> A
C --> B
D --> B
E --> C
E --> D

Главной особенностью DAG является «отсутствие циклов». Благодаря этому алгоритмы обхода истории коммитов никогда не попадают в бесконечный цикл и гарантированно достигают конца (начального коммита).

3.2 Топологическая сортировка и порядок истории

При отображении истории, например, с помощью команды git log, DAG упорядочивается в одномерный список с использованием алгоритма топологической сортировки (Topological Sort). Для любого направленного ребра $u \to v$ в DAG ($u$ является потомком $v$), элементы сортируются так, чтобы $u$ находился перед $v$ в списке.

4. Механизмы и типы git merge

git merge — это самая базовая команда для интеграции изменений из веток. Однако, в зависимости от текущего состояния, Git автоматически выбирает разные стратегии слияния.

4.1 Слияние Fast-Forward (–ff)

Если целевая ветка (например, main) является прямым предком исходной ветки (например, feature), Git выполняет слияние «Fast-Forward» (перемотка вперед). Это операция, при которой новые коммиты не создаются, а просто указатель ветки перемещается вперед.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature

Слияние Fast-Forward сохраняет историю линейной, но имеет тот недостаток, что теряется контекст: «какие коммиты были сгруппированы как разработка одной функции (feature)».

4.2 Слияние Non-Fast-Forward (–no-ff)

Если явно указать git merge --no-ff, Git обязательно создаст новый «коммит слияния», даже если возможен Fast-Forward. Коммит слияния — это специальный коммит, имеющий двух родителей.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
commit id: "Main Work 1"
merge feature type: NORMAL

Преимущество этого метода в том, что существование и история функциональной ветки четко остаются в DAG. При возникновении проблем можно выполнить git revert -m 1 <хеш коммита слияния>, чтобы безопасно отменить (revert) всю функцию целиком за один раз.

4.3 Алгоритм трехстороннего слияния (3-Way Merge)

Если целевая и исходная ветки имеют свои собственные коммиты, Git выполняет трехстороннее слияние. При этом Git исследует DAG и находит «наименьшего общего предка» (Lowest Common Ancestor, LCA) двух веток.

Вычислительная сложность алгоритма поиска LCA, $T_{\text{LCA}}$, выполняется за линейное время относительно количества вершин $|V|$ и ребер $|E|$:

$$ T_{\text{LCA}} = \mathcal{O}(|V| + |E|) $$

Git сравнивает три состояния: «состояние LCA», «состояние текущей ветки» и «состояние другой ветки», и, если изменения не конфликтуют, автоматически генерирует коммит слияния.

5. Механизм git rebase и реконструкция истории

В то время как git merge «интегрирует» историю, git rebase «реконструирует» (перебазирует) её.

5.1 Что происходит за кулисами Rebase

Внутренняя работа при ребейзе ветки feature на ветку main (git rebase main) выглядит следующим образом:

Найти общего предка (LCA) веток feature и main.
Сохранить разницу коммитов от LCA до конца ветки feature во временную область.
Переместить указатель ветки feature на конец ветки main.
Последовательно применить сохраненные изменения (Cherry-Pick) поверх новой базы (конца main), создавая новые коммиты.

graph TD
A["Коммит A"] --> B["Коммит B"]
B --> C["Коммит C (Main)"]
B --> D["Коммит D (Старая ветка Feature)"]
D -.-> E["Коммит D' (Новая ветка Feature)"]
C --> E
style D stroke-dasharray: 5 5, fill: #f9f9f9, color: #999

Здесь важно отметить, что коммит $D'$, созданный в результате ребейза, имеет совершенно другой хеш, потому что у него другой родительский коммит, в отличие от исходного коммита $D$ (см. определение хеш-функции $H(C)$ выше).

5.2 Интерактивный ребейз (Interactive Rebase)

Использование git rebase -i (или --interactive) позволяет вам управлять историей коммитов по своему усмотрению. Это самый мощный инструмент для очистки локальной истории.

pick : использовать коммит как есть
reword : изменить только сообщение коммита
edit : приостановить ребейз для изменения содержимого коммита
squash : объединить этот коммит с предыдущим, а также объединить их сообщения
fixup : то же, что и squash, но сообщение этого коммита отбрасывается
drop : полностью удалить коммит

С математической точки зрения, если в ветке есть $N$ коммитов, количество возможных вариаций линейной истории (перестановок) $P$, генерируемых путем изменения порядка при ребейзе, выглядит следующим образом:

$$ P = N! $$

Git предоставляет разработчикам $N!$ степеней свободы, позволяя поддерживать историю в логичном и красивом состоянии.

6. Золотое правило ребейза (The Golden Rule of Rebase)

Команда rebase очень мощная, но существует одно абсолютное правило.

«Никогда не выполняйте ребейз публичной истории» (Never rebase public history)

6.1 Почему нельзя делать ребейз публичной истории?

Git — это распределенная система. Коммиты, которые вы запушили в origin/main, клонируются (копируются) в локальные репозитории других разработчиков. Что произойдет, если вы сделаете ребейз уже запушенных коммитов, перепишете историю и принудительно перезапишете её с помощью git push --force?

Локальный DAG у других разработчиков и удаленный DAG кардинально разойдутся. Когда другой разработчик выполнит git pull, Git попытается принудительно слить группы коммитов с разной историей, что приведет к огромному количеству конфликтов и дублирующихся коммитов (коммитов с одинаковыми изменениями, но разными хешами), повергая репозиторий в состояние паники.

Железное правило гласит: ребейз следует применять только к «локальным веткам, которыми вы еще ни с кем не поделились».

7. Разрешение конфликтов и git rebase –continue

Конфликт возникает, когда несколько человек изменяют одно и то же место в одном и том же файле. Процесс разрешения конфликтов в merge и rebase отличается.

7.1 Разрешение конфликтов в Merge

В случае с git merge разрешение конфликтов происходит только один раз. Все конфликтующие участки исправляются за один раз, прямо перед созданием финального коммита слияния.

7.2 Разрешение конфликтов в Rebase

В случае с git rebase, из-за природы повторного применения коммитов один за другим, существует вероятность возникновения конфликта на каждом коммите.

Если во время ребейза возникает конфликт, Git приостанавливает процесс. Порядок разрешения следующий:

Открыть редактор или IDE (например, VS Code) и вручную исправить маркеры конфликтов (<<<<<<<, ======, >>>>>>>).
Добавить исправленный файл в индекс:
1

git add <исправленный файл>
Не создавая коммит, возобновить процесс ребейза:
1

git rebase --continue

Если вы хотите прервать ребейз и вернуться к исходному состоянию, выполните следующую команду:

1

git rebase --abort

(※Если разрешение конфликта не требуется, и вы хотите полностью пропустить этот коммит, используйте git rebase --skip)

8. Правильное использование на практике (практика рабочих процессов)

Итак, как же правильно выбирать между merge и rebase в реальной разработке? Здесь мы представим самый стандартный и безопасный подход.

8.1 【Сценарий 1】Очистка локальной истории (использование Rebase)

Предположим, что во время разработки в функциональной ветке накопилось много мелких коммитов (таких как «исправление опечатки», «временное сохранение» и т. д.). Перед созданием Pull Request (PR) вы используете интерактивный ребейз, чтобы организовать их в осмысленные блоки.

1
2
3


# Выполнить, находясь в ветке feature
git rebase -i HEAD~5
# (Откроется редактор, используйте squash и fixup для очистки истории)

Это позволяет создать красивую историю коммитов, где намерения будут понятны ревьюерам.

8.2 【Сценарий 2】Следование за новейшей веткой main (использование Rebase)

Если разработка затягивается, и чужие изменения постоянно сливаются в main, ваша ветка feature устаревает. В этом случае вы делаете ребейз ветки feature на самую свежую main, чтобы не отставать.

1
2
3
4
5


# Получить новейшую информацию о main
git fetch origin

# Перебазировать ветку feature поверх свежей main
git rebase origin/main

В результате история становится линейной, что помогает избежать конфликтов при последующих слияниях. Кроме того, это предотвращает создание лишних коммитов слияния (например, “Merge branch ‘main’ into feature”).

8.3 【Сценарий 3】Интеграция завершенной функции (использование Merge)

Разработка в ветке feature завершена, и настал этап интеграции в ветке main. Здесь используется git merge --no-ff (это эквивалентно выбору «Create a merge commit» в Pull Request на GitHub и т.д.).

1
2
3


git checkout main
git merge --no-ff feature -m "Merge feature: Реализация функции входа пользователя"
git push origin main

Благодаря этому в DAG ветки main останется исторический узел (коммит слияния), показывающий: «здесь была слита одна функция». При просмотре истории в будущем это облегчит отслеживание кода по функциональным блокам.

9. Заключение (итоги)

В работе с Git крайние подходы, такие как «решать всё только через Merge» или «делать всё линейным только через Rebase», имеют свои плюсы и минусы.

Лучшая практика в реальной работе — это гибридный подход: «красиво организовывать локальную приватную историю с помощью rebase, а публичную историю интеграции сохранять с контекстом через merge –no-ff».

Локально (личное рабочее пространство): используйте rebase для устранения лишних коммитов и поддержания линейной истории, следуя за актуальной основной линией.
Глобально (общее рабочее пространство): используйте merge --no-ff для записи существования функциональной ветки в DAG в виде коммита слияния, что облегчает реверт и отслеживание.

Понимая математические и архитектурные основы, такие как структура DAG и механизмы хеш-функций, команды Git превращаются из простого заучивания в «проектирование истории с определенным намерением». Соблюдая золотое правило ребейза и выбирая оптимальные команды в зависимости от ситуации, давайте создавать чистую, легко читаемую и поддерживаемую историю коммитов для всей команды.

Распространенные ошибки новичков в Git и команды для их решения (разрешение конфликтов и др.)

Sat, 12 Sep 2026 17:00:00 +0900

Распространенные ошибки новичков в Git и команды для их решения (разрешение конфликтов и др.)

1. Введение: Почему мы совершаем ошибки в Git?

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

Почему Git кажется таким сложным и так часто провоцирует ошибки? Главная причина заключается в том, что «люди заучивают и используют поверхностные команды, не понимая, что происходит внутри Git». Git основан на надежной архитектуре распределенной системы контроля версий (DVCS), но его интерфейс командной строки (CLI) далеко не всегда интуитивно понятен.

В этой статье мы подробно разберем множество «косяков (типичных ошибок)», с которыми новички часто сталкиваются на практике, классифицируем их и предложим конкретные команды для их решения. Но это не будет просто еще одной шпаргалкой с набором команд. Мы глубоко погрузимся в суть проблемы: «почему возникает эта ошибка» и «как именно перемещаются данные внутри Git при выполнении этой команды». Наш материал объемом более 10 000 символов будет включать анализ структуры директории .git, математическую основу алгоритма Diff, работающего в фоновом режиме, а также визуализации с помощью Mermaid.

Прочитав эту статью до конца, вы избавитесь от чувства «страха перед Git» и вместо этого обретете уверенность в том, что «нет более надежного напарника, чем Git». Итак, давайте погрузимся в бездну мира Git.

2. Бездна Git: Понимание внутренней структуры директории `.git`

Первый шаг к облегчению устранения неполадок — узнать, как Git хранит данные. Скрытая папка .git, находящаяся в корневой директории вашего проекта, является сердцем Git. Git не просто последовательно записывает изменения (патчи) файлов; он управляет данными как потоком снимков состояния (снапшотов).

2.1 Объектная модель: Blob, Tree, Commit

Git в основном использует 3 типа объектов для представления состояния репозитория. Эти объекты хранятся в .git/objects.

Blob (Binary Large Object) Объект, который хранит само содержимое файла. Он не содержит имени файла или информации о правах доступа. Это просто чистый набор байтов, сжатый с помощью zlib, который идентифицируется по хэшу SHA-1 (40 символов в шестнадцатеричном формате).
Tree (Дерево) Объект, представляющий структуру директорий. Объект Tree содержит указатели (хэши SHA-1) на другие объекты Tree (поддиректории) или объекты Blob (файлы), а также их имена и права доступа. Он выполняет роль, аналогичную директории в UNIX.
Commit (Коммит) Содержит указатель на корневой объект Tree всего репозитория в определенный момент времени, метаданные (автор, дата создания, сообщение коммита), а также указатель на предыдущий коммит (родительский коммит).

graph TD
Commit1["Коммит (Хэш: 9f8a)"] --> Tree1["Дерево (Хэш: 4b82)"]
Tree1 --> Blob1["Blob-объект (Хэш: 8d7e) : index.js"]
Tree1 --> Tree2["Дерево (Хэш: 3a2c) : src/"]
Tree2 --> Blob2["Blob-объект (Хэш: 5f1b) : app.js"]

2.2 Истинная сущность HEAD и ссылок (Refs)

При работе с Git вы часто будете встречать слово HEAD. Это символическая ссылка (Symbolic Reference), которая указывает на текущую извлеченную (checked out) ветку (или коммит). Если вы откроете файл .git/HEAD в текстовом редакторе, то увидите строку, похожую на эту:

1

ref: refs/heads/main

Это означает, что «текущее состояние находится на острие ветки main». А если вы откроете файл .git/refs/heads/main, там будет записан хэш SHA-1 из 40 символов, который указывает на последний объект Commit. Ветка в Git — это просто легковесный указатель (файл), указывающий на конкретный коммит. Зная этот факт, исчезает страх: «А вдруг, удалив ветку, я удалю и все файлы?».

3. Читая Git через математику: Алгоритм Diff и хэш-функции

Когда Git обнаруживает конфликты или отображает разницу в файлах, под капотом работают продвинутые алгоритмы.

3.1 Алгоритм Diff Майерса

Алгоритм определения разницы в Git по умолчанию был разработан Юджином В. Майерсом. Если у нас есть два текстовых файла $A$ и $B$, то задачу поиска «минимального количества операций редактирования (вставок и удалений)» для преобразования $A$ в $B$ можно смоделировать как задачу поиска кратчайшего пути в теории графов.

Пусть длины строк равны $N$ и $M$, а их сумма $V = N + M$. Алгоритм Майерса ищет расстояние редактирования (Edit Distance) $D$. Временная сложность этого алгоритма выражается следующей формулой:

$$ \mathcal{O}(V \cdot D) $$

Здесь, если разница между файлами мала (т.е. $D$ мало), алгоритм работает очень быстро — за $\mathcal{O}(V)$. Однако, если файлы совершенно разные, $D \approx V$, и сложность в худшем случае становится равной $\mathcal{O}(V^2)$.

3.2 Patience Diff и Histogram Diff

Алгоритм Майерса отличный, но если вы сильно изменили порядок функций или классов, он может сгенерировать неочевидную для человека (лишённую смысла) разницу. Для решения этой проблемы в Git реализованы алгоритмы Patience Diff и Histogram Diff.

Patience Diff фокусируется на «уникальных строках, которые появляются только один раз в обоих файлах», и находит их наибольшую общую подпоследовательность (Longest Common Subsequence: LCS). Если количество уникальных элементов равно $U$, то вычисление LCS можно решить со следующей вычислительной сложностью:

$$ \mathcal{O}(U \log U) $$

Если вам сложно разрешить конфликт, одним из вариантов решения будет использование git diff --histogram или указание этого алгоритма в стратегии слияния (git merge -s recursive -X histogram).

3.3 SHA-1 и вероятность коллизий

Git управляет всеми объектами с помощью хэш-значений SHA-1. Размер пространства хэшей составляет $2^{160}$. Если аппроксимировать вероятность коллизии хэшей (когда разное содержимое имеет одинаковый хэш) с помощью парадокса дней рождений (Birthday Paradox), то количество объектов $k$, необходимое для достижения вероятности коллизии $p$ в 50%, будет следующим:

$$ k \approx \sqrt{2 \ln(2)} \cdot 2^{80} \approx 1.2 \times 2^{80} $$

Это астрономическое число, и вероятность непреднамеренного возникновения коллизии при обычной разработке программного обеспечения практически равна нулю. Поэтому Git работает, доверяя хэшам как «абсолютно уникальным ID».

4. Пример из практики 1: Сделал коммит не в ту ветку!

[Ситуация] Вы не заметили, что работаете в ветке main, активно писали код для новой фичи и, ко всему прочему, выполнили git commit. Хотя изначально планировали создать ветку feature/login и работать в ней!

Решение: `git reset` и создание ветки

В Git коммиты — это независимые объекты, а ветки — всего лишь указатели. Поэтому проблема мгновенно решается действием: «создать новую ветку, а затем перемотать указатель текущей ветки назад».

1
2
3
4
5
6
7
8
9


# 1. Создать новую ветку, указывающую на текущий коммит (сделанный по ошибке)
$ git branch feature/login

# 2. Перемотать указатель ветки main на один коммит назад (HEAD~1)
# Использование --keep позволяет безопасно выполнить сброс, сохраняя незафиксированные изменения в рабочем каталоге.
$ git reset --keep HEAD~1

# 3. Переключиться на правильную ветку
$ git checkout feature/login

Визуализация: Что произошло внутри?

Давайте визуализируем перемещение указателей веток с помощью gitGraph в Mermaid.

gitGraph
commit id: "Первоначальный коммит"
commit id: "Исправление ошибки"
commit id: "Ошибочный коммит" type: HIGHLIGHT
branch feature/login
checkout feature/login
checkout main

Сначала main и HEAD указывали на «Ошибочный коммит», но с помощью git branch feature/login там был создан новый указатель. Затем, с помощью git reset, только указатель main возвращается на позицию «Исправление ошибки». Сами объекты при этом не удаляются.

5. Пример из практики 2: Хочу отменить уже отправленный (push) коммит!

[Ситуация] Работая до глубокой ночи, вы закоммитили код, полный багов, и к тому же отправили его в удаленный репозиторий с помощью git push origin main. Осознав наличие критического бага, вы бледнеете.

Решение 1: Отмена истории с помощью `git revert` (Рекомендуемое и безопасное)

При командной разработке строго запрещено переписывать историю уже отправленных коммитов с помощью git reset и подобных команд. Это приведет к нарушению целостности локальных репозиториев других разработчиков. Правильный подход — «создать новый коммит, который полностью отменяет изменения ошибочного коммита». Для этого используется git revert.

1
2
3
4
5
6
7


# Создать коммит, отменяющий последний коммит
$ git revert HEAD
[main 7f3a8b2] Revert "Сообщение ошибочного коммита"
 1 file changed, 1 insertion(+), 10 deletions(-)

# Отправить изменения в удаленный репозиторий
$ git push origin main

gitGraph
commit id: "Коммит A"
commit id: "Коммит B (Ошибка)"
commit id: "Отмена коммита B" type: REVERSE

История продолжает двигаться вперед, и восстанавливается только предыдущее состояние кода.

Решение 2: Переписывание истории с помощью `git push --force-with-lease`

Если вы только что отправили код в ветку, которую используете только вы один, то переписывание истории допустимо.

1
2
3
4
5
6
7


# Локально отменяем коммит и вносим исправления
$ git reset --hard HEAD~1
$ git add .
$ git commit -m "Правильная реализация"

# Принудительно перезаписываем историю в удаленном репозитории
$ git push origin feature/login --force-with-lease

--force-with-lease — это безопасный принудительный push, который предотвращает случайную перезапись чужой работы.

6. Пример из практики 3: Нужно переключиться на другую ветку прямо в процессе работы (Магия Stash)

[Ситуация] Вы реализуете новую фичу в ветке feature/A, код еще даже не компилируется — это полуготовое состояние. Внезапно начальник сообщает: «На продакшене в ветке main критический баг, исправь его прямо сейчас!»

Решение: Сохранение работы в `git stash`

git stash — это команда для временного сохранения (прятания) незафиксированных изменений в специальную область.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. Прячем текущие изменения
$ git stash push -m "WIP: фича A частично реализована"

# 2. Теперь можно переключиться на ветку main
$ git checkout main
# ... (работа по исправлению критического бага, коммит и пуш) ...

# 3. По завершении работы возвращаемся в исходную ветку
$ git checkout feature/A

# 4. Восстанавливаем спрятанные изменения
$ git stash pop

Когда вы выполняете git stash, Git под капотом генерирует два специальных объекта-коммита и сохраняет их в ссылку refs/stash. Иными словами, Stash — это тоже просто «временные коммиты без имен».

7. Пример из практики 4: Пугающее состояние “Detached HEAD”

[Ситуация] Вы захотели проверить состояние кода на определенный момент в прошлом и выполнили git checkout 9f8a7b6. Появилось сообщение You are in 'detached HEAD' state.. Вы сделали коммит прямо в этом состоянии, но при переключении ветки коммит исчез!

Механизм Detached HEAD

Обычно HEAD указывает на ветку, например refs/heads/main. Однако, если вы переключаетесь непосредственно на определенный коммит, HEAD начинает указывать напрямую на объект коммита. Это называется Detached HEAD (оторванный HEAD).

graph TD
A["Коммит A"] --> B["Коммит B"]
B --> C["Коммит C"]
C --> D["Коммит D"]
BranchMain["Ветка: main"] --> D
HEAD["HEAD"] --> B
style HEAD fill:#f9f,stroke:#333,stroke-width:4px

Если вы будете создавать коммиты в этом состоянии, ни одна ветка не будет отслеживать эти новые коммиты. Как только вы переключитесь на другую ветку, новые коммиты потеряются.

Решение: Сохранить как новую ветку

Проблема решается созданием новой ветки на том месте, где вы сейчас находитесь.

1
2


# Создать новую ветку в текущей позиции HEAD и переключиться на нее
$ git checkout -b feature/recovered-work

8. Пример из практики 5: Разрешение конфликтов при слиянии и перебазировании

[Ситуация] При выполнении git merge или git rebase появилось сообщение CONFLICT (content), и процесс был прерван.

Разница между слиянием (Merge) и перебазированием (Rebase)

Merge (Слияние) Выполняет трехстороннее слияние (3-way merge) с использованием последних коммитов двух веток и их общего предка, создавая коммит слияния.
Rebase (Перебазирование) Временно сохраняет коммиты текущей ветки и применяет их заново на вершине целевой ветки. История становится линейной.

gitGraph
commit id: "M1"
commit id: "M2"
branch feature
checkout feature
commit id: "F1"
commit id: "F2"
checkout main
commit id: "M3"
merge feature

Как разрешить конфликт

В файле, где возник конфликт, будут вставлены следующие маркеры:

1
2
3
4
5


<<<<<<< HEAD
const apiUrl = "https://api.production.example.com";
=======
const apiUrl = "https://api.staging.example.com";
>>>>>>> feature/new-api

Процесс разрешения крайне прост.

Удалить маркеры и написать правильный код.

1
2
3


const apiUrl = process.env.NODE_ENV === 'production'
 ? "https://api.production.example.com"
 : "https://api.staging.example.com";

Добавить разрешенный файл в индекс (staging). git add выполняет функцию «информирования Git о том, что конфликт разрешен».
1

$ git add index.js

Завершить процесс.

1
2
3
4
5


# В случае слияния
$ git commit -m "Разрешен конфликт слияния в index.js"

# В случае перебазирования
$ git rebase --continue

Если вы запаниковали, вы всегда можете прервать процесс с помощью $ git merge --abort или $ git rebase --abort.

9. Пример из практики 6: История коммитов превратилась в хаос! `git rebase -i`

[Ситуация] У вас скопилось множество мелких коммитов, таких как «Исправление опечатки», «Еще одно исправление», «Добавление тестов». Если слить всё это в main, история станет грязной.

Решение: Интерактивное перебазирование

С помощью git rebase -i (interactive) вы можете менять порядок прошлых коммитов, объединять несколько коммитов в один (squash) или изменять сообщения коммитов.

1
2


# Привести в порядок последние 3 коммита
$ git rebase -i HEAD~3

Откроется редактор, и вы увидите следующее:

1
2
3


pick 1a2b3c4 Исправление опечатки
pick 2b3c4d5 Еще одно исправление
pick 3c4d5e6 Добавление тестов

Измените это следующим образом:

1
2
3


pick 1a2b3c4 Реализация фичи X
squash 2b3c4d5 Еще одно исправление
squash 3c4d5e6 Добавление тестов

Когда вы сохраните и закроете файл, эти 3 коммита будут красиво объединены в один.

10. Пример из практики 7: Непонятно, когда появился баг! `git bisect`

[Ситуация] В текущей ветке main есть баг, но месяц назад во время релиза все было нормально. Вы хотите найти коммит, в котором появился баг, но их больше 100, и вручную это сделать невозможно!

Решение: Поиск бага с помощью бинарного поиска

В Git встроен инструмент, который находит коммит с багом с помощью математического бинарного поиска (Binary Search). Вычислительная сложность составляет $\mathcal{O}(\log N)$, поэтому даже при 1000 коммитах вы сможете найти нужный примерно за 10 проверок.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Начать поиск
$ git bisect start

# Текущий коммит содержит баг (bad)
$ git bisect bad

# Состояние месячной давности (например, хэш a1b2c3d) было рабочим (good)
$ git bisect good a1b2c3d

# Git автоматически переключится на коммит посередине, чтобы вы могли запустить тесты
# Если тест прошел успешно:
$ git bisect good
# Если тест провалился:
$ git bisect bad

Просто повторяя этот процесс, Git точно скажет вам: «Вот этот коммит стал первым коммитом с ошибкой (Bad)». По завершении используйте $ git bisect reset, чтобы вернуться в исходное состояние.

11. Абсолютная страховочная сетка: `git reflog`

Финальный прием против любых «косяков» в Git — это git reflog. Git сохраняет всю локальную историю действий (историю перемещений HEAD) за определенный период времени. Даже если вы удалили ветку или выполнили неправильный reset, вы можете найти хэш из прошлого в git reflog и восстановить состояние, просто выполнив туда git reset --hard.

1
2
3


$ git reflog
9f8a7b6 (HEAD -> main) HEAD@{0}: commit: Добавление новой фичи
1a2b3c4 HEAD@{1}: reset: moving to HEAD~1

12. Заключение

Мы очень подробно разобрали ошибки, с которыми часто сталкиваются новички в Git, механизмы Git, стоящие за ними, и способы их решения. Коммит не в ту ветку, отмена отправленного коммита, использование Stash, спасение из Detached HEAD и разрешение конфликтов. Во всем этом самым важным является представление того, «какими объектами и указателями Git манипулирует под капотом».

Разница в файлах вычисляется по строгим алгоритмам Diff, которые можно описать математическими формулами, а целостность истории обеспечивается криптографическими хэш-функциями. Поняв эту красивую архитектурную концепцию, вы осознаете, что Git — это вовсе не «непонятный черный ящик», а сильнейший щит, надежно защищающий ваш исходный код.

В следующий раз, когда вы подумаете «Я всё сломал!», не спешите закрывать терминал. Сделайте глубокий вдох и введите git status. Git обязательно подскажет вам путь к восстановлению.

Git on kenji.blog

【Команды Git】Разница между 'rebase' и 'merge', и их правильное использование на практике

1. Введение: почему выбор между «merge» и «rebase» — это вечная проблема

2. Внутренняя структура Git: хеши коммитов и объектная модель

2.1 Криптографические свойства хешей коммитов

3. Теория графов и DAG: математическая модель истории Git

3.1 Что такое DAG (направленный ациклический граф)

3.2 Топологическая сортировка и порядок истории

4. Механизмы и типы git merge

4.1 Слияние Fast-Forward (–ff)

4.2 Слияние Non-Fast-Forward (–no-ff)

4.3 Алгоритм трехстороннего слияния (3-Way Merge)

5. Механизм git rebase и реконструкция истории

5.1 Что происходит за кулисами Rebase

5.2 Интерактивный ребейз (Interactive Rebase)

6. Золотое правило ребейза (The Golden Rule of Rebase)

6.1 Почему нельзя делать ребейз публичной истории?

7. Разрешение конфликтов и git rebase –continue

7.1 Разрешение конфликтов в Merge

7.2 Разрешение конфликтов в Rebase

8. Правильное использование на практике (практика рабочих процессов)

8.1 【Сценарий 1】Очистка локальной истории (использование Rebase)

8.2 【Сценарий 2】Следование за новейшей веткой main (использование Rebase)

8.3 【Сценарий 3】Интеграция завершенной функции (использование Merge)

9. Заключение (итоги)

Распространенные ошибки новичков в Git и команды для их решения (разрешение конфликтов и др.)

Распространенные ошибки новичков в Git и команды для их решения (разрешение конфликтов и др.)

1. Введение: Почему мы совершаем ошибки в Git?

2. Бездна Git: Понимание внутренней структуры директории .git

2.1 Объектная модель: Blob, Tree, Commit

2.2 Истинная сущность HEAD и ссылок (Refs)

3. Читая Git через математику: Алгоритм Diff и хэш-функции

3.1 Алгоритм Diff Майерса

3.2 Patience Diff и Histogram Diff

3.3 SHA-1 и вероятность коллизий

4. Пример из практики 1: Сделал коммит не в ту ветку!

Решение: git reset и создание ветки

Визуализация: Что произошло внутри?

5. Пример из практики 2: Хочу отменить уже отправленный (push) коммит!

Решение 1: Отмена истории с помощью git revert (Рекомендуемое и безопасное)

Решение 2: Переписывание истории с помощью git push --force-with-lease

6. Пример из практики 3: Нужно переключиться на другую ветку прямо в процессе работы (Магия Stash)

Решение: Сохранение работы в git stash

7. Пример из практики 4: Пугающее состояние “Detached HEAD”

Механизм Detached HEAD

Решение: Сохранить как новую ветку

8. Пример из практики 5: Разрешение конфликтов при слиянии и перебазировании

Разница между слиянием (Merge) и перебазированием (Rebase)

Как разрешить конфликт

9. Пример из практики 6: История коммитов превратилась в хаос! git rebase -i

Решение: Интерактивное перебазирование

10. Пример из практики 7: Непонятно, когда появился баг! git bisect

Решение: Поиск бага с помощью бинарного поиска

11. Абсолютная страховочная сетка: git reflog

12. Заключение

2. Бездна Git: Понимание внутренней структуры директории `.git`

Решение: `git reset` и создание ветки

Решение 1: Отмена истории с помощью `git revert` (Рекомендуемое и безопасное)

Решение 2: Переписывание истории с помощью `git push --force-with-lease`

Решение: Сохранение работы в `git stash`

9. Пример из практики 6: История коммитов превратилась в хаос! `git rebase -i`

10. Пример из практики 7: Непонятно, когда появился баг! `git bisect`

11. Абсолютная страховочная сетка: `git reflog`