Merge
Merge (слияние) — это операция в системе контроля версий (например, Git), которая объединяет изменения из одной ветки в другую. Проще говоря, merge — это способ «влить» код, над которым вы работали отдельно, обратно в основную ветку проекта, сохранив при этом всю историю изменений.
Что такое Merge
Merge (в переводе — «слияние») используется, когда вы хотите объединить две ветки разработки в одну. Чаще всего это происходит, когда разработчик завершает работу над задачей в отдельной ветке (feature/add-login) и хочет добавить результат в основную (main или develop).
Пример: Вы создали новую функцию в своей ветке. После проверки кода через Pull Request вы выполняете merge, и изменения становятся частью основного проекта.
Как работает Merge
При слиянии Git сравнивает три состояния проекта:
- общий предок (точка, где ветки разошлись),
- текущую ветку,
- сливаемую ветку.
После анализа различий Git объединяет изменения и создаёт новый коммит слияния (merge commit), фиксирующий результат.
Пример команды:
git merge feature/add-login
Эта команда объединит ветку feature/add-login в текущую (например, develop).
Типы слияния (Merge)
| Тип | Описание |
| Fast-forward merge | Происходит, если основная ветка не изменилась с момента ветвления. История просто «прокручивается» вперёд без создания нового коммита. |
| No fast-forward (обычный merge) | Создаётся новый коммит слияния, который объединяет обе ветки, сохраняя их независимую историю. |
| Squash merge | Объединяет все коммиты ветки в один перед слиянием — удобно для аккуратной истории. |
| Rebase + merge | История ветки «переписывается» поверх основной, чтобы сделать историю линейной. |
Пример Fast-forward Merge
git checkout main
git merge feature/header
Если в main не было новых коммитов, Git просто «продвинет» указатель ветки вперёд, и история будет линейной — без дополнительного коммита.
Пример обычного Merge
git checkout develop
git merge feature/payment
Если в обеих ветках есть изменения, Git создаст merge commit:
Merge branch ‘feature/payment’ into ‘develop’
Этот коммит фиксирует, что ветки были объединены.
Конфликты при Merge
Иногда Git не может автоматически объединить изменения — например, если в одной и той же строке двух файлов внесены разные правки. Это называется merge conflict.
Пример конфликта:
<<<<<<< HEAD
console.log(‘Добро пожаловать!’);
=======
console.log(‘Welcome!’);
>>>>>>> feature/translation
Решение:
- Вручную выберите нужный вариант или объедините обе версии.
- Удалите метки <<<<<<<, =======, >>>>>>>.
Сохраните файл и выполните:
git add <файл>
git commit
Пример рабочего процесса (workflow)
# Создаём ветку для задачи
git checkout -b feature/add-search
# Работаем и коммитим изменения
git add .
git commit -m «feat: добавлен поиск по каталогу»
# Возвращаемся в основную ветку
git checkout develop
# Сливаем новую функциональность
git merge feature/add-search
После этого код из feature/add-search добавляется в develop.
Затем ветку можно удалить:
git branch -d feature/add-search
Merge и Pull Request
На платформах вроде GitHub или GitLab операция слияния чаще выполняется через Pull Request (или Merge Request). После того как ревьюеры проверили код и одобрили его, вы нажимаете кнопку “Merge”, и система автоматически объединяет ветки.
В GitHub можно выбрать способ слияния:
- Merge commit — стандартное слияние с сохранением истории.
- Squash and merge — все коммиты ветки объединяются в один.
- Rebase and merge — история становится линейной, без merge-коммитов.
Преимущества Merge
- Сохраняет полную историю изменений. Все коммиты и ветки остаются видимыми.
- Безопасен и предсказуем. Не изменяет существующие коммиты (в отличие от rebase).
- Подходит для командной работы. Удобно использовать с Pull Request для прозрачного ревью.
Недостатки
- История может стать запутанной. При большом количестве merge-коммитов история ветвится и теряет наглядность.
- Требует разрешения конфликтов вручную. Особенно в крупных командах с активными изменениями.
- Менее чистая история, чем при rebase. Иногда разработчики предпочитают использовать rebase перед merge, чтобы сделать историю линейной.
Merge vs Rebase
| Критерий | Merge | Rebase |
| Сохранение истории | Да, с merge-коммитом | Нет, история переписывается |
| Риск конфликтов | Возможен, при объединении веток | Возможен при каждом коммите |
| Прозрачность | Высокая — видны все ветки | История выглядит чище |
| Безопасность | Абсолютно безопасен для публичных веток | Опасен при изменении общей истории |
| Применение | При командной работе | Для локальных правок перед пушем |
Лучшие практики Merge
- Перед слиянием обновите ветку: git pull origin main
- Проверяйте тесты и линтер — особенно перед слиянием в main.
- Используйте Pull Request, чтобы другие участники могли сделать ревью.
- Удаляйте временные ветки после успешного merge.
- Если история запутана — применяйте squash или rebase для чистоты.
Итог
Merge — это ключевой процесс в Git, который объединяет код разных разработчиков в одну целостную версию проекта. Он обеспечивает командную синхронизацию, сохраняет историю изменений и делает разработку управляемой.
