Что используешь в Git rebase или merge?

Что используешь: Git rebase или merge

Это один из самых спорных вопросов в разработке. Обе команды объединяют ветки, но по-разному. Нет единственно правильного ответа — выбор зависит от контекста и требований проекта. Давай разберёмся в обоих подходах.

Git Merge — объединение с историей

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

# Команда
git checkout main
git merge feature-branch

# История ветки (история сохраняется):
# main:    A --- B --- C --- D (merge commit с двумя родителями)
#           \           /
# feature:   E --- F ---

# Результат: D.parents = [C, F]
# Полная история: A -> B -> C -> E -> F -> D

Преимущества merge:

# 1. Сохраняет полную историю разработки
# Можешь увидеть, когда и как был добавлен код
# git log --graph показывает красивую картину

# 2. Безопасно для shared веток
# Не переписываешь историю, что критично для collaborative work

# 3. Просто откатить слияние
git revert -m 1 <merge-commit-hash>
# Создаст новый коммит, отменяющий слияние

# 4. Логично отслеживать feature branches
# Видишь, какие фичи были добавлены
git log --graph --oneline --all

Недостатки merge:

# 1. История становится загромождена коммитами слияния
# git log выглядит сложно при частых merges

# 2. Коммиты слияния могут скрывать проблемы
# Сложнее найти, какой реальный коммит вызвал регрессию

# 3. Много merge commits в history
# Для большого проекта это может запутать историю

Git Rebase — переписывание истории

Rebase перепишет историю, поместив коммиты feature-ветки поверх main:

# Команда
git checkout feature-branch
git rebase main

# История ветки (переписана, без merge commit):
# main:     A --- B --- C
# feature:               E' --- F'
#           (E и F перемещены поверх C)

# E' и F' — это новые коммиты с новыми хешами!
# Исходные E и F больше не в истории

Преимущества rebase:

# 1. Чистая, линейная история
git log --oneline
# A
# B
# C
# E'
# F'
# Просто читать и понять последовательность

# 2. Легче найти регрессии
git bisect # работает лучше с линейной историей

# 3. Меньше коммитов слияния
# История выглядит аккуратнее

# 4. Проще понять, что произошло
# Каждый коммит — это отдельный логичный шаг разработки

Недостатки rebase:

# 1. ПЕРЕПИСЫВАЕТ ИСТОРИЮ
# Никогда не используй на shared branches!
# Если someone else работает на feature-branch,
# они получат конфликты и потеряют свою работу

# 2. Сложнее откатить
# Нельзя просто git revert
# Если rebase пошёл неправильно, нужно git reflog

# 3. Конфликты нужно решать для каждого коммита
# При merge конфликты решаются один раз

# 4. История коммитов может быть не соответствует реальности
# Коммит, который работал отдельно, может не работать в rebase

Реальный пример конфликтов

# Исходная состояние
# main: A(file.txt="hello") -> B(file.txt="hello world")
# feature: A -> C(file.txt="goodbye")

# MERGE подход
git checkout main
git merge feature
# Конфликт! Решаешь один раз
# D(file.txt = ???)
# Готово, один merge commit

# REBASE подход
git checkout feature
git rebase main
# Конфликт в коммите C!
# git add file.txt
# git rebase --continue
# C'(file.txt = ???)
# Если было бы D, нужно решать конфликт опять для D

Стратегии для разных сценариев

1. Стратегия 1: Rebase для local веток, merge для main

Это популярный подход:

# Разработка на feature ветке
git checkout -b feature/my-feature
git commit -m "Add feature"
git commit -m "Fix feature"

# Перед отправкой на review — rebase на main
# (чтобы история была чистой)
git fetch origin
git rebase origin/main

# Решить конфликты если есть

# Отправить PR
git push -f origin feature/my-feature

# На GitHub: merge commit PR (не rebase!)
# Это сохранит историю слияния и будет безопасно

2. Стратегия 2: Squash and merge

Комбинирует оба подхода:

# На GitHub/GitLab: "Squash and merge"
# Результат: все коммиты feature-ветки объединяются в один
# main: A -> B -> C -> D(объединённый коммит всей feature)

# Преимущества:
# - Чистая история на main
# - Один логичный коммит = одна фича
# - Не переписываешь историю feature-ветки

# Недостатки:
# - Теряется история коммитов feature

3. Стратегия 3: Interactive rebase для очистки

# Перед отправкой на review можешь очистить историю
git rebase -i origin/main

# Интерактивный rebase позволяет:
# - Объединить коммиты (squash)
# - Переордерить коммиты
# - Отредактировать сообщения
# - Удалить коммиты

# Пример:
# pick E1 Add feature part 1
# squash E2 Fix typo
# squash E3 Add missing file
# pick E4 Improve performance
#
# Результат: 2 коммита вместо 4

Чек-лист: как выбрать

# Используй MERGE если:
# ✓ Это shared branch (main, develop)
# ✓ Много людей работают на ветке
# ✓ Нужна полная история разработки
# ✓ Нужна возможность отката с git revert
# ✓ Хочешь видеть точку слияния в истории

# Используй REBASE если:
# ✓ Это твоя личная feature ветка
# ✓ Никто ещё не работает на ветке
# ✓ Хочешь чистую линейную историю
# ✓ Будешь отправлять PR с merge commit на main
# ✓ Хочешь объединить несколько черновых коммитов

Лучшие практики

# 1. Golden Rule: НИКОГДА rebase на shared branch
shared_branches = ["main", "master", "develop", "production"]
# Если забыл и сделал git push -f
# Сообщи коллегам немедленно! Они получат конфликты.

# 2. Используй merge commits для visibility
# GitHub Pull Request = merge commit
# Это сохраняет историю и точку слияния

# 3. Если нужна чистая история на main:
# Используй Squash and Merge в PR
# Или интерактивный rebase на feature ветке

# 4. Документируй решение в проекте
# В CONTRIBUTING.md опиши стратегию ветвления

# Пример:
# MERGE STRATEGY
# - Feature branches: используй rebase для чистой истории
# - Отправка на main: используй GitHub UI для merge commit
# - PR с несколькими черновыми коммитами: используй squash

Реальные примеры из популярных проектов

# Linux Kernel: Очень консервативный, merges (Linus Torvalds так требует)
# git log --graph --all | head -50
# Видны все merge commits, история полная

# React: Squash and merge в PR
# Чистая история на main, один коммит на PR

# Docker: Merge commits для visibility
# Видна история интеграции разных фич

# Google: Interactive rebase перед отправкой
# Чистые коммиты, потом merge на main

Команды для работы

# Merge
git checkout main
git merge --no-ff feature-branch  # --no-ff гарантирует merge commit
git push origin main

# Rebase
git checkout feature-branch
git rebase main
git push -f origin feature-branch  # -f потому что переписали историю

# Squash and merge (локально)
git checkout feature-branch
git reset --soft main  # отменить все коммиты, но сохранить изменения
git commit -m "Feature: description"
git checkout main
git merge feature-branch

# Или на GitHub UI просто выбери "Squash and merge"

Мой рекомендуемый подход (как опытный разработчик)

# 1. На личной feature ветке: используй rebase
git rebase main  # Чистая история перед PR

# 2. Interactive rebase для очистки коммитов
git rebase -i main
# Объедини черновые коммиты, переупорядочи, отредактируй сообщения

# 3. Отправь PR
git push -f origin feature-branch

# 4. На GitHub: используй "Squash and merge" или "Create a merge commit"
# Это гарантирует, что main получит чистую историю

# 5. НИКОГДА не переписывай main историю
git checkout main
git pull origin main  # Только pull

# Результат: main чистый и линейный, но сохраняется история слияния

Заключение

Rebase даёт чистую историю, merge сохраняет полную историю разработки. В modern workflow:

• Используй rebase локально на feature ветках для чистоты
• Используй merge или squash при отправке на main
• НИКОГДА не переписывай историю shared веток

Когда интервьюер спросит "merge или rebase?" — ответь: "Это зависит от контекста. Для личных веток я использую rebase для чистой истории. Для main я предпочитаю merge commits или squash, чтобы сохранить историю интеграции и не переписывать shared ветку. Главное правило: никогда не переписываешь историю веток, на которых работают другие люди."