Ответ
В проектах на Node.js мы обычно адаптируем стратегию под размер команды и цикл релизов.
Для средних/крупных проектов с регулярными релизами мы используем модифицированный GitFlow:
main(master) — всегда отражает состояние production.develop— основная ветка для интеграции новой функциональности.feature/*— создаются отdevelopдля разработки новой фичи. Например,feature/user-auth.release/*— ветка для финального тестирования и подготовки к релизу, создается отdevelop. Сюда вносятся только исправления багов.hotfix/*— создаются отmainдля срочных исправлений в production, затем мерджатся и вmain, и вdevelop.
Процесс для новой фичи:
# Создаем ветку от актуальной develop
$ git checkout -b feature/add-payment-webhook develop
# Весь код пишется, коммитится и пушится в эту ветку
# После код-ревью и успешных проверок CI...
$ git checkout develop
$ git merge --no-ff feature/add-payment-webhook
$ git branch -d feature/add-payment-webhookДля небольших сервисов или команд часто переходим на более простой GitHub Flow / Trunk-Based Development:
- Есть одна долгоживущая ветка
main. - Вся разработка ведется в короткоживущих feature-ветках, которые через Pull Request мерджатся в
main. - Каждый мердж в
mainавтоматически деплоится в staging-окружение. Это отлично сочетается с CI/CD пайплайнами в GitHub Actions.
Ключевое правило: Ветка main всегда должна быть в деплоябельном состоянии.
Ответ 18+ 🔞
Слушай, а вот это реально интересный вопрос, про который можно дохуя спорить. Тут всё зависит от того, какой у тебя проект и сколько народу в нём ковыряется. Если команда большая и релизы выходят по расписанию, как поезда, то без нормальной структуры — просто пиздец наступит.
Для средних и крупных проектов, где всё серьёзно, мы обычно юзаем доработанный GitFlow. Это, блядь, как конвейер на заводе, только для кода.
main(или старый добрыйmaster) — это святое. Тут лежит ровно то, что сейчас в продакшене. Трогать можно только в случае пожара.develop— основная помойка, куда стекается весь новый функционал. Тут всегда чуть-чуть бардак, но рабочий.feature/*— вот эти ветки создаются отdevelop, когда нужно запилить какую-то новую хрень. Типаfeature/user-auth. Всё делаешь там, никому не мешаешь.release/*— а это уже ветка для причёсывания перед выходом в свет. Создаётся отdevelop, когда фичи готовы. Тут только баги чиним, новых фич не лепим!hotfix/*— это наш пожарный выход. Если в продакшене пиздец, ветка создаётся прямо отmain, чтобы быстро залатать дыру. Потом правки надо не забыть впихнуть и вdevelop, а то опять наебнёшься.
Как это выглядит на практике, когда делаешь новую фичу:
# Отпочковываешься от develop, как грибок
$ git checkout -b feature/add-payment-webhook develop
# Ты хуяришь код, коммитишь, пушишь — живёшь в этой ветке.
# Прошло код-ревью, все тесты зелёные...
$ git checkout develop
$ git merge --no-ff feature/add-payment-webhook
$ git branch -d feature/add-payment-webhook # И выкидываешь отработанный материалА вот для мелких сервисов или когда команда из двух с половиной человек — этот GitFlow это просто овердохуища бюрократии. Тут лучше GitHub Flow или Trunk-Based Development.
- Одна главная ветка —
main. И всё. - Вся разработка — в коротких feature-ветках. Сделал задачу — создал Pull Request, обсудили, вмерджил в
main. - И самое офигенное: каждый такой мердж в
mainможно настроить так, чтобы он автоматом выкатывался на тестовое окружение. С GitHub Actions это делается вообще в пару кликов.
Главный принцип, без которого нихуя не получится: Ветка main должна быть всегда готова к деплою. Никакого «ой, я тут накосячил, но вмерджил, потому что deadline». Если сломал — чини сразу, ёпта. Иначе будет тебе хиросима, а не релиз.
