При работе с удаленным репозиторием Git, вам необходимо придерживаться регламента, чтобы возникало меньше конфликтов при merg’ах, легче было отслеживать и дебажить ошибки.
Основные ветки
Существет две основные ветки:
- Main или master: production-ветка, которая всегда должна быть стабильной и содержать готовый к развертыванию код.
- Dev: ветка для разработки и тестирования
Релизные ветки
Также рекомендую отслеживать версии вашего приложения/сервиса/т.д. и создавать релизные ветки.
Такие ветки в случае критических проблем (например, упал прод и быстро пофиксить не получается) помогают быстро восстановить последнюю рабочую версию, чтобы ваш production не лежал, пока вы исправляете проблемы.
Обычно такие ветки именуются по принципу: release-1.0.0.
Где первая цифра это новые изменения, которые не совместимы с предыдущим кодом, вторая — это была создана новая, крупная фича, а третья — это исправленые баги.
Типы веток для разработки
- feature/имя-фичи *
- bugfix/имя-багфикса *
- hotfix/имя-фикс-вашей-проблемы *
* Название рекомендуется делать лаконичным и отражающим суть задачи.
Например: создаем форму заявки, ветка — feature/newOrderForm
Описание веток
feature/*name* — ветка для создания/внедрения нового функционала (или логики) (например: Разработали компонент квиза)
bugfix/*name* — ветка для исправления не критичных багов, которые не ломают приложение (например: на мобильных устройствах текст наезжает на заголовок)
hotfix/*name* — ветка для исправления критичных багов, которые ломают работы приложения на production (например: перестала отправляться форма заявки, в мобильной версии уезжает кнопка отправки формы)
Процесс создания веток
Основная работа ведется с ветками feature/*name* и bugfix/*name* эти ветки всегда создаются от dev ветки.
Экстренная работа ведется с ветками hotfix/*name* и эти ветки всегда создаются от актуальной main (или master) ветки.
Рецензирование кода
- Pull Request (PR) в релизную ветку создает лид
- Комментарий к коммиту должен быть полный: что конкретно было реализовано (плохо: Поправил баги. хорошо: исправил ошибку отправки формы в шаблоне кейса)
- Для каждой подзадачи создаем отдельный коммит (например: задача реализовать форму отправки заявки. Создали обработчик валидации — закоммитили и запушили, создали форму и верстку — закоммитили и запушили. И т.д)
Итог
По опыту работы, такая система поначалу кажется сложной и излишней, особенно на маленьких проектах.
Но это как тренировка для спортсмена, когда вы попадете в большой проект, вам будет легко, так как вы уже работали по такой системе.
У вас будет меньше проблем конфликтов при merg’ах файлов и в целом совместной работе в команде, будет легче откатывать изменения при необходимости и «вырезать» ненужные коммиты.
