Как в Git выполнить слияние веток

Стратегии слияния веток в Git

В Git существует несколько основных способов объединения изменений из разных веток, каждый из которых подходит для разных сценариев разработки. Я, как Senior QA Engineer, особенно обращаю внимание на то, чтобы процесс слияния не нарушал стабильность кода и позволял эффективно тестировать результаты интеграции.

Основные команды слияния

1. git merge — классическое слияние

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

# Переключиться на ветку, В КОТОРУЮ хотите влить изменения (например, main)
git checkout main

# Выполнить слияние с веткой feature-branch
git merge feature-branch

Типы слияния при использовании git merge:

• Fast-forward merge — происходит, когда в целевой ветке (main) не было новых коммитов после создания feature-ветки. Git просто перемещает указатель основной ветки вперед.
• Recursive merge — создается коммит слияния (merge commit) с двумя родителями, когда истории веток разошлись.

Важно для QA: После git merge обязательно запускайте регрессионное тестирование, даже если изменения кажутся небольшими.

2. git rebase — перебазирование

Перемещает всю ветку на вершину другой ветки, переписывая историю коммитов. Создает линейную историю без merge-коммитов.

# Переключиться на feature-ветку
git checkout feature-branch

# Перебазировать feature-ветку на актуальную main
git rebase main

Преимущества для разработки:

• Чистая, линейная история
• Упрощает навигацию по git log

Риски (особенно важно для QA):

• Переписывает историю коммитов — никогда не используйте rebase для публичных веток (main, develop)
• Может вызвать конфликты слияния для каждого коммита feature-ветки

Рекомендация QA инженера: Использовать rebase для локальных веток перед их слиянием в основную ветку через git merge --no-ff (о чем ниже).

3. Стратегические варианты слияния для команды

git merge --no-ff (no fast-forward)

Принудительно создает merge-коммит даже когда возможен fast-forward.

git checkout main
git merge --no-ff feature-branch

Почему это важно с точки зрения QA:

• Сохраняет информацию о том, что была feature-ветка
• Упрощает откат всей функциональности (через git revert для merge-коммита)
• Позволяет легче идентифицировать, какие коммиты относятся к feature

git merge --squash

Объединяет все коммиты feature-ветки в один новый коммит на основной ветке.

git checkout main
git merge --squash feature-branch
git commit -m "Реализована функция X"

Преимущества для процесса:

• Чистая история основной ветки без промежуточных коммитов
• Удобно для небольших фич

Недостатки с точки зрения тестирования:

• Теряется детальная история изменений
• Сложнее проводить бисекцию (git bisect) для поиска багов

Рабочий процесс слияния с точки зрения QA

1. Перед слиянием:

   • Убедитесь, что feature-ветка прошла весь цикл тестирования
   • Проверьте, что pipeline CI/CD успешно завершился
   • Обновите основную ветку: git pull origin main

2. Разрешение конфликтов слияния:

   # При возникновении конфликта Git укажет файлы с конфликтами
   # Отредактируйте файлы, разрешив конфликты вручную
   git add <разрешенные_файлы>
   git commit -m "Разрешение конфликтов слияния"
   

3. После слияния:

   • Запустите smoke-тесты для проверки базовой функциональности
   • Проведите регрессионное тестирование критических сценариев
   • Удалите feature-ветку после успешного слияния:

     git branch -d feature-branch
     

Рекомендации для процесса слияния

• Используйте Pull/Merge Requests в GitLab/GitHub/Bitbucket для code review
• Не сливайте в пятницу перед выходными — оставьте время на пост-релизное тестирование
• Ведите четкую политику ветвления (Git Flow, GitHub Flow, Trunk-Based Development)
• Автоматизируйте тестирование в CI/CD pipeline перед возможностью слияния

Главное правило для QA: Каждое слияние в основную ветку (особенно production) должно рассматриваться как потенциальный риск и требовать соответствующего тестирования, независимо от того, насколько малыми кажутся изменения.