List Issues Suggestions1 Discussions Insights

Compare versions

From:To:

+14−12

# Зачем промежуточная веткаAdded

Зачем промежуточная ветка

В простой схеме фичи льются сразу в main. Пока разработчик один, это работает. Как только появляется необходимость проверить несколько фич вместе до выкатки, нужна промежуточная ветка.

Здесь она называется demo. В других проектах встретишь develop, development или staging — суть одна.

code

1feature/твоя-фича → demo → main

2 первый PR второй PR

3 (ревью) (релиз)

Главное отличие от простой схемы: два pull request вместо одного, и ветка ответвляется от demo, а не от main.

## Как оформлять коммитыAdded

Как оформлять коммиты

Полная форма сообщения выглядит так:

code

1тип(область): описание в повелительном наклонении

Пять правил:

Тип — feat, fix, docs, style, refactor, test, chore.
Повелительное наклонение — «добавь», а не «добавил».
Описывай ЧТО сделано, а не КАК.
Первая строка до 50 символов.
Подробности — после пустой строки.

Примеры по-русски:

yaml

1feat: добавлен модуль авторизации

2fix: исправлен баг с регистрацией пользователя

3docs: обновлена документация API

4refactor: переработка модуля платежей

5test: добавлены тесты для API эндпоинтов

6chore: обновлены зависимости проекта

Примеры по-английски:

yaml

1feat: add user authentication via JWT

2fix: resolve database connection timeout

3refactor: optimize course search algorithm

4test: add integration tests for payment module

5chore: upgrade FastAPI to v0.100.0

Язык выбирает команда — важно только, чтобы в одном проекте он был один.

## Что писать в скобочкахAdded

Что писать в скобочках

Скобки после типа — это область изменения (scope). Одно слово: какой части проекта касается коммит.

code

1fix(git): успешный push не становится ошибкой

2chore(deps): закрыты уязвимости ip-address и fast-uri

3fix(ui): длинные названия больше не распирают мобильную вёрстку

4feat(mcp): точечная правка списка

5fix(cache): закрытие списка отзывает его у общего кеша сразу

6feat(safety): разрушительная команда не попадает в исполняемые

Прочитав такую строку, ты понимаешь куда смотреть, ещё не открыв диф. Без области — «fix: исправлен баг» — приходится лезть в коммит, чтобы понять, о чём он вообще.

Правила для области:

Правило	Как	Как не надо
Одно слово, строчными	`fix(auth)`	`fix(Модуль Авторизации)`
Часть системы, а не файл	`fix(cache)`	`fix(redis_client.py)`
Из устоявшегося набора	`api`, `ui`, `db`, `auth`, `deps`	каждый раз новое слово
Не дублирует тип	`feat(cart)`	`feat(feature)`

Набор областей у проекта конечный: обычно 5–15 штук. Их стоит один раз выписать в CONTRIBUTING.md и дальше выбирать из списка, а не сочинять на ходу. Иначе через полгода в истории будет auth, authorization, authz и users-auth — и польза от области пропадёт.

Область необязательна. Если изменение общее и не привязано к части системы — пиши без скобок: chore: обновлены зависимости. Пустые скобки fix(): ... — ошибка, так не пишут.

Ломающее изменение помечается восклицательным знаком после скобок:

code

1feat(api)!: убран устаревший эндпоинт /v1/users

Это сигнал: у того, кто пользуется твоим кодом, после обновления что-то сломается.

Added

Обновить demo и ответвиться от неёAdded

bash

1git switch demo

2git pull origin demo

3git switch -c feature/your-name-of-feature

Ключевое: ветка создаётся от demo, а не от main. Ответвишься от main — получишь конфликты со всем, что уже влили в demo до тебя.

git switch demo && git pull origin demo

Закоммитить измененияAdded

bash

1git add .

2git commit -m "feat(cart): добавлено удаление товара из корзины"

Перед git add . всегда смотри git status — точка забирает всё, включая то, что ты не собирался коммитить.

git status

Conventional Commits по-русски

Перед push поднять ветку над demo через rebaseAdded

bash

1git switch demo

2git pull origin demo

3git switch feature/your-name-of-feature

4git rebase demo

Что делает rebase: берёт твои коммиты и прикладывает их заново поверх свежего demo — как будто ты только что ответвился. История остаётся прямой, без лишнего коммита слияния.

Правило безопасности: rebase переписывает историю. Делай его только со своей веткой, которую никто больше не трогает. Никогда — с demo или main.

Если что-то пошло не так: git rebase --abort.

git rebase demo

git rebase — документация

Первый PR: ветка в demoAdded

bash

1git push origin feature/your-name-of-feature

Дальше на GitHub жмёшь New Pull Request и внимательно выбираешь направление:

base — demo (КУДА льём)
compare — feature/your-name-of-feature (ОТКУДА льём)

Затем описание и ревьюеры.

Если перепутать base и compare местами, PR предложит влить demo в твою ветку — то есть наоборот.

git push origin feature/your-name-of-feature

Протестировать на demoAdded

После мержа фича живёт в demo рядом с чужими. Это тот самый момент, ради которого вся схема и затевалась.

Второй PR: demo в mainAdded

Когда на demo всё сошлось, создаётся второй pull request:

base — main
compare — demo

В описании перечисляются все изменения, которые уйдут в прод. Дальше — подтверждение от тимлида.

Этот PR делает не автор фичи, а тот, кто выпускает релиз.

Added

## Когда эта схема нужна, а когда нетAdded

Когда эта схема нужна, а когда нет

Ситуация	Схема
Один разработчик, выкатываешь когда готово	`feature/` → `main`, один PR
Несколько разработчиков, нужно проверять фичи вместе	`feature/` → `demo` → `main`
Есть отдельный стенд для тестирования	точно с `demo`

Не бери сложную схему на вырост. Два PR на каждую правку в одиночном проекте — это ритуал, а не польза. Перейти от простой схемы к этой легко, обратно — тоже.

# Зачем промежуточная веткаRemoved

# Зачем промежуточная ветка В простой схеме фичи льются сразу в `main`. Пока разработчик один, это работает. Как только появляется необходимость **проверить несколько фич вместе** до выкатки, нужна промежуточная ветка. Здесь она называется `demo`. В других проектах встретишь `develop`, `development` или `staging` — суть одна. ``` feature/твоя-фича → demo → main PR ℕ1 PR ℕ2 (ревью) (релиз) ``` **Главное отличие от простой схемы:** два pull request вместо одного, и ветка ответвляется от `demo`, а не от `main`.

## Как оформлять коммитыRemoved

## Как оформлять коммиты Пять правил: 1. **Префикс** — `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`. 2. **Повелительное наклонение** — «добавь», а не «добавил». 3. **Описывай ЧТО сделано, а не КАК.** 4. **Первая строка до 50 символов.** 5. **Подробности** — после пустой строки. **Примеры по-русски:** ``` feat: добавлен модуль авторизации fix: исправлен баг с регистрацией пользователя docs: обновлена документация API refactor: переработка модуля платежей test: добавлены тесты для API эндпоинтов chore: обновлены зависимости проекта ``` **Примеры по-английски:** ``` feat: add user authentication via JWT fix: resolve database connection timeout refactor: optimize course search algorithm test: add integration tests for payment module chore: upgrade FastAPI to v0.100.0 ``` Язык выбирает команда — важно только, чтобы в одном проекте он был один.

Обновить demo и ответвиться от неёRemoved

```bash git switch demo git pull origin demo git switch -c feature/your-name-of-feature ``` **Ключевое:** ветка создаётся от `demo`, а **не** от `main`. Ответвишься от `main` — получишь конфликты со всем, что уже влили в `demo` до тебя.

Закоммитить измененияRemoved

```bash git add . git commit -m "feat: описание изменения" ``` Перед `git add .` всегда смотри `git status` — точка забирает всё, включая то, что ты не собирался коммитить.

Перед push поднять ветку над demo через rebaseRemoved

```bash git switch demo git pull origin demo git switch feature/your-name-of-feature git rebase demo ``` **Что делает rebase:** берёт твои коммиты и прикладывает их заново поверх свежего `demo` — как будто ты только что ответвился. История остаётся прямой, без лишнего коммита слияния. **Правило безопасности:** rebase **переписывает историю**. Делай его только со своей веткой, которую никто больше не трогает. Никогда — с `demo` или `main`. Если что-то пошло не так: `git rebase --abort`.

PR ℕ1: ветка → demoRemoved

```bash git push origin feature/your-name-of-feature ``` Дальше на GitHub жмёшь **New Pull Request** и внимательно выбираешь направление: - **base** — `demo` (КУДА льём) - **compare** — `feature/your-name-of-feature` (ОТКУДА льём) Затем описание и ревьюеры. Если перепутать base и compare местами, PR предложит влить `demo` в твою ветку — то есть наоборот.

Протестировать на demoRemoved

После мержа фича живёт в `demo` рядом с чужими. Это тот самый момент, ради которого вся схема и затевалась.

PR ℕ2: demo → mainRemoved

Когда на `demo` всё сошлось, создаётся второй pull request: - **base** — `main` - **compare** — `demo` В описании перечисляются **все** изменения, которые уйдут в прод. Дальше — подтверждение от тимлида. Этот PR делает не автор фичи, а тот, кто выпускает релиз.

Removed

## Когда эта схема нужна, а когда нетRemoved

## Когда эта схема нужна, а когда нет | Ситуация | Схема | |---|---| | Один разработчик, выкатываешь когда готово | `feature/` → `main`, один PR | | Несколько разработчиков, нужно проверять фичи вместе | `feature/` → `demo` → `main` | | Есть отдельный стенд для тестирования | точно с `demo` | Не бери сложную схему на вырост. Два PR на каждую правку в одиночном проекте — это ритуал, а не польза. Перейти от простой схемы к этой легко, обратно — тоже.