Какие знаешь методы для слияния веток в Git?

Методы слияния веток в Git

В Git существует несколько способов объединить две ветки. Каждый имеет свои плюсы и минусы.

---

1. Merge (трёхсторонний merge)

Что это: объединяет две ветки, создавая merge-commit, который имеет двух родителей.

# На ветке main
git merge feature-branch

# Git найдёт общего предка и создаст merge-commit

Визуально:

ОДО:
        C -- D  (feature)
       /
A -- B -- E -- F  (main)

ПОСЛЕ merge feature-branch:
        C -- D
       /      \
      /        G  (merge-commit)
     /        /
A -- B -- E -- F

Код merge-commit содержит объединённые изменения из обеих веток.

Плюсы:

✅ История полностью сохраняется
✅ Понятно, когда была ветка создана и когда слита
✅ Легко откатить (один commit)

Минусы:

❌ История становится нелинейной (сложнее читать)
❌ Много merge-commitов при частых интеграциях
❌ Граф истории запутанный

---

2. Rebase (перебазирование)

Что это: перемещает коммиты одной ветки на вершину другой, линеаризуя историю.

git checkout feature-branch
git rebase main

# или сразу:
git rebase main feature-branch

Визуально:

ОДО:
        C -- D  (feature)
       /
A -- B -- E -- F  (main)

ПОСЛЕ rebase main:
              C' -- D'  (feature)
             /
A -- B -- E -- F  (main)

(Коммиты C и D пересозданы: C' и D')

Реально: Git берёт каждый коммит из feature (C, D) и повторяет его на вершине main:

1. C' = apply(C's changes on top of F)
2. D' = apply(D's changes on top of C')

Плюсы:

✅ История линейная и понятная
✅ Легче читать git log
✅ Меньше merge-commitов
✅ Чистая история

Минусы:

❌ Переписывает историю (опасно если ветка публична!)
❌ Коммиты меняют хеши (теряется соответствие с origin)
❌ Может быть сложнее разбираться с конфликтами
❌ Если ошибиться — потеря работы

⚠️ ПРАВИЛО: никогда не делай rebase на публичной ветке (которую используют другие разработчики)!

---

3. Squash (сжатие)

Что это: объединяет все коммиты одной ветки в один коммит при слиянии.

git merge --squash feature-branch
# Создаёт merge-commit, но забывает историю feature-branch

Визуально:

ОДО:
        C -- D -- E  (feature: 3 коммита)
       /
A -- B -- F -- G  (main)

ПОСЛЕ merge --squash:
        C -- D -- E  (feature, НЕ трогается)
       /
A -- B -- F -- G -- H  (main)
      (H содержит все изменения C+D+E, но без их истории)

Плюсы:

✅ История main чистая и линейная
✅ Одна фича = один коммит
✅ Легко откатить фичу целиком

Минусы:

❌ История feature-branch полностью теряется
❌ Нельзя просмотреть отдельные коммиты фичи
❌ Может быть сложно разобраться с конфликтами

---

4. Interactive Rebase (интерактивный rebase)

Что это: позволяет редактировать коммиты во время rebase (переписывать, переупорядочивать, сжимать).

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

git rebase -i main feature-branch  # редактировать всё, что не в main

Что откроется:

pick C1234 First commit
pick D5678 Second commit
pick E9999 Third commit

# Команды:
# p, pick = использовать коммит
# r, reword = использовать, но отредактировать сообщение
# s, squash = использовать, но объединить с предыдущим
# f, fixup = то же что squash, но выкинуть сообщение
# d, drop = удалить коммит
# e, edit = использовать, но остановиться для редактирования

Пример: сжать последние 3 коммита в 1:

pick C1234 First commit
squash D5678 Second commit    # <- squash (объединить с предыдущим)
squash E9999 Third commit     # <- squash (объединить с C+D)

Результат: один большой коммит с объединённым сообщением.

Плюсы:

✅ Максимальный контроль над историей
✅ Можно чистить историю перед PR
✅ Красивая, понятная история

Минусы:

❌ Опасно (переписывает историю)
❌ Требует внимания и опыта
❌ Может быть долгим и скучным для больших веток

---

5. Cherry-pick

Что это: берёт конкретный коммит из одной ветки и применяет его в другую.

# Копирует коммит ABC123 из feature в main
git cherry-pick ABC123

# Несколько коммитов
git cherry-pick ABC123 DEF456 GHI789

# Диапазон (исключая первый)
git cherry-pick ABC123..GHI789

Визуально:

ОДО:
feature: A -- B -- C -- D
main:    X -- Y -- Z

ПОСЛЕ cherry-pick C (из main):
feature: A -- B -- C -- D  (не изменилась)
main:    X -- Y -- Z -- C'  (скопирован коммит C)

C' — новый коммит с теми же изменениями, что C, но другой хеш и родитель.

Плюсы:

✅ Выборочное применение коммитов
✅ Полезно для backports
✅ Гибкое управление

Минусы:

❌ Дублирует коммиты (разные хеши)
❌ Может привести к конфликтам
❌ История становится запутанной
❌ Сложно отследить, какие изменения куда ушли

---

6. Fast-Forward (автоматическое слияние)

Что это: если главная ветка НЕ имеет новых коммитов, то это просто движение указателя.

ОДО:
main: A -- B
feature: A -- B -- C -- D

ПОСЛЕ merge (fast-forward):
main: A -- B -- C -- D
feature: A -- B -- C -- D

(Никаких merge-commitов, просто сдвинул указатель main)

# Fast-forward автоматический, но можно отключить:
git merge --no-ff feature  # создаёт merge-commit даже если возможен FF

---

Сравнение: когда что использовать

---

Реальный workflow

Вариант 1: GitHub Flow (простой)

# Создал фичу
git checkout -b feature/login
(работаю)
git add . && git commit -m "Add login"

# Готов к merge
git push origin feature/login
# Делаю Pull Request на GitHub
# (Review, approve)

# Merge на GitHub: используется merge или squash
# (GitHub выполняет merge on GitHub)

# Удаляю локальную ветку
git checkout main
git pull origin main
git branch -d feature/login

Вариант 2: Git Flow (сложнее)

# Фича в develop
git checkout -b feature/login develop
(работаю)

# Перед merge на develop: rebase
git rebase develop
# Теперь история develop линейна

git checkout develop
git merge --no-ff feature/login  # merge-commit для отслеживания

Вариант 3: Squash перед PR

# Много коммитов во время разработки
git log --oneline
# C1234 Fix typo
# D5678 Add feature
# E9999 Refactor

# Перед PR: сжимаю в один
git rebase -i main
# pick D5678, squash C1234, squash E9999

# Результат: один коммит "Add feature"
git push origin feature --force-with-lease

---

Опасности и как их избежать

❌ Опасность 1: Rebase на публичной ветке

# НИКОГДА!
git rebase origin/main  # и потом push --force
# Другие разработчики потеряют связь со своими коммитами

Безопасно:

# Только на локальных ветках
git rebase main

❌ Опасность 2: Слияние двух направлений

# Если сделал merge main в feature, а потом feature в main
# История запутается

Правило: всегда merge в одном направлении (feature → main, never main → feature)

✅ Защита: force-with-lease

# Вместо:
git push origin --force  # опасно!

# Используй:
git push origin --force-with-lease  # проверит, что никто не толкнул

---

Итог

Для быстрого запоминания:

• merge — сохраняет историю, создаёт merge-commit
• rebase — линеаризует историю (опасен на публичных ветках)
• squash — объединяет всё в один коммит
• cherry-pick — копирует отдельные коммиты
• interactive rebase — полный контроль, но опасен

Золотое правило: линейная история в main, любые манипуляции в feature-ветках.