Ветки в Git: полное руководство для начинающих

Ветки — один из главных механизмов Git. Они позволяют нескольким разработчикам работать над разными задачами одновременно, не мешая друг другу. Без понимания веток невозможно эффективно использовать Git в команде. В этой статье разберём, что такое ветки, как они работают внутри Git и как применять их в реальных проектах.

Что такое ветка в Git #

Ветка в Git — это просто указатель на конкретный коммит. Ничего более. Когда вы создаёте новую ветку, Git создаёт новый указатель (несколько байт) на текущий коммит. Это делает создание и переключение веток в Git практически мгновенным.

Представьте хронологию коммитов как цепочку:

A ← B ← C ← D (main)

Когда вы создаёте ветку feature:

A ← B ← C ← D (main)
               ↑
             (feature)

Оба указателя смотрят на один коммит D. Теперь вы делаете коммиты в feature:

A ← B ← C ← D ← E ← F (feature)
               ↑
             (main)

Ветки разошлись: main всё ещё на D, feature продвинулась до F.

Что такое HEAD #

HEAD — это специальный указатель, который показывает, на какой ветке вы сейчас находитесь (и, следовательно, какой коммит является «текущим»):

A ← B ← C ← D ← E (feature) ← HEAD
               ↑
             (main)

Когда вы переключаетесь на другую ветку, HEAD перемещается. Все новые коммиты создаются там, куда смотрит HEAD.

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

Ветки решают несколько реальных проблем:

Параллельная разработка. Два разработчика работают над разными задачами — каждый в своей ветке. Изменения не конфликтуют.

Изоляция экспериментов. Хотите попробовать новый подход, не уверены, получится ли? Создайте ветку, экспериментируйте. Если не получилось — просто удалите ветку.

Стабильный основной код. Ветка main всегда содержит рабочий, протестированный код. Новые функции разрабатываются в отдельных ветках и вливаются только после проверки.

Быстрые исправления. Нужно срочно исправить баг в продакшне? Создайте hotfix-ветку от main, исправьте, влейте обратно — не затрагивая незаконченные функции.

Удобство проверки кода (code review). Pull Request / Merge Request — это запрос на вливание ветки. Ветки делают review естественным этапом процесса.

Master, main и соглашения об именовании #

Исторически основная ветка называлась master. В 2020 году GitHub, GitLab и другие платформы начали переходить на main как менее нейтральное название. Сегодня:

Новые репозитории на GitHub создаются с веткой main по умолчанию
Старые репозитории продолжают использовать master
Вы можете использовать любое имя

Настройте имя ветки по умолчанию для новых репозиториев:

git config --global init.defaultBranch main

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

Просмотр веток #

# Все локальные ветки (звёздочка = текущая)
git branch

# Все ветки: локальные и удалённые
git branch -a

# Только удалённые ветки
git branch -r

# С информацией о последнем коммите
git branch -v

# С информацией об отслеживании удалённых веток
git branch -vv

# Ветки, слитые с текущей (можно удалять)
git branch --merged

# Ветки, ещё не слитые (осторожно при удалении)
git branch --no-merged

Создание веток #

# Создать ветку (без переключения)
git branch feature-name

# Создать и сразу переключиться (старый способ)
git checkout -b feature-name

# Создать и переключиться (современный способ)
git switch -c feature-name

# Создать от конкретного коммита
git branch feature-name a1b2c3d

Подробнее о создании веток — в статье «Как создать ветку в Git».

Переключение веток #

# Старый способ
git checkout main

# Современный способ (Git 2.23+)
git switch main

Удаление веток #

# Удалить слитую ветку (безопасно)
git branch -d feature-name

# Принудительно удалить (даже если не слита)
git branch -D feature-name

# Удалить удалённую ветку на сервере
git push origin --delete feature-name

Переименование #

# Переименовать текущую ветку
git branch -m new-name

# Переименовать другую ветку
git branch -m old-name new-name

Локальные и удалённые ветки #

В Git существует разница между локальными и удалёнными ветками:

Локальные ветки — существуют только на вашем компьютере. Вы их создаёте, коммитите, удаляете.

Удалённые ветки — ветки на сервере (GitHub, GitLab). В локальном репозитории хранятся их «слепки» вида origin/main, origin/feature. Они обновляются при git fetch или git pull.

# Посмотреть все ветки включая удалённые
git branch -a
# * main
#   feature/auth
#   remotes/origin/main
#   remotes/origin/feature/auth

Отслеживающие ветки #

Локальная ветка может «отслеживать» удалённую — это значит, что git push и git pull будут знать, куда отправлять/откуда получать изменения:

# Создать с отслеживанием
git switch -c feature origin/feature

# Установить отслеживание для существующей ветки
git branch -u origin/main main

# Проверить настройки отслеживания
git branch -vv
# * main    a1b2c3d [origin/main] Update README

Рабочие процессы с ветками (Branching Workflows) #

GitHub Flow (простой, рекомендуется для большинства команд) #

main ← все в продакшне
  ↓
feature/xyz ← работа над задачей
  ↓
Pull Request → code review
  ↓
merge в main → деплой

Принципы:

main всегда готова к деплою
Работа ведётся в feature-ветках
Через Pull Request проводится code review
После review — слияние в main

Git Flow (для проектов с чёткими релизами) #

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

Trunk-Based Development (для CI/CD) #

Все разработчики коммитят напрямую в main несколько раз в день. Ветки минимальны и живут не более 1–2 дней. Требует хорошего покрытия тестами и feature flags.

Граф веток #

Посмотреть визуальный граф истории:

git log --graph --oneline --all

# Пример вывода:
# * f3e2d1c (HEAD -> feature/auth) Add OAuth2
# * a4b5c6d Add login form
# | * 9e8d7c6 (main) Fix typo in README
# |/
# * 1a2b3c4 Initial commit

Практический пример: работа с ветками #

# Начало работы над задачей
git switch main
git pull origin main   # Обновить main
git switch -c feature/new-dashboard

# Разработка
echo "dashboard code" > dashboard.js
git add dashboard.js
git commit -m "feat: add dashboard skeleton"

# Ещё один коммит
echo "dashboard styles" > dashboard.css
git add dashboard.css
git commit -m "style: add dashboard CSS"

# Посмотреть историю
git log --oneline
git log --graph --oneline --all

# Вернуться на main и слить
git switch main
git merge feature/new-dashboard

# Или создать pull request на GitHub
git push origin feature/new-dashboard
# Затем открыть PR через интерфейс GitHub

# После слияния — удалить ветку
git branch -d feature/new-dashboard
git push origin --delete feature/new-dashboard

Часто задаваемые вопросы #

Какая разница между master и main? Только название. Это одна и та же роль — основная ветка проекта. Переход на main — это изменение соглашения, не технические отличия.

Что происходит с HEAD при переключении? HEAD перемещается на указанную ветку. Файлы в рабочей директории обновляются до состояния на момент последнего коммита этой ветки.

Что произойдёт, если удалить ветку? Только указатель удаляется. Коммиты остаются в репозитории (до следующего git gc). Если ветка не слита, при удалении через -d Git предупредит. Используйте -D для принудительного удаления.

Как восстановить удалённую ветку? Если знаете хеш последнего коммита: git branch new-name <hash>. Найти хеш можно через git reflog.

Как настроить отслеживание удалённой ветки? git branch -u origin/branch-name или git push -u origin branch-name при первом push.

Заключение #

Ветки — это мощный, лёгкий и быстрый инструмент параллельной разработки. В Git создание ветки занимает миллисекунды, а переключение между ними — секунды. Это принципиальное отличие от других систем контроля версий, где ветки были тяжёлыми и дорогостоящими операциями.

Используйте ветки активно: для каждой задачи — отдельная ветка. Это сделает историю проекта чистой, упростит code review и позволит работать команде без постоянных конфликтов.

Следующий шаг — научиться создавать ветки разными способами в статье «Как создать ветку в Git».