Работа с ветками в Git (git branch)

Введение

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

Основные понятия: о ветке Git и master

Под веткой принято понимать независимую последовательность коммитов в хронологическом порядке. Однако конкретно в Git реализация ветки выполнена как указатель на последний коммит в рассматриваемой ветке. После создания ветки уже новый указатель ссылается на текущий коммит.

Имя основной ветки Git-проекта по умолчанию — master (однако зачастую бывает main, например, в GitHub), она появляется сразу при инициализации репозитория. Эта ветка ничем не отличается от остальных и также ее можно переименовать, но по договоренности master принято считать главной веткой в проекте.

Что делает git branch

Команда git branch — главный инструмент для работы с ветвлением. С ее помощью можно добавлять новые ветки, перечислять и переименовывать существующие и удалять их.

Способы создания веток и переключения между ними

Чтобы в Git добавить ветку мы используем:

$ git branch <name of new branch>

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

$ git checkout <name of branch>

Для того чтобы определить, где сейчас находится разработчик, Git использует специальный указатель HEAD, ссылающийся на текущую локальную ветку. В результате checkout HEAD переместится на иную ветку.

Как с помощью git branch создать ветку и перейти в нее

Чаще всего при создании новой ветки git пользователю необходимо сразу же переключиться на нее. В таком случае стоит использовать:

$ git checkout branch <name of new branch> 

Это будет равносильно:

$ git branch <name of new branch>

$ git checkout <name of new branch>

И также мы получим тот же результат при использовании git checkout с ключом -b:

$ git checkout -b <name of branch>

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

• -r — при использовании этого ключа мы получим список удаленных веток,
• -a — используя этот параметр, в выводе будут удаленные и локальные ветки.

О команде git checkout

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

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

Переключение указателя HEAD на новую ветку
Необходимо сместить указатель, чтобы Git понимал, где сейчас идет работа.

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

После завершения всех перечисленных выше действий можно считать, что мы полностью переключились. Также с помощью checkout можно извлечь отдельный файл (или папку) из другой ветки и получить его, предварительно перейдя в ту ветку, куда вы собираетесь перенести файл. Для этого выполняем:

$ git checkout <name of new branch> -- <path to folder>

Основы ветвления и слияния

Ветвление позволяет разделять рабочий процесс, оптимизировать тестирование и написание нового кода. Однако после того, как разработчик убедился, что написанный им кусок кода готов и его можно отправить к остальной части итоговой версии, удобно переместить его в основную ветку. Такой подход дает возможность получить к концу разработки проекта целый продукт в одном месте.
Для этого в Git предусмотрено слияние — перенос изменений с одной ветки на другую. Однако сливаемая ветка (под этим определением мы подразумеваем ветку, у которой берем изменения для «вливания» их в другую ветвь) никак не меняется и остается в прежнем состоянии. Такие преобразования мы получаем, применив git merge:

$ git merge <name of merged branch>

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

Также стоит упомянуть о существовании ключей, предназначенных специально для работы с конфликтами:

• —abort — прерывает слияние и возвращает все к началу
• —continue — продолжает слияние после разрешения конфликта

Решить конфликт можно двумя способами:

• Вручную разрешить файловый конфликт. Для этого нужно самим изменить файлы, с которыми возникли проблемы. Мы получим файлы такими, какими и представляли их при попытке слияния.
• Выбрать более подходящий файл, а от второго отказаться.

Управление ветками с помощью git branch

Эта команда может немного больше, чем просто в git создавать ветки из текущей. Если запустить ее без параметров:

$ git branch

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

 first_branch
* master
  second_branch

С помощью параметра -v можно получить последний сохраненный коммит в каждой ветке.

$ git branch -v
  first_branch 8fa301b Fix math
* master 225cc2d Merge branch 'first_branch'
  second_branch c56ee12 Refactor code style

Так же существуют опции —merged и —no-merged, с помощью которых можно отфильтровать полученную последовательность веток. То есть мы получим список ответвлений, которые уже были слиты, или, наоборот, ветки, которые еще не прошли через слияние с другими. Выведем ветки, которые уже были слиты с текущей:

$ git branch --merged
  first_branch
* master

Как закоммитить изменения в новую ветку

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

$ git add

$ git commit -m '<information about commit>'

После выполнения последовательности этих команд мы закоммитили изменения в нужной версии программы.

Как запушить в новую ветку

Если мы хотим запушить нашу ветку, то для этого нужно написать:

$ git push origin <name of branch>

Теперь ветка запушена. Если до этого мы уже пушили ее, то произойдет отправка новых коммитов.
В отличии от команды git checkout, при выполнении пуша нет проверки на существование указанной ветки. Это будет значить, что при написании несуществующей ветки git создаст ее автоматически.

Как переименовать ветку

В процессе разработки могут возникнуть ситуации, когда человек хочет по-другому называть уже созданную ветку. Это может быть связано с разными причинами (например, разрабатываемый в данной версии функционал не соответствует названию). Чтобы переименовать ветку применяем:

$ git branch -m <new name of branch>

Однако здесь нужно быть аккуратными, чтобы не перегрузить проект ненужными ветками. Если запушить переименованную ветку, то на сервере появится ветка с новым именем, но и ветка со старым названием тоже останется. Чтобы избежать такой проблемы, необходимо удалить ветку локально и на сервере.

Как удалить ветку

Удаление веток не такой простой процесс, как может показаться. Можно случайно удалить несохраненные изменения в исходном коде, что приведет к нежелательным последствиям. Поэтому здесь нужно действовать осторожно. С операцией удаления над ветками справляется уже привычная команда git branch с параметром -d:

$ git branch -d <name of branch>

Для корректного удаления нужно помнить несколько правил, чтобы не получить ошибки:

• Нельзя удалить ветку, в которой вы находитесь. Git выкинет ошибку и не произведет удаление. Следовательно, нужно перейти на другую ветку.
• Git не позволит удалить ветку, у которой есть несохраненные изменения. Так мы избегаем ситуации, когда часть написанного кода будет безвозвратно утеряна. Если же мы уверены, что изменения в этой версии не нужны и их можно смело удалять, то вместо флага -d используем -D:

$ git branch -D <name of branch>

Соблюдая все условия, нам удастся удалить указанную ветвь.

Работа с ветками на практике

В инструментах для разработки на языках часто есть встроенный функционал, позволяющий работать напрямую с Git. Например, в таких средах разработки как IntelliJ IDEA, PyCharm, PhpStorm, CLine, Rider очень удобно и понятно, как правильно оперировать с разными ветками. Для примера разберем работу в одной из таких сред.

Как работать с ветками в PhpStorm

Справа в нижнем углу расположены вкладки для работы с Git, где и происходит вся настройка ветвления. На этой панели расположено название текущей ветки. При желании создать новую нужно нажать на этот пункт и выбрать New Branch. Для смены ветки — выбрать из списка искомую и кликнуть на Checkout. Для удаления и переименования предусмотрены кнопки Delete и Rename соответственно.

Работа в специальном приложении почти ничем не отличается от работы в консоли, поэтому все полученные знания можно применять независимо от выбранного способа.

Получение информации о состоянии веток

Как просмотреть состояния файлов ветки

Отметим, что при переходе на другую версию, незакоммиченные изменения перенесутся на ветку, куда мы перейдем. Поэтому перед переключением необходимо убедиться, что изменения в текущей ветки уже закоммичены. Для этого подходит git status:

$ git status

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

Как просмотреть истории коммитов ветки

Неоднократно в процессе разработки нужно посмотреть на журнал изменений: для отслеживания развития проекта или для определения коммита, к которому следует вернуться. В таких ситуациях выручает команда git log:

$ git log <keys> --<path>

У данной команды есть множество ключей, используя которые можно получить более конкретную информацию:

• -<number> (равноценно -n=<number>) — показывает последние n коммитов,
• —pretty=<value> (доступные такие значения, как oneline, short, medium, full и другие) ****— форматированный вывод истории,
• -p — выводятся изменения, содержащиеся в коммите,
• —graph — представляет дерево взаимосвязей коммитов в виде ASCII-графа — такой метод использования позволяет получить графическое представление ветвей прямо в консоли,
• —all — на выходе мы получаем историю всех коммитов для всех существующих веток,
• —decorate — показывает, на что ссылаются указатели.

Если нам нужно посмотреть историю для конкретной ветви, то поможет выполнение:

$ git log <keys> <name of parent's branch>..<name of branch>

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

Как просмотреть различия между коммитами

Достаточно часто в ходе разработки какого-либо продукта у разработчика может возникнуть потребность посмотреть разницу между двумя коммитами, прежде чем заливать что-то. Для этого существует git diff:

$ git diff <keys> <path to file> <path to file>

Для этой операции также предусмотрены несколько ключей:

• —diff-filter=<mark> — с помощью этого параметра, изменяя значения меток, можно задать, обновления между какими файлами мы хотим увидеть. Рассмотрим некоторые возможные значения меток:
  • D — покажет удаленные файлы,
  • M — мы получим файлы, модифицированные после последнего коммита.
• —word-diff=color — повышает читабельность полученной информации: слова подсвечиваются зеленым цветом, если они были добавлены, и красным — если были удалены.

Заключение

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