Этап 7 - Совместная работа через Pull Requests
task-service уже опубликован в GitHub, и теперь команда вводит обязательный этап review перед тем, как изменения попадут в main. Pull request — это как буфер безопасности между веткой автора и общей историей.
Pull request как пространство обсуждения
PR — это не просто «нажал кнопку merge». Это пространство с:
- списком коммитов,
- списком измененных файлов,
- комментариями к строкам,
- статусом проверок,
- историей обновлений.
По сути это место, где коллеги согласовывают изменение до интеграции.
Рабочий поток для task-service
git switch main
git pull
git switch -c feature/task-export
Добавьте одно точечное изменение. Создайте task-service-export.json в редакторе с таким содержимым:
{"version":"1.0","export":"json"}
Затем зафиксируйте и отправьте ветку:
git add task-service-export.json
git commit -m "feat: add export format contract file"
git push -u origin feature/task-export
Затем откройте PR в GitHub из feature/task-export в main.
Fork или ветка внутри репозитория
Внутри одного репозитория обычно создается ветка и пушится туда.
В open source-проектах, где нет прав push, используется fork:
- создаете fork upstream,
- клонируете его,
- пушите ветку,
- открываете PR в исходный репозиторий.
Идея та же: локальная ветка → push → обсуждение → merge.
Ответ на комментарии
Комментарии в review — это часть процесса, не «атакующий тон».
git switch feature/task-export
# внесите корректировку, если reviewer указал на ошибку
git add task-service-export.json
git commit -m "fix: include metadata in export contract"
git push
PR обновится автоматически.
| Термин | Роль |
|---|---|
| Fork | Собственная удаленная копия без прямого push-доступа |
| PR | Совместная зона перед merge |
| Комментарий ревью | Конкретная техническая правка к месту |
| Push после review | Обновление PR тем же кодом по тому же пути |
Если PR прошел обсуждение и проверки, слияние становится минимальным риском для main.
Review как инженерная практика
Хороший PR — это не «больше текста ради текста». Он снимает неоднозначность:
- что меняется,
- что сознательно не меняется,
- как быстро проверить.
Если в PR только общая фраза «изменилась логика», ревьюер тратит время на реконструкцию. Поэтому добавляйте хотя бы ручную проверку на task-service или короткий тестовый сценарий.
Комментарии ревьюера лучше рассматривать как часть проектной экспертизы. Не спорьте о вкусе без причины: спросите, как эта правка снижает риск для следующего разработчика, который будет читать историю.
Понятность для коллег и будущего вас
Сильный PR всегда помогает даже тем, кто придет позже и не участвовал в задаче. Если через месяц нужно вернуться к этому изменению, reviewer-комментарии и описание в PR уже объяснят, почему было решено именно так.
Поэтому не стремитесь к «мини-PR». Стремитесь к PR, в котором есть мотивация, контекст и проверка.