Open Source
Fork → PR: полный цикл
GitHub показывает что у TypeScript 700+ contributors. Каждый из них прошёл один и тот же путь: fork → branch → commit → PR. Этот процесс занимает 10 минут после того как вы сделали это один раз. Давайте разберём его по шагам.
- Vite принимает сотни PR в год - все через fork workflow
- Conventional commits используют: Angular, Vue, Electron, NestJS, Jest
- Linux Kernel требует DCO sign-off в каждом коммите с 2004 года
- GitHub Actions автоматически проверяет conventional commit формат во многих проектах
Fork, clone, branch
В OSS вы не работаете напрямую в репозитории проекта - у вас нет прав. Вместо этого: **fork** создаёт копию репозитория под вашим аккаунтом, и уже туда вы пушите изменения. Затем PR связывает ваш fork с оригиналом.
**Называйте ветки осмысленно:** `fix/button-hover-state`, `feat/add-dark-mode`, `docs/update-api-reference`. Не `my-changes`, `patch-1`, `fix`. Maintainer видит десятки PR - название ветки создаёт первое впечатление.
Зачем добавлять remote `upstream` после fork?
Commit, push, PR
**Conventional Commits** - стандарт сообщений коммитов, который используют большинство крупных OSS проектов. Он позволяет автоматически генерировать CHANGELOG и определять тип version bump.
**DCO (Developer Certificate of Origin):** Некоторые проекты (Linux kernel, Node.js) требуют `Signed-off-by` в коммитах. Это значит вы подтверждаете право на публикацию кода под лицензией проекта. Добавляется через `git commit -s` или вручную: `Signed-off-by: Your Name <email@example.com>`
Какой коммит-месседж правильный для исправления краша при открытии файла с пробелом в пути?
Ключевые идеи
- Fork создаёт копию репозитория под вашим аккаунтом - вы пушите туда
- upstream remote - для синхронизации с оригиналом, origin - ваш fork
- Ветка для каждого изменения, никогда не работайте в main
- Conventional commits: тип(scope): описание - стандарт большинства OSS проектов
- DCO sign-off требуют некоторые проекты: git commit -s
Связанные темы
Знаете workflow - теперь научитесь писать хорошие issues и PR descriptions.
- Следующий урок курса — Логическое продолжение
Вопросы для размышления
- Почему важно работать в отдельной ветке для каждого изменения, а не в main своего fork?
- Что такое squash merge и когда он предпочтительнее обычного merge? Посмотрите как это настроено в GitHub репозитории vite или react.