Как работать с ветками в Git и не запутаться в командах

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

Рекомендуем в процессе чтения открыть редактор и повторять за нами. В конце у вас получится шпаргалка по основным командам для работы с ветками Git.

Содержание

• Что такое ветки в Git и зачем они нужны
• Начинаем проект: создаём ветку main и делаем первый коммит
• Что такое git branch: создаём рабочую ветку
• Сливаем изменения из feature-веток
• Разрешаем merge-конфликты и завершаем слияние
• Удаляем временные ветки и финалим проект

Что такое ветки в Git и зачем они нужны

Когда вы начинаете проект и инициализируете репозиторий, Git автоматически создаёт главную ветку. В ней хранят стабильную версию кода, и она служит отправной точкой для создания остальных веток. Раньше главная ветка по умолчанию называлась master, но с 2020 года она подписывается как main.

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

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

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

Например, на схеме ниже разработка началась в ветке main, и в неё были добавлены коммиты A, B, C. Затем в точке C кто-то создал ветку feature и продолжил работу там — появились коммиты D, E, F. В этот момент указатель Head указывает на F — это значит, что мы находимся в feature. Ветка main не знает об этих изменениях и остаётся на месте. В конце ветка feature сливается с main — так появляется коммит G, который объединяет обе линии разработки.

Конечно, внутреннее устройство Git намного сложнее. Но для практики нам достаточно текущей теории, и далее мы перейдём к знакомству с командами.

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

Для начала работы создайте на компьютере новую папку и придумайте ей название. В нашем примере она будет называться git-branches-cheatsheet. Перенесите эту папку в VS Code или другой редактор кода. В ней мы сверстаем красивую шпаргалку по основным командам для работы с ветками в Git:

Для начала откройте терминал в редакторе и проверьте, установлен ли Git на вашем компьютере. Для этого выполните команду:

git --version

Если Git не установлен, скачайте его с официального сайта, а затем инициализируйте репозиторий с главной веткой main:

git init -b main

После этого перейдите в маркетплейс расширений VS Code и найдите плагин Git Graph. Он поможет нам работать с ветками — вместо скучного списка коммитов в терминале мы будем видеть наглядную интерактивную схему.

Пока у нас нет коммитов, поэтому плагин Git Graph ничего не отображает. Чтобы это исправить, создадим файл index.html с базовой разметкой проекта:

<!DOCTYPE html>
<html lang="ru">
<head>
  <meta charset="UTF-8">
  <title>Работа с ветками в Git</title>
  <link rel="stylesheet" href="css/style.css">
</head>
<body>
  <div class="container">
    <header>
      <h1>Шпаргалка по Git</h1>
    </header>
    <main class="grid">
      <!-- Сюда будем добавлять карточки -->
    </main>
  </div>
</body>
</html>

Теперь создадим папку css и добавим в неё файл style.css. В редакторе у нас установлена цветовая тема Dracula, поэтому давайте используем её палитру:

:root {
  --bg: #282a36;
  --card-bg: #44475a;
  --text: #f8f8f2;
  --purple: #bd93f9;
  --cyan: #8be9fd;
  --green: #50fa7b;
  --orange: #ffb86c;
}

body {
  background-color: var(--bg);
  color: var(--text);
  font-family: 'Inter', sans-serif;
}

Основа готова, и мы можем сохранить это состояние в истории Git. Чтобы сделать первый коммит, выполните в терминале две следующие команды:

git add .

git commit -m "chore: Базовая структура и стили проекта"

После этого в Git Graph появится первая точка — это начальный коммит, «корень» проекта, от которого будут ответвляться все остальные ветки. В данный момент мы находимся в ветке main — основной линии разработки:

Что такое git branch: создаём рабочую ветку

Из теоретического раздела вы уже знаете, что в профессиональной разработке никто не пишет код сразу в main, и для каждой задачи создают отдельную ветку. Есть несколько способов это сделать, и самый простой вариант — команда git branch. Она нужна для работы с ветками в Git. С её помощью можно создавать, смотреть список, переименовывать и удалять локальные ветки.

git branch <имя новой ветки>

После этой команды Git создаст новую ветку, однако вы всё ещё останетесь на прежнем месте — в данном случае в main. Чтобы начать работу в новой ветке, вам нужно переключиться на неё вручную. Это делается командой switch:

git switch <имя ветки>

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

Но согласитесь: сначала создавать ветку, а затем переключаться на неё вручную — не очень удобно. Поэтому разработчики чаще используют команды, которые объединяют создание и переход в одно действие. Вот старый универсальный вариант, который вы, скорее всего, встретите в большинстве туториалов:

git checkout -b <имя новой ветки>

А вот современный вариант, который мы будем использовать:

git switch -c <имя новой ветки>

Давайте создадим ветку feature/basics, чтобы добавить в нашу шпаргалку раздел с командами из первого шага:

git switch -c feature/basics

Теперь, когда мы работаем в изолированной ветке, добавим в index.html первую карточку. Для этого вставьте в тег <main> следующий блок кода:

<section class="card">
        <h2>Подготовка</h2>
        <ul>
          <li>
            <span class="desc">Инициализация репозитория</span>
            <code>git init</code>
          </li>
          <li>
            <span class="desc">Проверка статуса файлов</span>
            <code>git status</code>
          </li>
        </ul>
</section>

Сохраним файл и зафиксируем изменения коммитом:

git add index.html

git commit -m "feat: Добавлена секция основ"

Если вы откроете Git Graph, то увидите механику ветвления: метка main осталась привязанной к первому коммиту — она фиксирует состояние проекта до внесения правок, а feature/basics переместилась на более высокий узел.

Сейчас в репозитории параллельно существуют две версии проекта. У нас есть main с базовой структурой и feature/basics со структурой и карточкой «Подготовка». На данном этапе эти версии изолированы, поэтому если вы переключитесь на main, добавленный код в файле index.html исчезнет.

Прежде чем двигаться дальше, обратите внимание на название ветки. Оно написано в формате feature/basics. Префикс feature/ указывает, что задача связана с добавлением функциональности. А вторая часть (basics) описывает её содержание. Другие распространённые префиксы: bugfix/ для исправления ошибок, hotfix/ для срочных правок и chore/ для технических задач. Такой подход к неймингу помогает сразу понять назначение каждой ветки без необходимости открывать задачу в трекере или читать её подробное описание.

Вот команда, которая позволяет переименовать вашу текущую ветку:

git branch -m <новое имя ветки>

А эта команда позволяет переименовать одну ветку, находясь в другой:

git branch -m <старое имя ветки> <новое имя ветки>

Сливаем изменения из feature-веток

Самое интересное начинается, когда над проектом работают несколько человек одновременно или когда вы параллельно ведёте работу над разными задачами. Давайте имитируем такую ситуацию. Представим, что пока мы наполняли раздел «Подготовка» в ветке feature/basics, коллега (или вы сами) получили срочную новую задачу — добавить раздел про работу с ветками.

Вернитесь в main и создайте ветку для новой задачи:

git switch maingit switch -c feature/branching

Добавьте вторую карточку в index.html — намеренно сделайте это в том же месте, где была первая карточка в другой ветке. Вот нужный фрагмент кода:

      <section class="card">
        <h2>Ветки</h2>
        <ul>
          <li>
            <span class="desc">Создать и перейти (switch)</span>
            <code>git switch -c feature/name</code>
          </li>
          <li>
            <span class="desc">Список локальных веток</span>
            <code>git branch</code>
          </li>
          <li class="old">
            <span class="desc">Создать и перейти (старый способ)</span>
            <code>git checkout -b name</code>
          </li>
        </ul>
      </section>

Зафиксируйте результат:

git add .git commit -m "feat: Добавлена секция веток"

Теперь взгляните на схему Git Graph. Вы увидите, как от одной точки main расходятся две независимые линии и формируют своеобразную рогатку (Fork). В каждой ветке содержится свой набор изменений: feature/basics с разделом «Подготовка» и feature/branching с новым разделом «Ветки».

Когда работа в параллельных ветках завершена, их нужно объединить с main. Воспользуемся командой git merge и сольём изменения из feature/basics с главной веткой:

git switch maingit merge feature/basics

После этого в терминале появится сообщение Fast-forward. Это самый простой сценарий слияния: поскольку в main за это время не появилось новых коммитов, Git переместил указатель основной ветки вперёд — на тот коммит, где находилась feature/basics. То есть фактически никакого объединения не случилось — обновилась лишь позиция main. Если вы теперь откроете index.html в ветке main, в нём появится карточка с разделом «Подготовка».

Разрешаем merge-конфликты и завершаем слияние

Попробуем влить вторую ветку feature/branching в обновлённую main:

git merge feature/branching

Git увидит, что в обеих ветках вы добавили разный код в одно и то же место файла index.html. В таких случаях он не сможет сам определить, какую версию оставить. Поэтому в терминале вы получите сообщение о конфликте слияния:

Автослияние index.html
КОНФЛИКТ (содержимое): Конфликт слияния в index.html
Сбой автоматического слияния; исправьте конфликты, затем зафиксируйте результат

Не пугайтесь такого сообщения — это вполне нормальная ситуация. Если вы откроете index.html, то увидите визуальные маркеры конфликта:

• <<<<<<< HEAD (Current Change) — это код, который уже есть в вашей текущей ветке;
• ======= — разделитель между конфликтующими версиями;
• >>>>>>> feature/branching (Incoming Change) — код из другой ветки.

Если вы вместе с нами используете VS Code, то обратите внимание на кнопки-действия над конфликтующими блоками:

• Accept Current Change — оставить версию из текущей ветки;
• Accept Incoming Change — заменить всё кодом из входящей ветки;
• Accept Both Changes — сохраняет оба блока, поставив их друг за другом;
• Compare Changes — открывает специальный режим сравнения «бок о бок». Это может пригодиться, когда конфликтующих участков много или изменения сложные: так вы сможете детально изучить различия между версиями в отдельном окне, прежде чем решить, какой вариант оставить.

Если вместо VS Code вы используете другой современный редактор, то названия кнопок могут немного отличаться. Но делать они будут то же самое.

Мы хотим, чтобы в шпаргалке остались оба раздела — «Подготовка» и «Ветки». Поэтому жмём кнопку Accept Both Changes, после чего Git самостоятельно уберёт технические маркеры и расположит блоки кода друг за другом.

В редакторе после этого наступит порядок, но для Git конфликт ещё не разрешён, пока вы не сохраните изменения. Переходим в терминал и выполняем команды:

git add index.html

git commit -m "merge: Объединяем разделы подготовки и веток"

Посмотрим на Git Graph: две параллельные линии разработки наконец-то встретились в одной точке слияния. Это означает, что в ветке main собраны все наши изменения, а именно: первоначальная структура проекта, карточка «Подготовка» из ветки feature/basics и карточка «Ветки» из feature/branching.

Удаляем временные ветки и финалим проект

Мы разрешили все конфликты и успешно слили в main все изменения. Поэтому вспомогательные ветки feature/basics и feature/branching больше не нужны. Их можно так и оставить, но в реальных проектах их обычно удаляют. Это необходимо для того, чтобы список веток оставался актуальным и не загромождался устаревшими ссылками, которые уже выполнили свою задачу.

Чтобы удалить локальную ветку, нужно выполнить команду git branch -d. Флаг -d означает delete — он удаляет ветку только в том случае, если все её изменения уже слиты в другую ветку. Это защитная мера, которая предотвращает потерю несохранённой работы. Повторяем команду дважды:

git branch -d feature/basics

git branch -d feature/branching

Если после удаления веток вы посмотрите на Git Graph, то на нём не будет лишних меток, однако вся история изменений останется нетронутой. Также на схеме будут по-прежнему видны характерные петли, которые показывают, где работа разделялась и в какой момент она была объединена с основной линией. Это и есть результат правильной гигиены репозитория: вы избавляетесь от всего лишнего шума и оставляете только актуальный указатель на ветку main.

Мы прошли основные этапы работы с ветками в Git. Теперь вы знаете, как их создавать, переключать, переименовывать, вести параллельную разработку и разрешать возникающие конфликты. Чтобы закрепить материал, скачайте готовые файлы index.html и style.css, добавьте их в редактор и сделайте финальный коммит. После этого сохраните изменения и откройте страницу в браузере, чтобы получить шпаргалку со всеми популярными командами.

Что дальше

В этой статье мы работали с локальными ветками, которые существуют только на вашем компьютере. Однако в реальной разработке почти всегда есть удалённый репозиторий (например, на GitHub), а значит — и удалённые ветки. Основные команды для работы с ними мы добавили в шпаргалку. Вот они:

• Первый пуш новой ветки с привязкой: git push -u origin <branch>
• Показать все ветки (включая удалённые): git branch -a
• Удалить ветку на сервере: git push origin --delete <branch>

Но перед работой с удалёнными ветками мы рекомендуем разобраться, что такое GitHub и как им пользоваться. Вы должны уметь создавать репозитории, отправлять изменения через git push и забирать обновления через git pull. Без этого легко ошибиться: отправить изменения не туда, потерять работу или столкнуться с неожиданными конфликтами. Про GitHub у нас есть отдельный большой материал, и там же есть разделы про работу с удалёнными ветками.

Читайте также:

Что такое GitHub и как им пользоваться