Git Strategy — Partizap Frontend

Инфраструктура

Сервер	Ресурсы	Роль
VPS 1 (85.239.48.136)	2 vCPU, 4 GB RAM, 38 GB disk (18%)	nginx reverse proxy
VPS 2 (192.168.0.5)	6 vCPU, 16 GB RAM, 38 GB disk (73%)	GitLab 18.8 + Runner + YouTrack + dev/prod containers

Runner: shell executor, concurrent = 1 (одна джоба за раз).

Ветки

feature/TASK-123-описание  ──┐
fix/TASK-456-описание      ──┤──→  develop  ──→  main  ──→  v* tag
hotfix/critical-fix        ──┘       ↑           ↑           ↑
                                  auto CI     sem-release  manual deploy
                                  auto deploy              partizap.ru
                                  dev.partizap.ru

Постоянные ветки

Ветка	Назначение	CI	Деплой
`develop`	Интеграция фич, dev-стенд	validate → build → deploy → e2e → cleanup	dev.partizap.ru (auto)
`main`	Стабильный релизный код	semantic-release (создаёт тег `v*`)	—

Временные ветки

Паттерн	Когда	Пример
`feature/<ticket>-<описание>`	Новая функциональность	`feature/XSUD-123-catalog-filters`
`fix/<ticket>-<описание>`	Багфикс	`fix/XSUD-456-login-redirect`
`hotfix/<описание>`	Срочный фикс в прод	`hotfix/csrf-token-expired`

Жизненный цикл задачи

1. Начало работы

bash

git checkout develop
git pull origin develop
git checkout -b feature/XSUD-123-catalog-filters

2. Разработка

Коммиты в feature-ветку — формат Conventional Commits:

bash

git commit -m "feat(catalog): add price range filter"
git commit -m "fix(catalog): handle empty filter state"
git commit -m "test(catalog): add filter composable tests"

Промежуточные коммиты могут быть любыми — при squash merge они сольются в один.

3. Локальная проверка перед MR

bash

npm run lint
npm run typecheck
npm run test:run

CI на feature-ветках не запускается — экономия ресурсов сервера.

4. Merge Request в develop

Создать MR в GitLab: feature/XSUD-123-catalog-filters → develop
Squash commits — включить (по умолчанию)
Заголовок MR = финальный commit message: feat(catalog): add price range filter
Описание MR: что сделано, ссылка на задачу в YouTrack
После approve — Merge (squash)

5. Автоматическая валидация + деплой

После мержа в develop автоматически:

lint ──┐
       ├── (параллельно, но concurrent=1 → последовательно)
typecheck ─┤
       │
test ──┘
       ↓
build:dev (docker build)
       ↓
deploy:dev (dev.partizap.ru)
       ↓
test:e2e (Playwright smoke)
       ↓
cleanup:dev (docker prune)

6. Релиз в прод

bash

git checkout main
git merge develop    # fast-forward или merge commit
git push origin main

Автоматически:

semantic-release анализирует коммиты с момента последнего тега
Определяет версию по conventional commits (feat: → minor, fix: → patch)
Создаёт тег v1.2.0, обновляет CHANGELOG.md
Тег триггерит build:prod → ручная кнопка deploy:prod

7. Hotfix

Для срочных фиксов в прод:

bash

git checkout main
git checkout -b hotfix/csrf-token-expired
# ... fix ...
git commit -m "fix(auth): handle expired CSRF token on session timeout"
git checkout develop && git merge hotfix/csrf-token-expired
git checkout main && git merge hotfix/csrf-token-expired
git push origin develop main
# semantic-release создаст patch-версию

Squash Merge — почему

Без squash	Со squash
`wip: начал фильтры`	`feat(catalog): add price range filter`
`fix: забыл импорт`	(один чистый коммит)
`wip: доделал`
`fix: линтер`

Преимущества squash для этого проекта:

Чистая история develop — один коммит = одна задача
Предсказуемый semantic-release — один feat: коммит = один minor bump, без дублей
Простой revert — git revert <sha> откатывает целую фичу
История фичи сохраняется в MR (все промежуточные коммиты видны там)

Настройка в GitLab

Settings → Merge Requests:

Squash commits when merging: Encourage или Require
Merge method: Merge commit (не fast-forward — сохраняет видимость мержей)

Conventional Commits

Финальный коммит (заголовок MR при squash) обязан следовать формату:

<type>(<scope>): <описание>

Типы и влияние на версию

Тип	Версия	Пример
`feat`	minor (1.0 → 1.1)	`feat(catalog): add price range filter`
`fix`	patch (1.0.0 → 1.0.1)	`fix(auth): handle expired session`
`perf`	patch	`perf(catalog): cache category tree`
`ci`	patch	`ci: add memory limit to docker build`
`revert`	patch	`revert: feat(catalog): add price range filter`
`chore`	нет релиза	`chore: update dependencies`
`docs`	нет релиза	`docs: update API reference`
`style`	нет релиза	`style: fix linting errors`
`refactor`	нет релиза	`refactor(auth): extract validation logic`
`test`	нет релиза	`test(catalog): add filter tests`
`feat!` или `BREAKING CHANGE:`	major (1.x → 2.0)	`feat!: redesign auth flow`

Scope (опционально)

Scope = FSD-слайс или модуль: auth, catalog, product, admin, geo, ci, deps.

CI Pipeline — что происходит на каждом этапе

При push в `develop`

Стадия	Что делает	Время*	Ресурсы
lint	`npm ci && npm run lint` в Docker alpine	~2 мин	~400 MB disk (tmp)
typecheck	`npm ci && npm run typecheck`	~3 мин	~400 MB disk (tmp)
test	`npm ci && npm run test:run`	~2 мин	~400 MB disk (tmp)
build:dev	`docker build` Nuxt app	~3-5 мин	~1 GB RAM, ~1.5 GB disk
deploy:dev	`docker compose up -d`	~10 сек	—
test:e2e	Playwright smoke (13 tests)	~2 мин	~1 GB disk (Playwright image)
cleanup:dev	`docker builder prune`, `image prune`	~10 сек	освобождает место

*Примерное время при concurrent=1 (последовательно).

Итого: ~12-15 минут от push до деплоя + e2e.

При push в `main`

Только semantic-release (~1-2 мин). Никакой валидации — код уже проверен в develop.

При теге `v*`

build:prod (auto) → deploy:prod (manual кнопка) → cleanup:prod.

Влияние на ресурсы сервера

Git — пренебрежимо

Репозиторий: 7.7 MB. Даже 100 веток и 10 000 коммитов без squash → ~50-100 MB за год
Ветки — указатели (41 байт каждый), не копии файлов
Вывод: squash/no-squash не влияет на ресурсы сервера ощутимо

CI — основной потребитель

Ресурс	Потребление	Ограничение
RAM	~1 GB пик (docker build)	16 GB total, 8.7 GB available — ОК
Disk	~1.5 GB build cache, ~500 MB per image	11 GB free — мало, cleanup обязателен
CPU	100% во время build (1-2 ядра)	6 vCPU — ОК

Удаление веток

Автоматически

GitLab Settings → Merge Requests → Delete source branch by default: включить.

После мержа MR feature-ветка удаляется автоматически. Не захламляет список веток.

Вручную (периодически)

bash

# Удалить локальные ветки, смерженные в develop
git checkout develop
git branch --merged | grep -v 'develop\|main' | xargs git branch -d

# Синхронизировать с remote
git fetch --prune

Чеклист: новая задача

1. [ ] git checkout develop && git pull
2. [ ] git checkout -b feature/TICKET-описание
3. [ ] Разработка + коммиты (любой формат)
4. [ ] Локально: npm run lint && npm run typecheck && npm run test:run
5. [ ] git push origin feature/TICKET-описание
6. [ ] Создать MR → develop (squash, conventional commit в заголовке)
7. [ ] Code review → Merge
8. [ ] CI: validate → build → deploy → e2e (автоматически)
9. [ ] Проверить на dev.partizap.ru
10. [ ] Ветка удалена автоматически

Чеклист: релиз в прод

1. [ ] develop стабилен, e2e проходят
2. [ ] git checkout main && git merge develop && git push
3. [ ] semantic-release создаёт тег v*
4. [ ] В GitLab: нажать Manual deploy:prod
5. [ ] Проверить partizap.ru

Git Strategy — Partizap Frontend ​

Инфраструктура ​

Ветки ​

Постоянные ветки ​

Временные ветки ​

Жизненный цикл задачи ​

1. Начало работы ​

2. Разработка ​

3. Локальная проверка перед MR ​

4. Merge Request в develop ​

5. Автоматическая валидация + деплой ​

6. Релиз в прод ​

7. Hotfix ​

Squash Merge — почему ​

Настройка в GitLab ​

Conventional Commits ​

Типы и влияние на версию ​

Scope (опционально) ​

CI Pipeline — что происходит на каждом этапе ​

При push в develop ​

При push в main ​

При теге v* ​

Влияние на ресурсы сервера ​

Git — пренебрежимо ​

CI — основной потребитель ​

Рекомендации по экономии ресурсов ​

Удаление веток ​

Автоматически ​

Вручную (периодически) ​

Чеклист: новая задача ​

Чеклист: релиз в прод ​

Git Strategy — Partizap Frontend

Инфраструктура

Ветки

Постоянные ветки

Временные ветки

Жизненный цикл задачи

1. Начало работы

2. Разработка

3. Локальная проверка перед MR

4. Merge Request в develop

5. Автоматическая валидация + деплой

6. Релиз в прод

7. Hotfix

Squash Merge — почему

Настройка в GitLab

Conventional Commits

Типы и влияние на версию

Scope (опционально)

CI Pipeline — что происходит на каждом этапе

При push в `develop`

При push в `main`

При теге `v*`

Влияние на ресурсы сервера

Git — пренебрежимо

CI — основной потребитель

Рекомендации по экономии ресурсов

Удаление веток

Автоматически

Вручную (периодически)

Чеклист: новая задача

Чеклист: релиз в прод