На предыдущих уроках мы научились работать с Git локально, подключать удалённые репозитории и синхронизировать изменения через GitHub. Однако до сих пор мы рассматривали сценарий, в котором над проектом работает только один человек.

В реальной разработке это встречается редко. Даже небольшой коммерческий проект обычно создаётся командой из нескольких специалистов. В одном репозитории одновременно могут работать backend-разработчики, frontend-разработчики, тестировщики, аналитики и DevOps-инженеры.

Если каждый участник будет напрямую изменять основную ветку проекта, очень быстро возникнет хаос:

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

Для решения этой проблемы в Git и GitHub используется процесс командной разработки через ветки, Pull Request и Code Review.

Именно такой подход применяется в большинстве современных компаний.

В этом уроке мы разберём, как организована совместная работа над проектом и каким образом изменения проходят путь от компьютера разработчика до основной ветки репозитория.

Ключевые термины

Main branch — основная ветка проекта, содержащая стабильную версию кода.
Feature branch — отдельная ветка для разработки новой функциональности.
Pull Request (PR) — запрос на добавление изменений из одной ветки в другую.
Code Review — проверка кода другими участниками команды перед объединением изменений.
Reviewer — специалист, который проверяет код в рамках Code Review.
Merge — объединение изменений из одной ветки в другую.
Approval — подтверждение того, что изменения прошли проверку.
Comment — замечание или вопрос, оставленный во время проверки кода.

Почему нельзя работать напрямую в main

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

Кроме того, одна из функций может оказаться незавершённой. В результате основная ветка перестанет быть стабильной. Именно поэтому в профессиональной разработке действует простое правило: Ветка main должна содержать только рабочий и проверенный код. Любые новые задачи выполняются в отдельных ветках.

Работа через ветки

Когда разработчик получает новую задачу, он создаёт отдельную ветку. Например git switch -c feature-login или git checkout -b feature-login. После этого вся работа ведётся внутри новой ветки.

Разработчик может:

изменять файлы;
создавать коммиты;
экспериментировать с реализацией;
исправлять ошибки.

При этом основная ветка проекта остаётся неизменной. После завершения работы изменения фиксируются:

git add .
git commit -m "Добавлена форма авторизации"

Затем ветка отправляется на GitHub:

git push -u origin feature-login

Теперь изменения доступны на сервере, но ещё не попали в основную ветку проекта.

Это важный момент. Отправка ветки на GitHub не означает автоматическое добавление кода в main. Для этого используется специальный механизм — Pull Request.

Что такое Pull Request

Pull Request является одной из самых важных возможностей GitHub. Представьте ситуацию. Разработчик завершил работу над авторизацией пользователей. Он уверен, что код работает корректно.

Однако прежде чем изменения попадут в основной проект, команда хочет убедиться:

код соответствует стандартам;
не содержит ошибок;
не ломает существующую функциональность;
решает поставленную задачу.

Для этого создаётся Pull Request. Проще говоря, Pull Request можно воспринимать как запрос: «Я закончил работу над задачей. Проверьте мои изменения и разрешите добавить их в проект».

При создании Pull Request GitHub показывает:

список коммитов;
изменённые файлы;
добавленные строки;
удалённые строки;
комментарии участников обсуждения.

Обычно процесс выглядит следующим образом:

Разработчик создаёт ветку.
Выполняет задачу.
Отправляет ветку на GitHub.
Создаёт Pull Request.
Команда проверяет изменения.
После проверки выполняется merge.

Таким образом, Pull Request становится своеобразными воротами перед попаданием изменений в основной проект.

Создание Pull Request

После отправки ветки на GitHub платформа обычно сама предлагает создать Pull Request. Также его можно создать вручную через вкладку Pull Requests.

При создании необходимо указать:

исходную ветку;
целевую ветку;
название изменений;
описание выполненной работы.

Хорошее описание помогает коллегам быстрее понять смысл изменений.

Что такое Code Review

После создания Pull Request начинается следующий этап — Code Review. Code Review представляет собой проверку изменений другим разработчиком.

На первый взгляд может показаться, что это лишняя бюрократия. На практике Code Review решает огромное количество проблем.

Во-первых, позволяет находить ошибки до попадания кода в основную ветку.
Во-вторых, помогает поддерживать единый стиль разработки.
В-третьих, позволяет распространять знания внутри команды.

Когда несколько разработчиков регулярно проверяют код друг друга, они лучше понимают устройство проекта. Поэтому в большинстве компаний изменение не может попасть в main без прохождения Code Review.

Что проверяют во время Code Review

Во время проверки ревьюер обращает внимание на множество факторов.

Например:

правильно ли решена задача;
нет ли логических ошибок;
читается ли код;
соблюдаются ли соглашения команды;
отсутствует ли дублирование;
не появились ли потенциальные проблемы производительности.

Иногда замечания бывают небольшими. Например Переименуй переменную, её назначение неочевидно.

Иногда замечания могут быть серьёзнее: В этом месте возможна ошибка при отсутствии данных от сервера.

После получения замечаний разработчик исправляет код и отправляет новые коммиты в ту же ветку. Pull Request обновляется автоматически. Создавать новый PR не требуется.

Одобрение изменений

Когда все замечания устранены, ревьюер может подтвердить изменения. На GitHub это называется Approval.

После получения одобрения ветка может быть объединена с основной. Выполняется merge. После этого изменения появляются в ветке main. С этого момента новая функциональность становится частью проекта.

Наиболее частые ошибки

Работать напрямую в ветке main.
Это увеличивает риск случайно сломать проект и усложняет контроль изменений.
Создавать одну ветку для нескольких задач.
Каждая задача должна иметь собственную ветку.
Создавать Pull Request слишком поздно.
Большие изменения сложнее проверять и обсуждать.
Не заполнять описание Pull Request.
Коллегам становится сложнее понять цель изменений.
Смешивать исправление ошибок и новую функциональность в одном Pull Request.
Это затрудняет проверку.
Удалять ветку до завершения проверки.
Ветка должна существовать до завершения работы над Pull Request.

Наиболее частые вопросы

Можно ли работать без Pull Request?
Технически можно. Однако в командной разработке Pull Request считается стандартом и используется практически повсеместно.
Обязательно ли делать Code Review?
В небольших личных проектах нет. В коммерческой разработке проверка изменений обычно является обязательной.
Кто должен проверять код?
Обычно это тимлид, старший разработчик или другой участник команды.
Можно ли создать Pull Request на незавершённую задачу?
Да. Многие команды используют черновые Pull Request для раннего обсуждения реализации.
Нужно ли удалять ветки после merge?
Обычно да. После объединения ветка становится ненужной и может быть удалена.
Почему в командах так много внимания уделяется Code Review?
Потому что исправлять ошибки до попадания в основную ветку значительно дешевле и проще, чем искать их позже в рабочем приложении.

Итоги

В этом уроке вы познакомились с процессом совместной разработки через GitHub. Мы разобрали, почему работа ведётся через отдельные ветки, узнали назначение Pull Request и рассмотрели процесс Code Review.

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

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