Магия Pull Requests

1. От слияния к предложению: зачем нужны Pull Requests?

В прошлой лекции мы научились сливать (merge) ветки на своем локальном компьютере. Это отлично работает, когда вы работаете в одиночку. Но что если над проектом трудится целая команда? Если каждый будет сливать свои изменения напрямую в основную ветку main, очень скоро начнется хаос: кто-то может случайно добавить код с ошибками, сломать сборку или удалить важную часть работы коллеги.

Чтобы избежать этого, в командной разработке принят другой подход. Вместо того чтобы сразу сливать изменения, вы создаете предложение на слияние. Это предложение называется Pull Request (сокращенно PR) или, на некоторых платформах, Merge Request.

Pull Request — это официальная просьба: "Пожалуйста, заберите (pull) мои изменения из моей ветки и добавьте (merge) их в основную ветку". Но это не просто просьба, а целая площадка для обсуждения, проверки и улучшения кода перед тем, как он попадет в main.

2. Стандартный рабочий процесс с Pull Request

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

Прежде чем создавать ветку для новой задачи, убедитесь, что вы отправили все свои завершенные коммиты (push) и обновили (Update Project) основную ветку main.

Иначе все ваши "забытые" локальные коммиты из main случайно попадут в новый Pull Request, создав путаницу для ваших коллег.

Шаг 1. Создайте ветку для новой задачи.

Как и раньше, любая новая работа начинается с создания отдельной ветки. Допустим, мы хотим добавить в наш проект файл с правилами для контрибьюторов. Создадим ветку feature/add-contribution-guide.

Шаг 2. Внесите изменения и отправьте вашу ветку на GitHub.

В новой ветке создайте файл CONTRIBUTING.md (после создания нажмите Add) и напишите в нём послание другим разработчикам. После этого сделайте Commit and Push с понятным сообщением, например: docs: Add contribution guide.

Это ключевой шаг! Pull Request создается на основе ветки, которая уже существует на удаленном сервере. Поэтому, прежде чем создавать PR, нужно отправить (push) вашу новую ветку на GitHub.

3. Создание Pull Request из IntelliJ IDEA

Теперь, когда ваша ветка есть на GitHub, можно создать Pull Request.

Шаг 1. Откройте вкладку Pull Requests.

Слева в IDE находится вкладка Pull Requests. Откройте ее и нажмите на значок +, чтобы создать новый PR.

Шаг 2. Заполните данные для PR.

IDE автоматически откроет для вас удобный интерфейс для создания Pull Request. Ваша задача — грамотно его заполнить. Давайте разберем основные поля:

1. Заголовок: IDE часто подставляет сюда название ветки, но это плохая практика. Заголовок должен быть кратким, понятным и отражать суть изменений, как хорошее сообщение коммита.
2. Описание: здесь вы объясняете, что и зачем вы сделали.
3. Ревьюеры: здесь вы выбираете одного или нескольких коллег, которые должны проверить ваш код. В учебном проекте пропустим этот шаг, но в реальной работе он обязателен.
4. Исполнители: обычно здесь вы указываете себя. Это означает, что вы — автор и основной ответственный за эту задачу и за внесение правок после ревью.

После того как все поля заполнены смело нажимайте Create Pull Request.

4. Код-ревью: проверка и обсуждение

После создания PR начинается самый важный этап — код-ревью (code review). Ваши коллеги могут открыть ваш PR, посмотреть все изменения и оставить комментарии.

Вы можете видеть все обсуждения прямо в IDE во вкладке Pull Requests. Если кто-то оставит комментарий, вы получите уведомление.

Что делать, если попросили внести правки?

Очень просто! Не нужно создавать новый PR. Просто внесите нужные изменения в код в вашей же ветке, сделайте новый коммит и отправьте его (push). Pull Request на GitHub автоматически обновится, добавив ваши новые коммиты.

5. Завершение работы: слияние и удаление ветки

Когда все замечания исправлены и команда одобряет ваши изменения, Pull Request можно сливать. Обычно это делает старший разработчик или вы сами, если у вас есть права.

Шаг 1. Merge

Слияние чаще всего происходит на сайте GitHub. Там под вашим PR появится большая зеленая кнопка Merge pull request. После ее нажатия ваш код станет частью основной ветки main.

Шаг 2. Удаление ветки.

После слияния ваша `feature`-ветка больше не нужна, и ее стоит удалить, чтобы не засорять репозиторий. GitHub сам предложит это сделать, показав кнопку Delete branch.

Не забудьте также удалить и локальную копию ветки у себя в IDE, чтобы поддерживать порядок. Это можно сделать через то же меню управления ветками.

6. Три правила коммита

Хороший коммит — это не только правильное сообщение, но и правильное содержание. Чтобы ваша история изменений была чистой, полезной и профессиональной, придерживайтесь трех простых правил.

Правило 1: пишите понятные сообщения по стандарту

Ваши коммиты — это сообщения, которые вы отправляете своей команде и себе в будущее. История, полная сообщений "fix" или "update", абсолютно бесполезна. Самый популярный стандарт называется Conventional Commits. Он предлагает следующую структуру:

<тип>: <краткое описание>

Тип — это короткое слово, описывающее категорию ваших изменений:

• feat: (feature) — для новой функциональности.
• fix: — для исправления ошибки.
• docs: — для изменений в документации.
• style: — для правок форматирования, не влияющих на логику кода.
• refactor: — для изменений в коде, которые не добавляют новой функциональности и не исправляют ошибок.
• test: — для добавления или исправления тестов.
• chore: — для рутинных задач, не связанных с кодом (обновление зависимостей, настройка сборки).

Примеры:

• Плохо: fixed bug
• Хорошо: fix: Correct user login validation

• Плохо: readme
• Хорошо: docs: Update installation instructions

Правило 2: один коммит — одно логическое изменение (Атомарность)

Не пытайтесь уместить в один коммит исправление бага, добавление новой функции и рефакторинг старого кода. Такой коммит очень сложно проверять, и почти невозможно безболезненно отменить, если что-то пойдет не так.

Каждый коммит должен решать только одну конкретную задачу.

• Плохо: один коммит с сообщением "Update user page", который добавляет поле для аватара, исправляет ошибку в валидации имени и меняет цвет кнопок.
• Хорошо: три разных коммита:
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. style: Update button colors on user page

Маленькие, сфокусированные коммиты гораздо проще для понимания и управления.

Правило 3: Коммит не должен ломать проект

Каждый коммит в основной ветке должен оставлять проект в рабочем состоянии. Перед его созданием вы должны как минимум убедиться, что код компилируется. Но как убедиться, что вы случайно не сломали что-то в другой части системы? Полагаться только на ручную проверку рискованно.

Здесь на помощь приходит автоматизация. В этом курсе мы не будем настраивать автоматические процессы, но вы должны знать, как это работает в реальных проектах. Современные команды используют системы непрерывной интеграции (Continuous Integration, CI), такие как GitHub Actions.

Как это работает?

Вы пишете код и тесты к нему. Затем вы настраиваете специальный сценарий (workflow) прямо на GitHub. Теперь, как только вы отправляете push в свой Pull Request, происходит магия:

1. GitHub Actions видит это событие и запускает ваш сценарий.
2. Он автоматически "собирает" проект и запускает все тесты.
3. Если все тесты успешно пройдены, рядом с вашим коммитом на GitHub появляется зеленая галочка. Это сигнал для всей команды, что ваши изменения безопасны.
4. Если хотя бы один тест падает, вы увидите красный крестик. Сливать такой PR в основную ветку категорически запрещено.

                graph LR
                subgraph GitHub
                A[Разработчик] -- "push" --> B(Репозиторий)
                B -- "Событие: push" --> C{GitHub Actions}
                end

                subgraph Workflow
                C -- "Запуск" --> D[Запуск_тестов]
                D --> E[Успешно]
                D --> F[Неуспешно]
                end

                subgraph Notifications
                F --> G((Email))
                G --> H[Разработчик]
                G --> I[Команда]
                end

                style F fill:#f99,stroke:#333,stroke-width:2px
                style G fill:#ccf,stroke:#333,stroke-width:2px
                

Можно настроить уведомления. Если тесты провалились, GitHub Actions может отправить письмо вам или всей команде. Такой подход создает культуру, где тесты — это не просто формальность, а неотъемлемая часть разработки, и каждый несет ответственность за качество своего кода.