Ветки

Что такое ветка

Ветка — это указатель на коммит. Файл в .git/refs/heads/<имя>, внутри один SHA. Это всё.

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

Из такой простой механики получается удобный workflow: ветки создаются и удаляются за миллисекунды, их можно делать много, никаких "тяжёлых веток" как в SVN.

Команды

git branch                        # список локальных веток
git branch feature/login          # создать ветку от текущего коммита (HEAD)
git switch feature/login          # переключиться
git switch -c feature/login       # создать и сразу переключиться
git branch -d feature/login       # удалить (если merged)
git branch -D feature/login       # удалить force (без проверки)

До 2.23 переключение делалось через git checkout. Команда осталась, но switch (для веток) и restore (для файлов) разнесли два разных действия. Чужие туториалы с checkout встречаются постоянно, это нормально, но в своём коде лучше использовать switch.

Создать ветку от конкретного коммита (не текущего):

git switch -c hotfix abc1234

HEAD — где ты стоишь

HEAD — указатель на текущую ветку (через неё ведёт на текущий коммит). В обычной работе HEAD -> main.

Бывает "detached HEAD": переключился на конкретный коммит, а не на ветку. Закоммитить туда можно, но новый коммит окажется в воздухе: ветки, которая на него показывала бы, нет. Если переключишься обратно - коммит потеряешь: он останется только в reflog и сборщик мусора git gc удалит его, когда запись выйдет из reflog (по умолчанию через 30/90 дней).

Если случайно в detached наработал, создай ветку прямо там: git switch -c rescue.

Feature-branch workflow

Стандарт для команд почти любого размера:

1. От main создаёшь ветку под задачу: feature/payments-retry.
2. Работаешь в ней: коммиты маленькие, тематические.
3. Пушишь в remote: git push -u origin feature/payments-retry.
4. Открываешь Merge Request / Pull Request (запрос на слияние ветки в main, проходит ревью). Дальше обсуждение, правки.
5. После approve ветка вливается в main, удаляется.

-u (или --set-upstream) при первом push'е запоминает связь "локальная ветка <-> ветка в remote". После этого хватает git push и git pull без аргументов: git знает, куда.

git push -u origin feature/payments-retry
# в следующий раз
git push

Почему main защищают

На проде main — источник правды для деплоя. CI/CD триггерится по push'у в main. Поэтому:

• прямой push в main запрещён (только через MR),
• MR не сливается, пока CI зелёный и есть approve,
• force-push в main отрезан совсем.

В GitLab это настраивается в Settings → Repository → Protected branches. В GitHub они называются Branch protection rules. Это стандартная гигиена shared-репозитория.

Удаление ветки в remote

git push origin --delete feature/payments-retry

Или через UI после merge. Чаще всего достаточно поставить галку "Delete source branch" в MR.

Что важно запомнить

Ветка — указатель на коммит, дешёвая и одноразовая.

Под каждую задачу — своя ветка от main.

-u при первом push'е запоминает upstream, дальше push/pull без аргументов.

main защищена, прямой push запрещён, заливается через MR.

В следующем уроке посмотрим, что происходит, когда ветку нужно влить обратно: merge или rebase.