Работа в команде требует организации рабочего процесса. Это позволяет эффективно управлять кодовой базой, облегчает рецензирование кода и разрешение конфликтов. Предлагаю уделить внимание ключевым моментам рабочего процесса на GitHub — теме, которой я увлечен, поскольку во всем ценю организованность.
Проблемы
Не существует единственно верного способа перевода проблем в задачи. Обычно все определяет соглашение о совместной разработке. Рабочий процесс на GitHub чаще всего начинается с выявления проблем для определения задач.
Допустим, команда сформулировала три проблемы, требующие решения в работе над приложением: исправление существующего потока аутентификации, улучшение стиля страницы входа и создание дэшборда администратора. Задачи могут выглядеть следующим образом:
[FIX]: Fix auth flow
[STYLE]: Improve login page styling
[FEATURE]: Implement admin dashboard
Можно разбить третью задачу на подзадачи, например:
[FEATURE]: Implement admin dashboard
[SUB-FEAT]: Implement dashboard UI
[SUB-FEAT]: Implement dashboard APIs
Как правило, соглашение об именовании соответствует следующему формату:
[<type>]: <short-description>
Ветки
Следующий шаг после определения проблем — написание кода. При этом необходимо создать ветку отдельно от основной ветки. Такое разделение гарантирует, что ошибки, допущенные во время разработки, не повлияют на производственную среду.
GitHub предлагает функцию, позволяющую привязать проблему к ветке. Это означает, что после завершения работы над веткой и выполнения запроса на включение исправлений проблема будет автоматически закрыта. Чтобы создать ветку, нужно перейти на страницу «Issues» (Проблемы), справа найти раздел «Development» (Разработка) и нажать «Create a branch» (Создать ветку).
При присвоении имени ветке рекомендуется указывать номер проблемы. Например:
For `[FIX]: Fix auth flow`, the branch name could be `fix/<issue-number>/fix_auth_flow`.
For `[STYLE]: Improve login page styling`, it might be `style/<issue-number>/improve_login_page_styling`.
For `[FEATURE]: Implement admin dashboard`, use `feature/<issue-number>/implement_dashboard`.
Общий формат именования веток следующий:
<type>/<issue-number>/<short-description>
Коммиты
Вот несколько советов по созданию коммитов — фиксации внесенных изменений в коде:
- создавайте коммиты часто, в процессе написания кода, не дожидаясь завершения всей работы;
- пишите ясные, описательные сообщения о коммитах, которые понятно объясняют, что вы сделали;
- используйте настоящее время;
- используйте повелительное наклонение;
- по возможности не превышайте 50 символов в сообщении.
Теперь рассмотрим примеры сообщений о коммитах для задач, определенных выше:
feat: implement dashboard header
feat: implement dashboard main content
style: add dashboard styling
fix: fix dashboard data fetching
enhance: add dashboard animations
refactor: improve dashboard API implementation
docs: add API documentation for dashboard
При работе в монорепозитории (объединяющем код фронтенда и бэкенда) можете использовать сообщения типа:
feat(front): implement dashboard header
feat(back): implement dashboard APIs
style(front): add dashboard styling
fix(back): fix dashboard data fetching
enhance(front): add dashboard animations
refactor(back): improve dashboard API readability
docs(front): add API documentation for dashboard
Формат сообщения о коммите следующий:
[<type>]: <short-description>
Запросы на включение внесенных изменений
После сохранения изменений нужно отправить их в удаленную ветку и создать запрос на включение внесенных изменений (Pull Request, PR) для слияния этих изменений с основной веткой.
Для создания PR необходимо выполнить следующие действия:
- перейти на страницу «Branch» (Ветки) и нажать «Create a Pull Request» (Создать запрос на включение изменений);
- указать название и описание PR; можно связать их с проблемой или назначить рецензента, а также добавить метки, такие как «bug» (ошибка), «feature» (функциональность), «enhancement» (усовершенствование).
Название PR должно отражать название ветки, но без номера проблемы. Например:
For `style/<issue-number>/improve_login_page_styling`, the PR might be `style/improve-login-page-styling`.
For `feature/<issue-number>/implement_dashboard`, it might be `feature/implement-dashboard`.
Формат именования PR следующий:
<type>/<short-description> (use kebab-case for the short description)
OR
<type>/<scope>/<short-description>
Примечание: совершенно нормально использовать название ветки в качестве заголовка PR — никаких проблем с этим не возникнет.
Рецензирование кода
Рецензирование кода — важный этап перед слиянием кода в основную ветку. Он обеспечивает коду чистоту, соответствие лучшим практикам и отсутствие ошибок или проблем с производительностью. Создав PR, поручите рецензирование кому-то, кто имеет опыт работы с кодовой базой, в идеале — старшему разработчику.
Рекомендуется иметь двух рецензентов для каждого PR. Это помогает выявить больше проблем и способствует обмену знаниями между членами команды.
Слияние
Последний шаг в рабочем процессе на GitHub — слияние PR с основной веткой. После одобрения и слияния PR связанная с ним проблема будет автоматически закрыта. Не забудьте удалить ветку после слияния, чтобы сохранить репозиторий чистым.
Как только код окажется в основной ветке, он будет готов к производству, и изменения станут видны пользователям. Команда может праздновать очередной этап успешного сотрудничества!
Подведение итогов
Вкратце повторим основные моменты рабочего процесса на GitHub.
- Оповещение о проблеме. Назовите проблему, следуя схеме: [<type>]: <short-description> ([FIX]: Fix auth flow).
- Создание ветки. Назовите ее, следуя схеме: <type>/<issue-number>/<short-description> (fix/92/fix_auth_flow).
- Создание коммитов. Используйте для коммитов краткие, описательные сообщения, например feat: implement dashboard header.
- Создание PR (запроса на включение изменений). Используйте понятное название, отражающее имя ветки, например feature/implement-dashboard.
- Рецензирование кода. Назначьте одного или двух рецензентов для проверки кода перед слиянием.
- Слияние и очистка. Объедините PR, закройте проблему и удалите ветку.
Типы
Могут включать: feat, style, fix, enhance, refactor, docs.
Области действия
Могут быть: front, back, api, db, docs, test, chore.
Инструменты
Можете использовать Git-хук под названием pre-commit, чтобы обеспечить соблюдение формата сообщений коммитов.
Поначалу этот рабочий процесс может показаться сложным, но со временем станет привычным.
Читайте также:
- Как написать хороший README: краткий курс
- GitHub Actions и Vercel — быстрое развертывание проектов
- Как стать Git-мастером: 7 советов по повышению производительности
Читайте нас в Telegram, VK и Дзен
Перевод статьи Hüsam: GitHub Workflow (as a Pro)