From:To:
11¶ # Зачем промежуточная ветка
22
33 В простой схеме фичи льются сразу в `main`. Пока разработчик один, это работает. Как только появляется необходимость **проверить несколько фич вместе** до выкатки, нужна промежуточная ветка.
44
55 Здесь она называется `demo`. В других проектах встретишь `develop`, `development` или `staging` — суть одна.
66
77 ```
88 feature/твоя-фича → demo → main
9− PR ℕ1 PR ℕ2
10− (ревью) (релиз)
9+ первый PR второй PR
10+ (ревью) (релиз)
1111 ```
1212
1313 **Главное отличие от простой схемы:** два pull request вместо одного, и ветка ответвляется от `demo`, а не от `main`.
1414¶ ## Как оформлять коммиты
1515
16+ Полная форма сообщения выглядит так:
17+
18+ ```
19+ тип(область): описание в повелительном наклонении
20+ ```
21+
1622 Пять правил:
1723
18− 1. **Префикс** — `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`.
24+ 1. **Тип** — `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`.
1925 2. **Повелительное наклонение** — «добавь», а не «добавил».
2026 3. **Описывай ЧТО сделано, а не КАК.**
2127 4. **Первая строка до 50 символов.**
2228 5. **Подробности** — после пустой строки.
2329
2430 **Примеры по-русски:**
2531 ```
2632 feat: добавлен модуль авторизации
2733 fix: исправлен баг с регистрацией пользователя
2834 docs: обновлена документация API
2935 refactor: переработка модуля платежей
3036 test: добавлены тесты для API эндпоинтов
3137 chore: обновлены зависимости проекта
3238 ```
3339
3440 **Примеры по-английски:**
3541 ```
3642 feat: add user authentication via JWT
3743 fix: resolve database connection timeout
3844 refactor: optimize course search algorithm
3945 test: add integration tests for payment module
4046 chore: upgrade FastAPI to v0.100.0
4147 ```
4248
4349 Язык выбирает команда — важно только, чтобы в одном проекте он был один.
50+¶ ## Что писать в скобочках
51+
52+ Скобки после типа — это **область изменения** (scope). Одно слово: какой части проекта касается коммит.
53+
54+ ```
55+ fix(git): успешный push не становится ошибкой
56+ chore(deps): закрыты уязвимости ip-address и fast-uri
57+ fix(ui): длинные названия больше не распирают мобильную вёрстку
58+ feat(mcp): точечная правка списка
59+ fix(cache): закрытие списка отзывает его у общего кеша сразу
60+ feat(safety): разрушительная команда не попадает в исполняемые
61+ ```
62+
63+ Прочитав такую строку, ты понимаешь **куда** смотреть, ещё не открыв диф. Без области — «fix: исправлен баг» — приходится лезть в коммит, чтобы понять, о чём он вообще.
64+
65+ **Правила для области:**
66+
67+ | Правило | Как | Как не надо |
68+ |---|---|---|
69+ | Одно слово, строчными | `fix(auth)` | `fix(Модуль Авторизации)` |
70+ | Часть системы, а не файл | `fix(cache)` | `fix(redis_client.py)` |
71+ | Из устоявшегося набора | `api`, `ui`, `db`, `auth`, `deps` | каждый раз новое слово |
72+ | Не дублирует тип | `feat(cart)` | `feat(feature)` |
73+
74+ Набор областей у проекта конечный: обычно 5–15 штук. Их стоит один раз выписать в `CONTRIBUTING.md` и дальше выбирать из списка, а не сочинять на ходу. Иначе через полгода в истории будет `auth`, `authorization`, `authz` и `users-auth` — и польза от области пропадёт.
75+
76+ **Область необязательна.** Если изменение общее и не привязано к части системы — пиши без скобок: `chore: обновлены зависимости`. Пустые скобки `fix(): ...` — ошибка, так не пишут.
77+
78+ **Ломающее изменение** помечается восклицательным знаком **после** скобок:
79+
80+ ```
81+ feat(api)!: убран устаревший эндпоинт /v1/users
82+ ```
83+
84+ Это сигнал: у того, кто пользуется твоим кодом, после обновления что-то сломается.
85+¶
4486## Цикл
45871. Обновить demo и ответвиться от неё
4688 ```bash
4789 git switch demo
4890 git pull origin demo
4991 git switch -c feature/your-name-of-feature
5092 ```
5193
5294 **Ключевое:** ветка создаётся от `demo`, а **не** от `main`. Ответвишься от `main` — получишь конфликты со всем, что уже влили в `demo` до тебя.
5395 $ git switch demo && git pull origin demo
5496 why: Ветка должна ответвляться оттуда, куда потом вольётся. Это главное правило любой схемы ветвления, и его чаще всего нарушают.
5597 - [ ] Ветка создана от demo, а не от main
5698 - [ ] Имя ветки с префиксом и описывает задачу
57992. Закоммитить изменения
58100 ```bash
59101 git add .
60− git commit -m "feat: описание изменения"
102+ git commit -m "feat(cart): добавлено удаление товара из корзины"
61103 ```
62104
63105 Перед `git add .` всегда смотри `git status` — точка забирает всё, включая то, что ты не собирался коммитить.
64106 $ git status
65− why: Формат коммитов нужен не ради красоты: по префиксам собирают список изменений к релизу автоматически.
66− - [ ] Сообщение начинается с префикса
107+ why: Формат коммитов нужен не ради красоты: по типам собирают список изменений к релизу автоматически, а по областям фильтруют историю — `git log --grep="(auth)"` покажет всё, что делали с авторизацией.
108+ - [ ] Сообщение начинается с типа
109+ - [ ] Область в скобках указана и взята из принятого набора
67110 - [ ] Первая строка короче 50 символов
68111 → Conventional Commits по-русски — https://www.conventionalcommits.org/ru/v1.0.0/
691123. Перед push поднять ветку над demo через rebase
70113 ```bash
71114 git switch demo
72115 git pull origin demo
73116 git switch feature/your-name-of-feature
74117 git rebase demo
75118 ```
76119
77120 **Что делает rebase:** берёт твои коммиты и прикладывает их заново поверх свежего `demo` — как будто ты только что ответвился. История остаётся прямой, без лишнего коммита слияния.
78121
79122 **Правило безопасности:** rebase **переписывает историю**. Делай его только со своей веткой, которую никто больше не трогает. Никогда — с `demo` или `main`.
80123
81124 Если что-то пошло не так: `git rebase --abort`.
82125 $ git rebase demo
83126 why: Сравни с merge: он создаёт дополнительный коммит и ветвит историю. При десятке разработчиков история превращается в плетёнку, в которой невозможно найти, когда появилась ошибка. Rebase держит её линейной.
84127 - [ ] Ветка поднята над свежим demo
85128 - [ ] Ты понимаешь, почему rebase нельзя делать с общими ветками
86129 → git rebase — документация — https://git-scm.com/docs/git-rebase
87−4. PR ℕ1: ветка → demo
130+4. Первый PR: ветка в demo
88131 ```bash
89132 git push origin feature/your-name-of-feature
90133 ```
91134
92135 Дальше на GitHub жмёшь **New Pull Request** и внимательно выбираешь направление:
93136
94137 - **base** — `demo` (КУДА льём)
95138 - **compare** — `feature/your-name-of-feature` (ОТКУДА льём)
96139
97140 Затем описание и ревьюеры.
98141
99142 Если перепутать base и compare местами, PR предложит влить `demo` в твою ветку — то есть наоборот.
100143 $ git push origin feature/your-name-of-feature
101144 why: На этом этапе код смотрят люди. Именно здесь ловятся ошибки, которые тесты не видят: непонятные имена, скопированный код, решения, которые через месяц придётся переписывать.
102145 - [ ] base = demo, compare = твоя ветка
103146 - [ ] В описании понятно, что и зачем сделано
104147 - [ ] Добавлены ревьюеры
1051485. Протестировать на demo
106149 После мержа фича живёт в `demo` рядом с чужими. Это тот самый момент, ради которого вся схема и затевалась.
107150 why: Фича может работать идеально в одиночку и ломаться рядом с другой. Такие поломки не ловятся ни ревью, ни тестами отдельной ветки — только совместной проверкой.
108151 - [ ] Фича проверена на demo вместе с остальными
109−6. PR ℕ2: demo → main
152+6. Второй PR: demo в main
110153 Когда на `demo` всё сошлось, создаётся второй pull request:
111154
112155 - **base** — `main`
113156 - **compare** — `demo`
114157
115158 В описании перечисляются **все** изменения, которые уйдут в прод. Дальше — подтверждение от тимлида.
116159
117160 Этот PR делает не автор фичи, а тот, кто выпускает релиз.
118161 why: Второй PR — это граница между «работает у нас» и «работает у пользователей». Он даёт последнюю возможность остановиться и список того, что именно выкатывается.
119162 - [ ] base = main, compare = demo
120163 - [ ] В описании перечислены все изменения релиза
121164 - [ ] Есть подтверждение ответственного
122165¶
123166¶
124167¶
125168¶ ## Когда эта схема нужна, а когда нет
126169
127170 | Ситуация | Схема |
128171 |---|---|
129172 | Один разработчик, выкатываешь когда готово | `feature/` → `main`, один PR |
130173 | Несколько разработчиков, нужно проверять фичи вместе | `feature/` → `demo` → `main` |
131174 | Есть отдельный стенд для тестирования | точно с `demo` |
132175
133176 Не бери сложную схему на вырост. Два PR на каждую правку в одиночном проекте — это ритуал, а не польза. Перейти от простой схемы к этой легко, обратно — тоже.