Одной из самых нужных функций Git (и других систем контроля версий тоже) является ветвление. Это возможность открывать новый канал для особого набора изменений, например, для исправления бага, релаизации новой фичи или каких-нибудь экспериментов — и все это без вреда для основной кодовой базы. Сайт proglib.io представил свой перевод статьи о ветвлении — «Git Branching Tutorial with Real-World Examples«.


Разбираемся, как использовать ветвление: создание, обновление, удаление и прочие классные штуки.
Часто используемые ветки
Большинство проектов включают две основные ветки – master
и dev
. Ветка master
используется для продакшна, а dev
– для тестирования. Когда новые изменения протестированы в ветке dev
, их можно сливать с веткой master
и после этого деплоить. Имена ветвей, их количество могут быть другими – это самые распространённые.
Есть важное правило: вы не должны работать с этими ветками напрямую. Для любого изменения в программном проекте надо сначала создать новую ветвь, унаследовавшись от dev
и дать ей имя, отражающее сделанное изменение.
Теперь перейдём к реальным примерам ветвления Git, встречающимся в повседневной жизни разработчиков программного обеспечения.
Настройка удалённых и локальных веток
Предположим, есть тестовый репозиторий на GitHub. Перейдём на главную страницу этого репозитория и щёлкнем по разделу 1 branch
.


Как можно видеть, здесь только созданная по умолчанию ветка master
. Она сообщает, что содержимое домашней страницы репозитория загружается при выборе данной ветки.
Вернёмся на главную страницу и кликнем по выпадающему меню Branch: master
. Если написать dev
и нажать на появившийся пункт Create branch: dev
, можно создать ветку dev
в своём удалённом репозитории.


Создание ветки на локальном репозитории
Для просмотра локального репозитория после добавления ветки dev
в удалённый репозиторий, используется следующая команда:
$git branch
или такая:
$git branch –-list


Эта команда выведет в окно терминала локальные ветви.


Чтобы выйти из списка веток, используйте клавишу q
.
Для просмотра удалённых веток применяется следующая команда:
$git branch –r


Получение изменений из удалённого репозитория
Теперь попробуем заставить появиться удалённую ветку dev
. Извлечём все последние изменения удалённого репозитория:
$git fetch –all


Теперь dev
появилась среди других веток, потому что с помощью git fetch
извлекаются последние актуальные метаданные.


Чтобы извлечь и скопировать все изменения из удалённого репозитория, нужно использовать команду git pull
:
$git pull origin dev (ключевое слово origin указывает на удаленный репозиторий)
Теперь информация о ветке верна. Чтобы просмотреть удалённые и локальные ветки, можно использовать уже известную команду с другим ключом:
$git branch –a


Переключение между ветками
Всё готово к разработке, и непосредственно перед началом нам нужно изменить текущую ветку с master
на dev
. Сделаем это в локальном репозитории с помощью команды:
$git checkout dev


Как говорилось ранее, dev
должна быть основной ветвью для разработки и все действия должны начинаться именно из неё.
CRUD операции с ветками
Создание ветви
Создадим новую ветвь из ветви dev
:
$git branch my-new-faeture


Снова проверим локальные ветви:


Обновление имени ветки
Чтобы поменять имя существующей ветки, нет необходимости создавать всё сначала т. к. есть специальная команда:
$git branch -m my-bug-fix
Если вы находитесь в другой ветви, вы всё равно можете переименовать любую из них следующим образом:
$git branch -m my-new-feature my-new-feature
Проверим правильность указанных имён:


Коммит ветки
Внесём изменения в файл README.md
и проверим локальный репозиторий:
$git status


Перенесём файл в промежуточную область и сделаем коммит:
$git add README.md $git commit -m "my first commit"


Проверяем:


Отправка изменений на удалённый сервер
Теперь можно пушить коммит:
$git push origin my-new-branch


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


Удаление ветки
Если есть необходимость в удалении ветви, переходим в dev
(или в любую ветку, которую нужно удалить) и выполняем удаление:
$git checkout dev $git branch -d my-new-branch


Удаление завершилось неудачно т. к. удаление локальной ветви с помощью команды git branch -d
является безопасной операцией. Если ветка имеет статус unpushed или unmerged , её можно удалить только принудительно:
$git branch -D my-new-branch


Как насчёт удаления remote-ветки? Для этой цели у push есть ключ --delete
:
$git push origin --delete my-new-branch


Проверим:


Видим, что my-new-branch
очищена от всех локальных и удалённых репозиториев.
Проделаем всё сначала и создадим новую ветку, как «правильные ребята»:


Внесём изменения:


Проверим состояние ветки:
$git status


Наблюдаем изменённый файлик README.md
, коммитим текущее изменение локального репозитория, добавив файл в промежуточную область:
$git add README.md $git commit -m "my killer feature"


Пушим результат на удалённый сервер:
$git push origin feature/my-killer-feature


Теперь предположим, что ваш коллега нашёл какой-то баг в коде, исправил его и создал копию данной ветки с другим именем: fix/my-killer-feature-bug-fix
.
Слияние ветвей
Как обычно, сначала получаем актуальную информацию о репозитории:


Далее ищем ветку, над которой работал коллега:


Теперь можно сливать исправленную ветку с feature/my-killer-feature
с помощью команды git merge
(убедитесь, что находитесь в нужной ветви).
$git merge origin/fix/my-killer-feature-fix


Проверяем конечный результат:


Заключение
Надеемся, что этот материал поможет вам узнать или укрепить знания о ветвлении в Git для ежедневного использования.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]