Часто используемые ветки
Большинство проектов
включают две основные ветки – 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, у нас для него есть специальный тег.
В этом теге наиболее близкие к этой статье следующие:
Комментарии