Введение и проблематика

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

Зачем нужны ветки?

• Изоляция работы — разработка новой функции не влияет на стабильный код
• Параллельная разработка — несколько разработчиков работают независимо
• Безопасное экспериментирование — можно пробовать идеи без риска сломать проект
• Code Review — изменения проверяются перед слиянием в основную ветку

Базовая теория

Структура веток

Команды для работы с ветками

Практические примеры

Создание и слияние веток

# Создать новую ветку
git branch feature/user-profile
 
# Создать и сразу переключиться
git switch -c feature/user-profile
 
# Старый синтаксис (тоже работает)
git checkout -b feature/user-profile

# Внести изменения
git add .
git commit -m "Add user profile component"
git commit -m "Add profile settings page"

# Получить изменения из main
git switch main
git pull
git switch feature/user-profile
git merge main

git switch main
git merge feature/user-profile

# Удалить локальную ветку
git branch -d feature/user-profile
 
# Удалить удалённую ветку
git push origin --delete feature/user-profile

Типы слияния

# Fast-forward происходит, когда main не изменился
# после создания ветки
 
git switch main
git merge feature/login
# Fast-forward merge - просто перемещение указателя

Работа с тегами

Теги используются для маркировки важных точек в истории — обычно релизов.

Типы тегов

Команды для работы с тегами

# Создать annotated тег
git tag -a v1.0.0 -m "Release version 1.0.0"
 
# Создать тег на определённом коммите
git tag -a v1.0.0 9fceb02 -m "Release 1.0.0"
 
# Просмотр тегов
git tag
git tag -l "v1.*"
 
# Просмотр информации о теге
git show v1.0.0
 
# Отправить тег на сервер
git push origin v1.0.0
 
# Отправить все теги
git push origin --tags
 
# Удалить тег локально
git tag -d v1.0.0
 
# Удалить тег на сервере
git push origin --delete v1.0.0

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

Пример конфликта

# При слиянии Git сообщит о конфликте
git merge feature/settings
# CONFLICT (content): Merge conflict in config.js

Файл с конфликтом

function getConfig() {
<<<<<<< HEAD
  return { theme: 'dark' };
=======
  return { theme: 'light', lang: 'ru' };
>>>>>>> feature/settings
}

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

git status
# Файлы с конфликтами отмечены как "both modified"

function getConfig() {
  return { theme: 'dark', lang: 'ru' };
}

git add config.js
git commit -m "Resolve merge conflict in config"

Популярные стратегии ветвления

Git Flow

• main — стабильный production код
• develop — интеграционная ветка
• feature/ — ветки функций
• release/ — подготовка релиза
• hotfix/ — срочные исправления в production

GitHub Flow

Упрощённый подход:

1. Создать ветку от main
2. Сделать изменения
3. Открыть Pull Request
4. Code Review
5. Merge в main
6. Deploy

Плюсы и минусы

Вопросы интервьюера

Q: Чем отличается merge от rebase?

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

Q: Когда использовать rebase?

Для локальных веток перед отправкой на сервер. Никогда не делать rebase коммитов, которые уже опубликованы.

Q: Что такое fast-forward merge?

Когда целевая ветка не изменилась после создания feature-ветки, Git просто перемещает указатель без создания merge-коммита.

Q: Чем отличаются lightweight и annotated теги?

Lightweight — просто указатель на коммит. Annotated — полноценный объект с метаданными (автор, дата, сообщение).

Q: Как разрешить конфликт слияния?

Открыть файлы с конфликтами, вручную отредактировать (удалить маркеры, оставить нужный код), добавить в staging и закоммитить.

Источники

• Git Branching - Basic Branching and Merging
• Atlassian: Git Merge vs Rebase
• Git Flow Workflow
• GitHub Flow