-
Переход на ветку main и обновление:
- Перед началом работы над новой функциональностью переходим на ветку
main
и стягиваем последние изменения.git checkout main git pull origin main
- Перед началом работы над новой функциональностью переходим на ветку
-
Создание ветки для новой функциональности:
- Создаем новую ветку для разработки функциональности с подходящим названием.
git checkout -b details-page
- Создаем новую ветку для разработки функциональности с подходящим названием.
-
Разработка в новой ветке:
- Работаем в ветке
details-page
, вносим необходимые изменения и коммитим их.# Работаем над проектом, затем коммитим изменения git add . git commit -m "Implemented details page functionality"
- Работаем в ветке
-
Создание pull request (PR):
- После завершения работы создаем pull request для слияния изменений из ветки
details-page
вmain
. - Отправляем PR на проверку ревьюеру.
- После завершения работы создаем pull request для слияния изменений из ветки
-
Проверка и мержинг PR:
- Ревьюер проверяет код, оставляет замечания или одобряет изменения.
- Только ревьюер имеет право мержить PR после проверки.
-
Переход на ветку main после мержинга:
- После успешного мержинга PR ревьюером, переходим обратно на ветку
main
.git checkout main
- После успешного мержинга PR ревьюером, переходим обратно на ветку
-
Удаление ветки:
- Удаляем локальную и удаленную ветку
details-page
, если больше не требуется.git branch -d details-page git push origin --delete details-page
- Удаляем локальную и удаленную ветку
Таким образом, поддерживается четкая структура работы с ветками, и контроль за качеством кода осуществляется через процесс ревью и мержинга пулл реквестов только после проверки.