От ветки до принятого Pull Request

В прошлом уроке вы создали GitHub-репозиторий, подключили его как remote с именем github и отправили первый коммит из локальной main. Теперь воспользуемся этим репозиторием: создадим отдельную ветку с изменением, откроем Pull Request и пройдём весь цикл до слияния и локальной синхронизации.

Feature branch, коммит и отправка ветки на GitHub

Откройте терминал в my_github_demo после успешного завершения урока 24. Если такого репозитория нет, выполните его подготовку и публикацию целиком в новой распаковке; произвольная новая папка не имеет нужного remote. Используйте собственный учебный репозиторий без защиты веток, допускающий обычный merge-коммит. main локально и на GitHub имеют один исходный коммит; никто больше не обновляет её до этого PR. Не делайте новых коммитов в локальной main в течение опыта.

Прежде чем делать первый коммит в клонированном или заново настроенном репозитории, нужно убедиться, что Git знает, кто его автор. Клонирование не переносит локальные настройки user.name и user.email — они хранятся отдельно от истории коммитов. Если вы работаете в клоне из предыдущего урока или в новой папке, задайте оба параметра явно:

git config user.name "Student"
git config user.email "student@example.com"

Это локальные настройки: они применяются только к текущему репозиторию и не влияют на другие. Без явно проверенной identity Git может отказать либо взять имя и e-mail из глобальных настроек или других источников, которые не подходят для этой работы. При неприемлемой пустой identity commit отказывает. Явные локальные настройки выбирают нужного автора.

Далее убедитесь, что находитесь на main и рабочая папка чистая:

git status

Должно быть: On branch main и nothing to commit, working tree clean. Если это так — создаём feature-ветку:

git switch -c feature/update-readme

switch -c создаёт ветку и сразу переключается на неё. Вы уходите от main: любые новые коммиты теперь пойдут в feature/update-readme, не затрагивая main до явного слияния.

Откройте README.md в редакторе и добавьте в конец строку, например:

Автор: Student

Сохраните файл, добавьте в индекс и зафиксируйте:

git add README.md
git commit -m "Добавить автора в README"

Теперь отправьте ветку на GitHub:

git push -u github feature/update-readme

Флаг -u настраивает tracking: Git запоминает, что локальная feature/update-readme связана с github/feature/update-readme. Следующий git push в этой ветке уже не потребует явного указания remote и ветки.

После успешного push GitHub показывает в веб-интерфейсе жёлтый баннер с текстом «Compare & pull request» для только что отправленной ветки. Это сигнал, что ветка появилась на сервере и готова к обсуждению.

Pull Request: не Git-команда, а веб-инструмент GitHub

Pull Request — это функция GitHub, а не команда Git. В локальном репозитории нет никакой команды git pull-request. PR — объект сервиса GitHub, доступный в браузере, через GitHub CLI и API. В этом уроке работаем в браузере: страница PR содержит описание изменений, diff и обсуждение. Это отличие от локального Git, а не ограничение PR одним интерфейсом. Официальная инструкция создания PR описывает и другие способы.

При создании PR вы указываете две ветки:

• base — ветка-получатель. Сюда попадут изменения после слияния. Обычно это main.
• compare (иногда называемая head) — ветка с вашими изменениями. В нашем случае это feature/update-readme.

GitHub автоматически вычисляет diff — разность между base и compare. Это не весь файл, а только те строки, которые изменились. Вкладка «Files changed» показывает:

• строки, добавленные в compare относительно base, — зелёным фоном с символом +;
• строки, которые есть в base, но отсутствуют в compare, — красным фоном с символом -.

Если в README.md добавлена одна строка, в диффе будет ровно одна зелёная строка с +.

Важный момент: base нужно выбирать осознанно до нажатия «Create pull request». Если случайно выбрать не ту ветку в качестве base, изменения при слиянии пойдут не туда. До создания PR посмотрите предварительный diff на странице сравнения веток и выбранные base/compare. Вкладка «Files changed» находится на странице уже созданного PR и позволяет ещё раз проверить правки перед слиянием.

Комментарии в PR — это текстовые заметки, которые участники оставляют к конкретным строкам diff или к PR в целом. Автор PR тоже может комментировать собственные изменения: это нормальная практика для фиксации решений или вопросов. В учебном репозитории второй участник не нужен — владелец репозитория может проверить и принять свой же PR самостоятельно.

Открытие PR и слияние обычным merge-коммитом

После push GitHub показывает жёлтый баннер «Compare & pull request» прямо на главной странице репозитория. Нажмите на него — откроется форма создания PR с уже выбранными base (main) и compare (feature/update-readme).

До нажатия «Create pull request» проверьте base main, compare feature/update-readme и предварительный diff на странице сравнения/форме создания: он должен содержать добавленную строку README. Если баннер не показан, откройте «Pull requests» → «New pull request» и выберите те же ветки.

Введите заголовок PR (он обязателен) — например, «Добавить автора в README». Описание можно оставить пустым. Нажмите «Create pull request».

PR создан. Теперь вы на странице PR, где три вкладки:

• Conversation — общий чат и итоговые кнопки слияния.
• Commits — список коммитов из compare.
• Files changed — постраничный diff.

После создания откройте «Files changed» и повторно проверьте весь diff и нужную строку. Затем для слияния перейдите на вкладку «Conversation» и прокрутите вниз. GitHub предлагает три варианта слияния через выпадающее меню рядом с кнопкой «Merge pull request»:

• Create a merge commit — обычный merge-коммит с двумя родителями.
• Squash and merge — все коммиты feature-ветки сжимаются в один.
• Rebase and merge — коммиты переносятся линейно без merge-коммита.

Выберите «Create a merge commit» — этот вариант сохраняет коммиты ветки и двух родителей объединения. Если выбор недоступен из-за настроек или защиты, не подменяйте его squash/rebase: для опыта нужен ваш обычный учебный репозиторий с доступным merge-коммитом. Нажмите «Merge pull request», затем «Confirm merge».

GitHub создаёт merge-коммит и объединяет feature/update-readme в main. Статус PR меняется на «Merged» (фиолетовая метка). Ветка feature/update-readme больше не нужна — GitHub предложит её удалить кнопкой «Delete branch», но для учебных целей это необязательно.

Синхронизация локальной main и проверка истории

После слияния PR на GitHub локальная main отстаёт: merge-коммит существует только на сервере. Переключитесь на неё:

git switch main

Получите обновления с GitHub и объедините их:

git fetch github
git merge github/main

git fetch github скачивает новые коммиты из remote в локальную remote-tracking ветку github/main, не трогая рабочую папку. git merge github/main применяет их к локальной main. В этом опыте локальная main не продвигалась: её исходный коммит — предок созданного на GitHub merge-коммита. Поэтому локальное обновление выполняется fast-forward до этого серверного коммита, без нового локального merge-коммита.

Альтернатива двум командам выше в этом же опыте — git pull --ff-only на чистой main, чей upstream после урока 24 именно github/main:

git pull --ff-only

В заданном состоянии она тоже продвигает main fast-forward; при уже выполненном обновлении сообщит Already up to date. В неподготовленном расходящемся состоянии она откажет в объединении.

Проверьте историю:

git log --oneline

Вы увидите примерно такой вывод (SHA будут другими):

a1b2c3d Merge pull request #1 from <user>/feature/update-readme
4e5f6a7 Добавить автора в README
8b9c0d1 Initial commit

Для наглядного графа с ветвлением:

git log --graph --oneline --all

*   a1b2c3d (HEAD -> main, github/main) Merge pull request #1 from <user>/feature/update-readme
|\
| * 4e5f6a7 (github/feature/update-readme) Добавить автора в README
|/
* 8b9c0d1 Initial commit

Видно ответвление feature/update-readme и точку слияния обратно в main.

Проверьте содержимое файла — строка «Автор: Student» должна быть в README.md. Дополнительно откройте репозиторий на GitHub: вкладка «Code» показывает актуальный README.md, ссылка «N commits» — полную историю включая merge-коммит, вкладка «Pull requests» — PR со статусом «Merged».

Локальная main и main на GitHub теперь совпадают.