Ветвление Git с примерами из реальной жизни
Разбираемся, как использовать ветвление: создание, обновление, удаление и прочие классные штуки.
Часто используемые ветки
Большинство проектов
включают две основные ветки – master
и dev
. Ветка master
используется для продакшна,
а dev
– для тестирования. Когда новые изменения протестированы в ветке
dev
, их можно сливать с веткой master
и после этого
деплоить. Имена ветвей, их количество могут быть другими – это самые
распространённые.
Есть важное правило: вы
не должны работать с этими ветками напрямую. Для любого изменения в программном
проекте надо сначала создать новую ветвь, унаследовавшись от dev
и дать ей имя,
отражающее сделанное изменение.
Теперь перейдём к реальным примерам ветвления Git, встречающимся в повседневной жизни разработчиков программного обеспечения.
Настройка удалённых и локальных веток
Предположим, есть
тестовый репозиторий на GitHub. Перейдём на главную страницу этого репозитория
и щёлкнем по разделу 1 branch
.
Как можно видеть, здесь
только созданная по умолчанию ветка master
. Она сообщает,
что содержимое домашней страницы репозитория загружается при выборе данной ветки.
Вернёмся на главную
страницу и кликнем по выпадающему меню Branch: master
. Если написать dev
и нажать на
появившийся пункт Create branch: dev
, можно создать ветку dev
в своём
удалённом репозитории.
Создание ветки на локальном репозитории
Для просмотра локального репозитория после добавления ветки dev
в удалённый репозиторий,
используется следующая команда:
или такая:
Эта команда выведет в окно терминала локальные ветви.
Чтобы
выйти из списка веток, используйте клавишу q
.
Для просмотра удалённых веток применяется следующая команда:
Получение изменений из удалённого репозитория
Теперь попробуем заставить появиться удалённую ветку dev
. Извлечём все последние
изменения удалённого репозитория:
Теперь
dev
появилась среди других веток, потому что с помощью git fetch
извлекаются
последние актуальные метаданные.
Чтобы
извлечь и скопировать все изменения из удалённого репозитория, нужно использовать команду
git pull
:
Теперь информация о ветке верна. Чтобы просмотреть удалённые и локальные ветки, можно использовать уже известную команду с другим ключом:
Переключение между ветками
Всё готово к разработке, и непосредственно перед началом нам нужно изменить текущую
ветку с master
на dev
. Сделаем это в локальном репозитории с помощью команды:
Как
говорилось ранее, dev
должна быть основной ветвью для разработки и все
действия должны начинаться именно из неё.
CRUD операции с ветками
Создание ветви
Создадим
новую ветвь из ветви dev
:
Снова проверим локальные ветви:
Обновление имени ветки
Чтобы поменять имя существующей ветки, нет необходимости создавать всё сначала т. к. есть специальная команда:
Если вы находитесь в другой ветви, вы всё равно можете переименовать любую из них следующим образом:
Проверим правильность указанных имён:
Коммит ветки
Внесём
изменения в файл README.md
и проверим локальный репозиторий:
Перенесём файл в промежуточную область и сделаем коммит:
Проверяем:
Отправка изменений на удалённый сервер
Теперь можно пушить коммит:
После отправки актуальной информации о ветке в удалённый репозиторий, нужно проверить, всё ли прошло корректно:
Удаление ветки
Если
есть необходимость в удалении ветви, переходим в dev
(или в любую ветку,
которую нужно удалить) и выполняем удаление:
Удаление
завершилось неудачно т. к. удаление локальной ветви с помощью команды git
branch -d
является безопасной операцией. Если ветка имеет статус unpushed или
unmerged , её можно удалить только принудительно:
Как
насчёт удаления remote-ветки? Для этой цели у push есть ключ --delete
:
Проверим:
Видим,
что my-new-branch
очищена от всех локальных и удалённых репозиториев.
Проделаем всё сначала и создадим новую ветку, как «правильные ребята»:
Внесём изменения:
Проверим состояние ветки:
Наблюдаем
изменённый файлик README.md
, коммитим текущее изменение локального репозитория,
добавив файл в промежуточную область:
Пушим результат на удалённый сервер:
Теперь предположим, что ваш
коллега нашёл какой-то баг в коде, исправил его и создал копию данной ветки с
другим именем: fix/my-killer-feature-bug-fix
.
Слияние ветвей
Как обычно, сначала получаем актуальную информацию о репозитории:
Далее ищем ветку, над которой работал коллега:
Теперь можно сливать исправленную ветку с feature/my-killer-feature
с помощью команды git merge
(убедитесь, что
находитесь в нужной ветви).
Проверяем конечный результат:
Заключение
Редакция Библиотеки Программиста надеется, что этот материал поможет вам узнать или укрепить знания о ветвлении в Git для ежедневного использования.
Если вам интересен Git, у нас для него есть специальный тег.
В этом теге наиболее близкие к этой статье следующие:
- Git для начинающих: основы рабочего процесса и базовые команды
- GitHub Actions: что это и как использовать
- Как использовать Git эффективно: налаживаем работу Git workflow
- 10 полезных Git команд, которые облегчат работу