Командный workflow: feature branch → PR → merge

Собираем всё изученное в один отлаженный процесс, по которому работают реальные команды.

Feature Branch Workflow — процесс, в котором каждая задача делается в отдельной ветке и попадает в main только через Pull Request.

Главное правило: main всегда рабочая

В основе процесса лежит идея: ветка main всегда содержит стабильную, рабочую версию. Напрямую в неё никто не пушит. Вся новая работа ведётся в отдельных ветках и вливается только после ревью. Часто main ещё и защищают настройками GitHub (branch protection), чтобы туда физически нельзя было запушить мимо PR.

Пошаговый цикл одной задачи

1. Обновите локальную main, чтобы стартовать со свежей базы:

git switch main
git pull

2. Создайте ветку под задачу с понятным именем:

git switch -c feature/registration-form

3. Работайте: делайте небольшие атомарные коммиты.

git add .
git commit -m "Добавить разметку формы регистрации"

4. Опубликуйте ветку на GitHub:

git push -u origin feature/registration-form

5. Откройте Pull Request, пройдите ревью, при необходимости дорабатывайте и пушите новые коммиты.

6. После одобрения слейте PR в main и удалите ветку (GitHub предложит кнопку Delete branch). Локально подчистите:

git switch main
git pull
git branch -d feature/registration-form

Именование веток

Команды договариваются о схеме имён, чтобы по названию было понятно назначение ветки:

`feature/...`	новая функциональность
`fix/...` или `bugfix/...`	исправление бага
`hotfix/...`	срочная правка в продакшене

Поддерживайте ветку свежей

Если задача длится долго, main уйдёт вперёд. Периодически подтягивайте её в свою ветку, чтобы конфликты при финальном слиянии были минимальны:

git switch feature/registration-form
git merge main

Почему это работает

Рабочая ветка изолирует незаконченный код от стабильной версии.
PR обеспечивает ревью — баги ловятся до попадания в main.
История прозрачна: видно, какая задача каким PR решена.

Защита ветки main

Чтобы правило «в main только через PR» нельзя было нарушить даже случайно, на GitHub настраивают branch protection. Тогда прямой push в main запрещается технически, а слить PR можно лишь при выполнении условий: пройденном ревью, зелёных автопроверках. Это превращает договорённость в гарантию — человеческий фактор больше не сломает основную ветку.

Другие модели ветвления

Feature Branch Workflow — самый распространённый, но не единственный подход. Существуют, например, Git Flow (с отдельными ветками develop, release, hotfix) и Trunk-Based Development (почти всё вливается прямо в одну ветку очень маленькими порциями). Какой выбрать — зависит от размера команды и частоты релизов. Начинать же стоит именно с простого feature branch: он покрывает потребности большинства проектов.

Итог

Цикл: обнови main → ветка под задачу → коммиты → push → PR → ревью → merge → удалить ветку.
В main не пушат напрямую; она всегда должна быть рабочей.
Долгие ветки регулярно обновляйте из main, чтобы избежать больших конфликтов.