freeCodeCamp/docs/i18n/ukrainian/how-to-open-a-pull-request.md

Як відкрити запит на злиття (PR)

Запит на злиття (PR) дозволяє надсилати зміни зі свого форку на GitHub до головного репозиторію freeCodeCamp.org. Як тільки ви закінчите вносити зміни до коду, дотримуйтесь цих рекомендацій, щоб відкрити PR.

Ми очікуємо, що наші помічники обізнані щодо процесу проєкту. Ви заощадите час та отримаєте повагу тих, хто відповідає за технічне обслуговування, дотримуючись цих вказівок.

Деякі приклади:

1. Не редагуйте файли напряму через GitHub, це не дуже хороша ідея.

2. Переконайтесь, що заголовок для PR відповідає нашій конвенції.

3. Переконайтесь, що дотримуєтесь контрольного списку PR, а не просто ставите галочки. В такому випадку ми не сприйматимемо вас серйозно.

4. Використовуйте правильний спосіб пов’язати завдання в описі PR, оновивши XXXXXX. Не додавайте номери завдань будь-де.

5. Не «@згадуйте» чи запитуйте відгук кілька разів.

   Ми розуміємо, що ви раді зробити свій внесок. Модераторам подобається відповідати кожному, однак пам’ятайте: вони зайняті люди, які розглядають сотні запитів. Рано чи пізно, хтось дійде і до вашого запиту.

6. Не працюйте напряму зі своєї гілки main. Створіть нову гілку для змін, над якими ви працюєте.

[!NOTE] Ваш PR повинен націлюватись лише на зміни навчальної програми англійською мовою. Див. цей довідник, щоб зробити внесок до перекладу.

Підготуйте хороший заголовок для PR

Ми використовуємо загальноприйнятні заголовки та повідомлення для затверджень і запитів на злиття. Конвенція вимагає наступного формату:

<тип>([область (необов’язково)]): <опис>

Наприклад:

fix(learn): тести для завдання з циклу do...while

Щоразу, коли ви відкриваєте запит на злиття (PR), використовуйте нижчеподану інформацію, щоб визначити тип, область та опис.

Тип:

Тип	Коли обирати
fix	Змінені або оновлені/вдосконалені функції, тести, формулювання уроку тощо.
feat	Лише при додаванні нової функції, тестів тощо.
chore	Зміни, які не повʼязані з кодом, тестами або формулюванням уроку.
docs	Зміни до каталогу /docs чи настанов щодо внесків тощо.

Область:

Область можна обрати із цього списку міток.

Опис:

Опис повинен бути коротким (не більше 30 символів) та простим; більше інформації можна додати в полі опису PR та коментарях.

Декілька прикладів хороших заголовків:

• fix(a11y): improved search bar contrast
• feat: add more tests to HTML and CSS challenges
• fix(api,client): prevent CORS errors on form submission
• docs(i18n): fix links to be relative instead of absolute

Запропонуйте PR

1. Як тільки зміни будуть збережені, вам буде запропоновано створити PR на сторінці вашого розгалуження GitHub.

   Переглянути знімок екрану

   

2. Усі PR потрібно надсилати до головного репозиторію freeCodeCamp — гілки main.

   Переконайтеся, що значення base fork встановлено на freeCodeCamp/freeCodeCamp під час створення PR.

   Переглянути знімок екрану

   

3. Надішліть PR зі своєї гілки до гілки freeCodeCamp main.

4. У тілі свого PR вкажіть детальну інформацію про внесені зміни та чим вони корисні.

   • Вам буде надано шаблон PR. Це список, якого потрібно дотримуватись перед відкриттям PR.

   • Заповніть деталі, які ви вважаєте за потрібне. Переконайтеся, що надали рецензентам достатньо контексту для перегляду змін. Якщо PR вносить зміни до інтерфейсу, обов’язково використайте знімки екрана зі змінами. Ця інформація буде розглянута, а рецензенти вирішать, чи ваш PR буде прийнятий.

   • Якщо PR призначений для вирішення наявного завдання на GitHub, то використайте ключове слово Closes та номер завдання в кінці опису, щоб автоматично закрити цю проблему, якщо PR прийнятий та об’єднаний.

     Наприклад: Closes#123 закриватиме завдання 123

5. Вкажіть, чи ви проводили тести на локальній копії сайту.

   • Це надзвичайно важливо при внесенні змін, які не стосуються зміни тексту (наприклад, документації чи опису завдань). До змін, яким потрібне локальне тестування, входять JavaScript, CSS або HTML (тобто ті, які можуть змінити функціональність чи макет сторінки).

   • Якщо ваш PR впливає на поведінку сторінки, він повинен супроводжуватися відповідними інтеграційними тестами Playwright.

Зворотний зв’язок по PR

🎉 Вітаємо зі створенням PR та дуже дякуємо, що знайшли час зробити свій внесок.

Наші модератори все переглянуть та залишать свій відгук. Будь ласка, наберіться терпіння та поважайте їхній час. Усі запити на злиття розглядаються за усталеним порядком.

І як завжди, не соромтесь ставити запитання на форумі у категорії «Contributors» або у чаті.

[!TIP] Якщо ви хочете внести ще більше PR, ми рекомендуємо прочитати про внесення змін та синхронізацію, щоб уникнути видалення вашого розгалуження.

Конфлікти PR

Конфлікти можуть виникнути, якщо над репозиторієм працює багато помічників. Зміни можуть вплинути на PR, який очікує на перегляд та злиття.

Оскільки ми об’єднуємо всі затвердження, можливо, вам не знадобиться перебазовування. Якщо перебазовування обов’язкове, див. розділи «Звичайні помилки та функціональності» або «Майбутня навчальна програма та функціональності», щоб дізнатись процес для відповідного PR.

Звичайні помилки та функціональності

Коли ви працюєте над звичайними помилками та функціональностями на нашій гілці розробки main, ви можете виконати просте перебазовування:

1. Перебазуйте свою локальну копію:

   git checkout <pr-branch>
   git pull --rebase upstream main
   

2. Вирішіть будь-які конфлікти та додайте/редагуйте затвердження

   # Або
   git add .
   git commit -m "chore: resolve conflicts"
   
   # Або
   git add .
   git commit --amend --no-edit
   

3. Відправте зміни до PR

   git push --force origin <pr-branch>
   

Майбутня навчальна програма та функціональності

Коли ви працюєте над функціональностями для майбутньої навчальної програми на гілках next-*, потрібно виконати команду cherry-pick:

1. Переконайтесь, що upstream синхронізовано з локальною гілкою:

   git checkout main
   git fetch --all --prune
   git checkout next-python-projects
   git reset --hard upstream/next-python-projects
   

2. Зробіть резервну копію

   a. Або видаліть локальну гілку після створення резервної копії (якщо вона досі існує локально):

   git checkout <pr-branch-name>
   
   # приклад:
   # git checkout feat/add-numpy-video-question
   
   git checkout -b <backup-branch-name>
   
   # приклад:
   #  git checkout -b backup-feat/add-numpy-video-question
   
   git branch -D <pr-branch-name>
   

   b. Або зробіть резервну копію гілки PR (якщо вона не існує локально):

   git checkout -b <backup-branch-name> origin/<pr-branch-name>
   
   # приклад:
   #  git checkout -b backup-feat/add-numpy-video-question origin/feat/add-numpy-video-question
   

3. Розпочніть з нуля:

   git checkout -b <pr-branch-name> next-python-projects
   git cherry-pick <commit-hash>
   

4. Розв’яжіть будь-які конфлікти, поприбирайте, встановіть залежності та запустіть тести

   pnpm run clean
   
   pnpm install
   FCC_SUPERBLOCK='<superblock-name>' pnpm run test:curriculum 
   
   # приклад:
   
   # FCC_SUPERBLOCK='python-for-everybody' pnpm run test:curriculum
   
   

5. Якщо все виглядає добре, передайте до PR

   git push --force origin <pr-branch-name>