Пошук уроків, статей та іншого контенту
Створите fork, підготуєте гілку змін і відкриєте Pull Request для внесення коду до чужого репозиторію.
Fork — це особиста копія чужого репозиторію у вашому обліковому записі на платформі для хостингу Git-репозиторіїв. Ви отримуєте право вільно змінювати цю копію, навіть якщо не маєте права запису до оригінального репозиторію.
Pull Request (PR) — запит на внесення ваших змін з fork або окремої гілки до іншого репозиторію. Власники проєкту можуть:
переглянути зміни;
залишити коментарі;
попросити виправлення;
схвалити PR;
об’єднати зміни з цільовою гілкою.
Типовий процес виглядає так:
Створити fork оригінального репозиторію.
Клонувати fork локально.
Додати оригінальний репозиторій як upstream.
Створити окрему гілку для змін.
Внести та перевірити зміни.
Опублікувати гілку у своєму fork.
Відкрити Pull Request до оригінального репозиторію.
На сторінці потрібного репозиторію натисніть Fork і виберіть свій обліковий запис.
Після цього у вас з’являться два репозиторії:
оригінальний репозиторій — джерело проєкту, зазвичай позначається як
upstreamваш fork — копія у вашому обліковому записі, з якою ви працюватимете та до якої маєте право запису.
Fork є окремим репозиторієм, але він зберігає зв’язок з оригінальним проєктом. Завдяки цьому платформа може показати, між якими репозиторіями створюється Pull Request.
Скопіюйте адресу вашого fork і клонуйте його локально:
git clone https://github.com/YOUR-USERNAME/project.git
cd projectПісля клонування Git зазвичай автоматично налаштовує віддалений репозиторій origin. У цьому випадку origin вказує саме на ваш fork:
git remote -vПриклад результату:
origin https://github.com/YOUR-USERNAME/project.git (fetch)
origin https://github.com/YOUR-USERNAME/project.git (push)Назва origin є лише локальним псевдонімом. Вона не означає «оригінальний репозиторій». У нашому процесі origin — це ваш fork.
Додайте адресу оригінального репозиторію під назвою upstream:
git remote add upstream https://github.com/ORIGINAL-OWNER/project.git
git remote -vТепер має бути два віддалені репозиторії:
origin https://github.com/YOUR-USERNAME/project.git (fetch)
origin https://github.com/YOUR-USERNAME/project.git (push)
upstream https://github.com/ORIGINAL-OWNER/project.git (fetch)
upstream https://github.com/ORIGINAL-OWNER/project.git (push)Зазвичай до origin ви надсилаєте власні зміни, а з upstream отримуєте оновлення оригінального проєкту.
Не вносьте зміни безпосередньо в main. Для кожної задачі створюйте окрему гілку.
Спочатку отримайте актуальну інформацію з оригінального репозиторію:
git fetch upstreamСтворіть гілку на основі актуальної main:
git switch -c fix-validation upstream/mainУ цьому прикладі:
fix-validation — назва нової гілки;
upstream/main — стан гілки main в оригінальному репозиторії;
git switch -c створює гілку та одразу перемикає на неї.
Якщо основна гілка проєкту називається не main, використайте її фактичну назву, наприклад master або develop.
Назва гілки має описувати зміни:
fix-validation
add-search-filter
update-api-docsВнесіть зміни у файли проєкту, після чого перевірте їхній стан:
git status
git diffgit status показує змінені та нові файли, а git diff — безпосередній вміст змін.
Додайте потрібні файли до індексу:
git add src/validation.jsАбо додайте всі зміни, якщо впевнені, що зайві файли не потраплять у коміт:
git add .Перевірте, що саме буде включено до коміту:
git diff --stagedСтворіть коміт із коротким описом:
git commit -m "Fix form validation"Повідомлення коміту має описувати виконану зміну, а не загальну дію на кшталт Update files.
Перед публікацією гілки запустіть доступні в проєкті перевірки. Наприклад:
npm testКонкретна команда залежить від самого проєкту. Орієнтуйтеся на його документацію та налаштування.
Надішліть локальну гілку до вашого fork:
git push -u origin fix-validationПараметр -u встановлює зв’язок між локальною гілкою fix-validation і віддаленою гілкою з такою самою назвою. Надалі достатньо буде виконувати:
git pushПісля успішного push платформа зазвичай покаже пропозицію створити Pull Request для щойно опублікованої гілки.
На сторінці вашого fork відкрийте форму створення Pull Request. Перевірте напрямок змін:
base repository — оригінальний репозиторій;
base branch — гілка, до якої мають потрапити зміни;
head repository — ваш fork;
compare branch — ваша гілка зі змінами.
Наприклад:
ORIGINAL-OWNER/project:main
←
YOUR-USERNAME/project:fix-validationНе плутайте цільову та вихідну гілки. Вам потрібно запропонувати зміни з вашого fork до оригінального репозиторію, а не навпаки.
Добрий Pull Request містить:
короткий заголовок, що описує основну зміну;
пояснення проблеми;
опис реалізованого рішення;
інформацію про виконані перевірки;
посилання на задачу або issue, якщо це передбачено процесом проєкту.
Приклад опису:
## Що змінено
Виправлено перевірку електронної адреси у формі реєстрації.
## Чому
Порожнє значення проходило перевірку як коректна адреса.
## Перевірка
- npm test
- Перевірено реєстрацію з порожнім полем emailОдин PR бажано присвячувати одній логічній задачі. Не додавайте до нього випадкове форматування, перейменування файлів або зміни, які не стосуються задачі.
Після створення PR інші учасники можуть залишити коментарі або попросити зміни. Виправлення вносяться у ту саму локальну гілку:
git switch fix-validation
# Внесіть виправлення після рев'ю
git add src/validation.js
git commit -m "Address review comments"
git pushНовий коміт автоматично з’явиться у відкритому Pull Request. Створювати новий PR для кожного виправлення не потрібно.
Після внесення змін:
перечитайте коментарі рев’ю;
внесіть необхідні виправлення;
повторно запустіть перевірки;
опублікуйте нові коміти;
відповідайте на коментарі, пояснюючи виконані зміни.
Оригінальний репозиторій може змінитися після створення вашого fork. Перед початком нової задачі отримайте оновлення:
git fetch upstream
git switch main
git pull --ff-only origin main
git merge upstream/main
git push origin mainПісля цього створюйте нову гілку від актуальної main:
git switch -c add-search-filtergit pull --ff-only не створює неочікуваного merge-коміту. Якщо локальна main має власні коміти, команда завершиться з помилкою, і ситуацію можна буде перевірити окремо.
Якщо main в оригінальному репозиторії змінилася, ваш PR може застаріти або отримати конфлікти. Спочатку отримайте новий стан:
git fetch upstreamПерейдіть на гілку PR:
git switch fix-validationОб’єднайте оновлення цільової гілки зі своєю гілкою:
git merge upstream/mainЯкщо виникли конфлікти:
відкрийте файли, позначені Git;
вручну залиште правильний варіант;
видаліть маркери конфлікту <<<<<<<, =======, >>>>>>>;
додайте виправлені файли;
завершіть merge-комітом.
git add .
git commit
git pushПісля push Pull Request оновиться автоматично.
Нижче наведено типовий сценарій від клонування fork до відкриття PR:
# Клонування власного fork
git clone https://github.com/YOUR-USERNAME/project.git
cd project
# Додавання оригінального репозиторію
git remote add upstream https://github.com/ORIGINAL-OWNER/project.git
# Отримання актуального стану оригінального репозиторію
git fetch upstream
# Створення гілки для окремої задачі
git switch -c fix-validation upstream/main
# Після редагування файлів перевірка змін
git status
git diff
# Додавання зміненого файлу
git add src/validation.js
# Перевірка підготовлених змін
git diff --staged
# Створення коміту
git commit -m "Fix form validation"
# Запуск тестів проєкту
npm test
# Публікація гілки у власному fork
git push -u origin fix-validationПісля останньої команди відкрийте Pull Request з YOUR-USERNAME/project:fix-validation до ORIGINAL-OWNER/project:main.
mainЦе ускладнює роботу над кількома задачами та може призвести до випадкової публікації незавершених змін.
Створюйте окрему гілку до редагування файлів:
git switch -c name-of-changeorigin вказує не на forkПеревірте віддалені репозиторії:
git remote -vДля стандартного процесу origin має вказувати на ваш fork, а upstream — на оригінальний репозиторій.
Перед створенням PR перевірте:
оригінальний репозиторій є цільовим;
ваша гілка у fork є джерелом;
обрана правильна цільова гілка.
Це часто трапляється, коли гілку створили від застарілої або неправильної бази. Створюйте її від актуальної upstream/main і не змішуйте кілька задач в одній гілці.
Переконайтеся, що:
git status
git log --oneline -n 3
git pushФайли повинні бути закомічені, а коміт — надісланий саме в гілку, з якої створено PR.
Перед git commit використовуйте:
git diff --stagedЯкщо файл додано помилково, приберіть його з індексу, не видаляючи локально:
git restore --staged path/to/fileFork — ваша копія чужого репозиторію, до якої ви маєте право запису.
Pull Request — запит на внесення змін із вашої гілки до оригінального репозиторію.
origin зазвичай вказує на ваш fork.
upstream вказує на оригінальний репозиторій.
Для кожної задачі створюйте окрему гілку.
Перед PR перевіряйте зміни, запускайте тести та публікуйте гілку через git push.
Нові коміти в ту саму гілку автоматично оновлюють відкритий Pull Request.
Перед початком роботи синхронізуйте локальну базову гілку з upstream.