Курс Git — Модуль 7: Командная работа

Модуль 7: Командная работа и продвинутые практики

Разберём, как эффективно работать в команде: PR/MR, ревью кода, теги, временное сохранение изменений и перенос коммитов.

Командная работа — это набор договорённостей о том, как создавать, проверять и интегрировать изменения. Git предоставляет механизмы, но культура и политика важнее: они определяют, когда и как применять инструменты.

7.1 Pull Request / Merge Request

Создавайте PR из feature‑ветки в main. Описывайте цель, мотивацию, изменения и способ тестирования.

Хороший PR — самодостаточный документ: контекст задачи, список изменений, скриншоты/логи при необходимости, чек‑лист для ревьюера. Чем меньше сюрпризов у ревьюера, тем быстрее слияние.

7.2 Code Review

Пишите короткие, самодостаточные коммиты
Отвечайте на замечания аргументированно, правки — отдельными коммитами
Используйте чек‑листы и авто‑проверки (CI)

Цель ревью — не «принять» код, а улучшить его и обменяться знаниями. Фокусируйтесь на рисках, читаемости и архитектурных договорённостях, а не на личных предпочтениях стиля.

7.3 Теги (релизы)

# Аннотированный тег
git tag -a v1.0.0 -m "Release 1.0.0"
# Отправить все теги
git push origin --tags

7.4 Временное сохранение: git stash

git stash push -m "WIP: форма логина"
# посмотреть список
git stash list
# применить и удалить из стэша
git stash pop
# применить без удаления
git stash apply stash@{1}

7.5 Перенос коммита: git cherry-pick

# перенести конкретный коммит в текущую ветку
git cherry-pick <commit-hash>

7.6 Модели ветвления: GitFlow, GitHub Flow, Trunk‑based

GitFlow — выпуска‑ориентированная модель с ветками develop/release/hotfix. GitHub Flow — простая модель «ветка‑PR‑merge» на основе main. Trunk‑based — короткоживущие ветки, частые слияния с «транком» и автоматизацией.

7.7 Защищённые ветки и политики

Политики репозитория: запрет force‑push, обязательные ревью, статические проверки (CI), требования к статусам, ограничение прав на merge. Это повышает качество и воспроизводимость релизов.

7.8 Подпись коммитов (GPG/SSH) и проверка

Кратко: подпись коммитов подтверждает авторство и целостность. Подробная теория и настройка вынесены в раздел 9.16 «Подписанные коммиты (GPG/SSH)», а организационные практики — в 10.6 «Безопасность секретов».

7.9 DCO и требования к PR

Developer Certificate of Origin — юридическое подтверждение авторства через строку Signed-off-by: в сообщении коммита. Часто применяется вместе с обязательными шаблонами PR и чек‑листами.

7.10 Семантическое версионирование и релизы

Версии в формате MAJOR.MINOR.PATCH, аннотированные теги, генерация релиз‑нот. Связка с Conventional Commits упрощает автоматизацию CHANGELOG и релизов.