Командная работа и pull request без обязательного аккаунта

От публикации к проверяемому изменению

Отправленная ветка ещё не означает, что её нужно включать в main. Автор может неправильно понять требование, забыть проверку или смешать несколько задач. Ревью связывает предложение, фактический diff, доказательство и решение о включении. В этой главе один человек играет автора и проверяющего в двух клонах; полезно сделать между ролями перерыв и читать изменение заново.

Pull request на хостинге — обсуждение предложения объединить выбранную ветку с другой. В самом локальном Git нет универсального объекта «PR с комментариями». Мы воспроизведём обязательные действия: автор публикует ветку и записку, проверяющий получает её, читает diff и проверяет результат, автор исправляет замечание, затем происходит интеграция. Интерфейс GitHub остаётся необязательным продолжением. GitHub Skills review показывает соответствующий цикл на хостинге.

Что должен сообщить автор

Записка отвечает на четыре вопроса: какое требование меняется, что теперь произойдёт на конкретном примере, чем проверено, какое ограничение осталось. «Добавлена новая функциональность» не помогает понять diff. Для нашего текста напишите: «Ограничиваем queue числом 24; пример конфигурации и описание теперь согласованы; проверил обе строки; поведение работающего сервера не проверял».

Проверяющий сверяет обещание с реальными файлами. Комментарий «плохо» не даёт действия; «README обещает 24, а config.example содержит 16; приведите оба к одному договору» позволяет исправить. Сообщение о прохождении теста не заменяет просмотр сценария: тест мог проверять не то требование.

Создайте предложение в локальной ветке

lab=$(mktemp -d "${TMPDIR:-/tmp}/git-08.XXXXXX")
git init --bare -b main "$lab/shared.git"
git init -b main "$lab/author"
cd "$lab/author"
git config user.name "Учебный автор"
git config user.email "author@example.invalid"
git config commit.gpgsign false
printf 'queue=16\n' > config.example
printf 'Queue capacity: 16\n' > README.txt
git add config.example README.txt
git commit -m "Describe initial capacity"
git remote add origin "$lab/shared.git"
git push -u origin main
git clone "$lab/shared.git" "$lab/reviewer"
git switch -c capacity-24
printf 'queue=24\n' > config.example
git add config.example
git commit -m "Raise example capacity to 24"
git push -u origin capacity-24
cd "$lab/reviewer"
git fetch origin
git diff origin/main...origin/capacity-24
git switch -c review-capacity origin/capacity-24
cat config.example
cat README.txt

Reviewer видит несогласованность: файл настроек содержит 24, описание — 16. Diff с тремя точками сравнивает вершину предложения с общей базой; так видно изменение ветки относительно основания. Это хороший вопрос ревью даже для проекта, в котором нет компилятора и автотестов.

Запишите замечание вне отслеживаемых файлов, например в $lab/review.txt. Затем вернитесь к роли автора:

cd "$lab/author"
printf 'Queue capacity: 24\n' > README.txt
git add README.txt
git commit -m "Align documentation with proposed capacity"
git push origin capacity-24
cd "$lab/reviewer"
git fetch origin
git merge --ff-only origin/capacity-24
cat README.txt

Проверяемая ветка продвинулась до исправления; комментарий нельзя считать выполненным только по ответу автора. Теперь настройте учебного автора reviewer, переключитесь на main и включите предложение через git merge --no-ff --no-edit origin/capacity-24, затем git push origin main. Здесь no-ff сознательно сохраняет отдельный коммит интеграции, даже если возможно простое продвижение.

Проверьте границы одобрения

Проверяющий прочитал первую версию и написал замечание. Автор добавил новый коммит, который исправляет строку, но одновременно меняет другой лимит. Достаточно ли старого одобрения, чтобы объединить ветку? Нет: нужно посмотреть обновлённый diff и проверить, что исправление не расширило предложение незаметно. В лаборатории намеренно добавьте такую лишнюю правку и попробуйте обнаружить её до интеграции.

Записка ревью должна различать факт запуска проверки и область её действия. «Проверил соответствие config и README» честно; «сервис выдержит нагрузку» не следует из чтения двух файлов. Напишите ограничение своими словами. Это не умаляет полезность ревью: оно делает результат понятным следующему человеку.

Наконец, автор и проверяющий могут не согласиться о числе 24. Механизм Git не разрешает такой спор. Нужно уточнить требование, выбрать критерий и проверить вариант, после чего создать изменение. В обязательной практике число задано условием, поэтому вы можете сфокусироваться на процедуре. Сохраните один конкретный комментарий и ответ с доказательством, а не только формальное «исправлено». Эти две строки часто лучше объясняют решение, чем длинный необработанный журнал команд.

Самостоятельная лаборатория

Практика — 45–70 минут. Сделайте своё предложение: добавьте правило остановки сервиса одновременно в описание и пример. Намеренно оставьте одно несоответствие. В роли проверяющего найдите его через diff и чтение файлов, составьте конкретный комментарий. Исправьте новым коммитом и повторно проверьте после fetch.

Создайте записку ревью с исходным замечанием, способом проверки и окончательным решением. Не добавляйте огромный лог терминала вместо объяснения. Интегрируйте в main и покажите graph. Для дополнительной практики можно повторить цикл через настоящий PR в своём тестовом репозитории GitHub по официальному вводному упражнению, но локальная лаборатория уже завершает обязательный этап.

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

Предложение существует отдельной веткой, main не изменён до решения. Замечание указывает проверяемую проблему; исправление прочитано в обновлённой ветке. Последний main содержит согласованные файлы, а записка не обещает проверки, которых вы не выполняли. Вы отличаете публикацию коммитов от одобрения их содержания.

Разбор

В первом варианте config и README расходились. Второй коммит предложения устранил расхождение, не переписывая уже показанную проверяющему историю. Merge no-ff добавил явную точку принятия двух коммитов. Сам локальный Git не хранит ваше решение «approved» как специальный статус; в нашем опыте его документирует записка.

Если reviewer не увидел исправление, сначала проверьте fetch и выбранную ветку. Если main изменился до ревью, вы работали или сливали не туда. Дальше разберём отмену ошибочных действий. Первичные источники команд: merge и push; методический источник командного цикла — GitHub Skills по ссылкам выше.