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

Большинство проектов включают две основные ветки – 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-faeture 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 для ежедневного использования.

Если вам интересен Git, у нас для него есть специальный тег.

В этом теге наиболее близкие к этой статье следующие:

• Git для начинающих: основы рабочего процесса и базовые команды
• GitHub Actions: что это и как использовать
  
• Как использовать Git эффективно: налаживаем работу Git workflow
  
• 10 полезных Git команд, которые облегчат работу