Git для командной разработки

Для чего модуль

Сделать git-процесс команды предсказуемым: чистая история изменений, понятные PR и безопасные релизы без хаотичных «пожаров».

Результат после прохождения

1. Вы уверенно работаете с rebase/merge/revert/cherry-pick/reflog в реальных сценариях.
2. Вы организуете PR-процесс, который повышает качество кода, а не тормозит поставку.
3. Вы умеете проводить релиз и hotfix с минимальным риском для production.
4. Вы знаете, как восстанавливаться после ошибок в истории и релизе.

Термины и аббревиатуры

Термин	Коротко
Trunk-based	Короткие ветки + частый merge
Rebase	Перенос коммитов на новую базу
Merge	Объединение веток
Revert	Отмена коммита отдельным коммитом
Protected branch	Защищенная ветка с правилами

Фокус по грейдам

1. Junior: понимать базовые механики и объяснять их простыми примерами.
2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем

1. Все команды отрабатывайте в учебном репозитории с имитацией командной работы.
2. Для каждого сценария фиксируйте: цель, риски, безопасный путь и rollback.
3. После урока добавляйте в командный runbook обновленный playbook.

Программа модуля

Урок 1. Командный workflow и модель ветвления

Цель: выбрать ветвление и правила PR под контекст команды.

Модели ветвления

1. Trunk-based (короткие ветки, частые merge).
2. GitFlow-подобный подход (release/hotfix ветки).
3. Гибрид для продуктовых команд с регулярными релизами.

Что важно, кроме схемы

1. Размер PR и SLA ревью.
2. Политика protected branches.
3. Правила именования веток и сообщений коммитов.

Где ломается в проде

1. Большие долгоживущие ветки с постоянными конфликтами.
2. «Срочные» merge в main без quality gates.
3. Нет договоренности, когда использовать rebase/merge.

Мини-задача (обязательная)

Опишите git workflow вашей команды: ветки, PR-правила, quality gates, release/hotfix путь.

Что спросит интервьюер: какой workflow вы выбрали и почему он подходит вашей команде.

Критерий готовности по уроку: вы можете показать workflow как систему управления риском, а не просто набор команд.

Урок 2. Rebase, merge и работа с конфликтами

Цель: управлять историей изменений и конфликтами без потери данных.

Когда что использовать

1. Rebase — для линейной локальной истории перед PR.
2. Merge — когда нужна явная фиксация объединения веток.
3. Revert — для безопасного отката в shared history.

Конфликты: безопасный алгоритм

1. Понять бизнес-смысл конфликтующего кода.
2. Разрешить конфликт, сохраняя инварианты и тесты.
3. Проверить интеграцию целиком, а не только конфликтный файл.

Где ломается в проде

1. Force-push в shared ветку без договоренности.
2. «Механическое» разрешение конфликтов без понимания контекста.
3. Попытка исправить всё через hard reset в рабочем репозитории команды.

Мини-задача (обязательная)

Симулируйте 2 конфликтных сценария и сделайте разбор: причина, шаги решения, как избежать повтора.

Что спросит интервьюер: как вы действуете при сложном merge-конфликте в критичной фиче.

Критерий готовности по уроку: вы можете восстановить корректную историю и код после конфликта без потери функциональности.

Урок 3. Pull Request как инженерный артефакт

Цель: сделать PR каналом качества, а не формальностью.

PR quality framework

1. Ясный контекст: что меняется и зачем.
2. Границы изменения: что входит/не входит.
3. Доказательства: тесты, скриншоты, метрики, миграции.

Review, который работает

1. Фокус на рисках и регрессиях.
2. Разделение блокирующих и неблокирующих комментариев.
3. Review checklist для критичных зон (security, data, perf).

Где ломается в проде

1. Огромные PR, которые никто не может проверить качественно.
2. Непонятные описания «fix stuff».
3. Смешение рефакторинга и бизнес-изменений в одном PR.

Мини-задача (обязательная)

Соберите PR-template и reviewer checklist для вашего проекта (frontend + backend + data changes).

Что спросит интервьюер: как вы организуете review так, чтобы оно повышало качество, а не только задерживало merge.

Критерий готовности по уроку: вы можете показать PR-процесс, который снижает дефекты без потери скорости команды.

Урок 4. Git в релизах и инцидентах

Цель: безопасно проводить релизы и hotfix в условиях ограниченного времени.

Release/hotfix стратегия

1. Freeze window и критерии готовности.
2. Release branch/tagging/versioning.
3. Быстрый rollback/revert сценарий.

Инциденты и восстановление

1. revert как основной инструмент безопасного отката.
2. reflog для восстановления локально потерянных состояний.
3. Запрет импровизаций в проде: только по runbook.

Где ломается в проде

1. Hotfix напрямую в main без трассируемости.
2. Нет единого владельца релиза и коммуникации.
3. Откат не проверен заранее, в критический момент «не срабатывает».

Мини-задача (обязательная)

Подготовьте release/hotfix runbook: шаги релиза, критерии rollback, роли, SLA коммуникации.

Что спросит интервьюер: как вы организуете rollback, если релиз уже у пользователей.

Критерий готовности по уроку: вы можете провести релиз и управляемо откатить его при риске инцидента.

Практика

1. Настройте учебный git workflow в мини-команде (2-3 участника).
2. Проведите конфликт-симулятор и оформите postmortem.
3. Подготовьте playbook: rebase/merge/revert/cherry-pick/reflog.
4. Соберите PR template + reviewer checklist.
5. Сформируйте release/hotfix process doc и закрепите в Playbook ответов.
6. Отработайте конфликт + revert + hotfix flow в Песочнице.

Связь с треками и вопросами

1. Треки: Junior трек, Middle трек, Senior трек.
2. Вопросы: Playbook, Senior Frontend.
3. Повторение: 3-5 вопросов без подсказок -> сверка с модулем -> повтор через 24 часа.

Критерий готовности

Вы объясняете git-процесс как систему надежной поставки, а не как набор команд CLI.

Артефакты после модуля

1. Документ Git Workflow для команды.
2. PR-template и review checklist.
3. Release/hotfix runbook с ролями.
4. Набор из 5 сильных interview-ответов по git-практикам.

Куда дальше

1. Tooling и Delivery
2. Инженерные принципы
3. Git