List Issues Suggestions1 Discussions Insights

🧙 Садовник: уточнил шаги, добавил проверки и обоснования. Примите, если полезно.

open−8~6proposed by gardener · Aug 12, 2026 · based on v2

Conversation Checks Proposed changes14 Result

Result · becomes v3

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

bash

1git switch demo

2git pull origin demo

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

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

Why: Ветка должна ответвляться оттуда, куда потом вольётся. Это главное правило любой схемы ветвления, и его чаще всего нарушают.

code

1git switch demo && git pull origin demo

–Ветка создана от demo, а не от main
–Имя ветки с префиксом и описывает задачу
–Demo обновлена до последней версии

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

bash

1git add .

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

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

Why: Формат коммитов нужен не ради красоты: по типам собирают список изменений к релизу автоматически, а по областям фильтруют историю — `git log --grep="(auth)"` покажет всё, что делали с авторизацией.

code

1git status

–Сообщение начинается с типа
–Область в скобках указана и взята из принятого набора
–Первая строка короче 50 символов
–Все нужные изменения добавлены в индекс

Conventional Commits по-русски

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

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. Проверь, что после rebase все изменения на месте и нет конфликтов.

Why: Сравни с merge: он создаёт дополнительный коммит и ветвит историю. При десятке разработчиков история превращается в плетёнку, в которой невозможно найти, когда появилась ошибка. Rebase держит её линейной.

code

1git rebase demo

–Ветка поднята над свежим demo
–Ты понимаешь, почему rebase нельзя делать с общими ветками
–Нет конфликтов после rebase
–Все изменения сохранены

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

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

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 в твою ветку — то есть наоборот. Убедись, что PR создан корректно и все участники ревью добавлены.

Why: На этом этапе код смотрят люди. Именно здесь ловятся ошибки, которые тесты не видят: непонятные имена, скопированный код, решения, которые через месяц придётся переписывать.

code

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

–base = demo, compare = твоя ветка
–В описании понятно, что и зачем сделано
–Добавлены ревьюеры
–PR создан и виден в интерфейсе GitHub

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

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

Why: Фича может работать идеально в одиночку и ломаться рядом с другой. Такие поломки не ловятся ни ревью, ни тестами отдельной ветки — только совместной проверкой.

–Фича проверена на demo вместе с остальными
–Нет конфликтов с другими изменениями
–Все функциональные требования выполнены

Второй PR: demo в main

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

base — main
compare — demo

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

Этот PR делает не автор фичи, а тот, кто выпускает релиз. Убедись, что все изменения в demo готовы к продакшену.

Why: Второй PR — это граница между «работает у нас» и «работает у пользователей». Он даёт последнюю возможность остановиться и список того, что именно выкатывается.

–base = main, compare = demo
–В описании перечислены все изменения релиза
–Есть подтверждение ответственного
–Все изменения в demo проверены и готовы к прод