Ветки в Git: что важно понять сразу

За 20–30 минут вы создадите отдельную ветку, сделаете в ней коммит, сольёте изменения в main и научитесь безопасно удалять и восстанавливать ветки. Главное — понять, что ветка в Git не является копией проекта: это подвижная ссылка на коммит, поэтому создание ветки почти ничего не стоит, а ошибки обычно связаны не с файлами, а с тем, где именно находится указатель.

Что нужно иметь до начала

• Установленный Git 2.40 или новее. Команды из материала подходят и для более новых версий.
• Терминал: PowerShell, Windows Terminal, Terminal в macOS или Linux.
• Локальный репозиторий, в котором можно менять файлы. Если проекта нет, создайте пустую папку.
• Настроенные имя и адрес электронной почты Git. Они попадут в метаданные коммитов, но не требуют доступа к GitHub или другой платформе.

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

Ветка — не «вторая версия проекта», а имя, которое указывает, где заканчивается конкретная линия истории.

HEAD^[1] — специальная ссылка Git на текущую позицию: обычно на ветку, в которой вы сейчас работаете. Проверять её нужно чаще, чем кажется.

Пошаговый сценарий: от проекта до слияния

Шаг 1. Создайте или откройте репозиторий

Для нового учебного проекта выполните команды ниже. Файл README.md нужен только для первого коммита.

mkdir git-branches-demo
cd git-branches-demo
git init
git config user.name "Your Name"
git config user.email "you@example.com"
printf "# Git branches demo\n" > README.md
git add README.md
git commit -m "Initial commit"

Команда git add помещает изменения в индекс, а git commit записывает подготовленную версию в историю. Если всё получилось, Git покажет сообщение о созданном коммите, а команда ниже выведет чистое рабочее дерево:

git status

Проверка: в ответе есть nothing to commit, working tree clean или его русская локализация.

Шаг 2. Узнайте, где вы находитесь

Перед любой операцией с ветками проверьте текущую позицию.

git branch --show-current
git log --oneline --decorate -3

Первая команда показывает имя текущей ветки, вторая — последние коммиты и ссылки на них. В новых репозиториях главная ветка может называться main или master. Это зависит от настроек Git и способа создания репозитория.

Проверка: вы видите имя текущей ветки и хотя бы один коммит с пометкой вроде HEAD -> main.

Шаг 3. Создайте ветку и переключитесь на неё

Современный вариант — две отдельные команды: git branch создаёт ветку, а git switch переключает рабочую папку на неё.

git branch feature/hello
git switch feature/hello

Или одной командой:

git switch -c feature/hello

Флаг -c создаёт ветку и сразу делает её текущей. Ветки принято называть по задаче: feature/hello, fix/login-error, docs/readme. Пробелы и слишком общие имена вроде test затрудняют работу в команде.

Проверка: команда git branch --show-current возвращает feature/hello.

Шаг 4. Измените файл и создайте коммит

Добавьте строку в README и посмотрите, как Git разделяет изменения, подготовленные к коммиту, и изменения, которые ещё не подготовлены.

printf "\nThis change belongs to feature/hello.\n" >> README.md
git status
git diff
git add README.md
git diff --cached
git commit -m "Add hello feature"

До git add изменение находится только в рабочем дереве. После него копия изменения попадает в индекс. Коммит фиксирует именно содержимое индекса, а не все случайно изменённые файлы.

Проверка: git status сообщает, что рабочее дерево чистое, а git log --oneline --decorate -2 показывает коммит Add hello feature на ветке feature/hello.

Шаг 5. Переключитесь в main и сравните содержимое

git switch main
cat README.md

В main новая строка пока не должна отображаться: коммит был создан в другой ветке. Если у вашей основной ветки имя master, подставьте его вместо main.

Проверка: git branch --show-current возвращает main, а история показывает, что main и feature/hello указывают на разные коммиты.

Шаг 6. Слейте ветку в main

Слияние запускают из ветки, которая должна получить изменения. Поэтому сначала нужно находиться в main.

git switch main
git merge --no-ff feature/hello

Флаг --no-ff принудительно создаёт отдельный merge-коммит, даже если Git мог бы просто передвинуть указатель main. Это сохраняет в истории факт существования отдельной ветки. Без этого флага Git часто выполняет fast-forward: история остаётся линейной, а отдельного merge-коммита не появляется.

Проверка: Git сообщает об успешном слиянии, а команда ниже показывает коммит функции среди последних записей:

git log --oneline --decorate --graph -5

Шаг 7. Удалите завершённую ветку

После слияния локальная рабочая ветка обычно больше не нужна. Удаляйте её только после проверки, что нужный коммит действительно попал в main.

git branch --merged
git branch -d feature/hello
git branch

Ключ -d безопаснее принудительного удаления: Git откажется удалять ветку, если видит в ней неслитые коммиты. -D обходить эту проверку может, поэтому для первого знакомства его использовать не стоит.

Проверка: feature/hello исчезла из списка, а строка из неё осталась в README.md в ветке main.

Что ломается у новичков

«fatal: not a git repository»

Вы запустили команду не внутри репозитория или не создали его. Выполните pwd либо Get-Location, перейдите в каталог проекта и проверьте наличие папки .git командой git status. Не создавайте новый репозиторий поверх существующего проекта, пока не убедились, где находится его история.

«Your local changes to the following files would be overwritten by checkout»

В рабочей папке есть незакоммиченные изменения, которые переключение ветки может затереть. Сначала сохраните их коммитом, либо временно уберите в stash:

git stash push -m "temporary work"
git switch main
git stash pop

Перед stash pop убедитесь, что возвращаете изменения в подходящую ветку: при конфликте Git остановится и попросит решить его вручную.

«Your branch is ahead of 'origin/main'»

Локальная ветка содержит коммиты, которых ещё нет в удалённом репозитории. Это не ошибка слияния. Если вы проверили историю и готовы публиковать изменения, отправьте именно текущую ветку с помощью git push. Название удалённого репозитория и правила публикации зависят от хостинга и настроек команды.

«CONFLICT (content)» при merge

Две ветки изменили пересекающиеся строки, и Git не может выбрать вариант автоматически. Откройте файл, найдите маркеры <<<<<<<, ======= и >>>>>>>, оставьте правильное содержимое, затем выполните:

git add path/to/file
git commit

Если вы передумали сливать ветки и конфликт ещё не разрешён, отмените операцию:

git merge --abort

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

• Сначала проверяйте git status и текущую ветку, потом переключайтесь или сливайте.
• Новая ветка начинается с текущего коммита. Если создать её не там, где нужно, она унаследует не ту историю.
• Коммиты относятся к истории, а не к веткам. Ветка лишь указывает на последний коммит этой линии.
• git merge не удаляет исходную ветку и не отправляет результат на сервер.
• Удаление ссылки на ветку не равно мгновенному уничтожению коммитов: пока коммиты достижимы через другую ссылку или журнал перемещений, их часто можно восстановить.

Что делать дальше

Повторите сценарий на копии настоящего проекта: создайте ветку для небольшой правки, сделайте два коммита, посмотрите граф через git log --graph --oneline --decorate --all, затем выполните слияние. После этого отдельно изучите pull request или merge request в вашем хостинге: локальный merge меняет только локальную историю, а командная проверка кода и публикация требуют дополнительных шагов.

^[1] HEAD — служебная ссылка Git на текущую позицию в истории. В обычной работе она указывает на текущую ветку, а при просмотре конкретного коммита может находиться в состоянии detached HEAD, когда вы не стоите на имени ветки.