Щоб створити нові сторінки або покращити наявні, відкрийте pull request (PR). Переконайтеся, що ви виконали всі вимоги у розділі Перш ніж почати.
Якщо ваша зміна невелика або ви незнайомі з git, прочитайте Зміни за допомогою GitHub, щоб дізнатися, як редагувати сторінку.
Якщо ваші зміни значні, прочитайте Робота з локальним форком, щоб дізнатися, як внести зміни локально на вашому компʼютері.
Якщо ви менш досвідчені з робочими процесами git, ось легший спосіб відкрити pull request. На схемі 1 описані кроки, а деталі наведені нижче.
Схема 1. Кроки для відкриття PR за допомогою GitHub.
На сторінці, де ви бачите проблему, виберіть опцію Відредагувати сторінку на панелі праворуч.
Внесіть зміни у GitHub markdown редакторі.
Праворуч над редактором, оберіть Commit changes. У першому полі дайте заголовок вашому повідомленню коміту. У другому полі надайте опис.
Оберіть Propose changes.
Оберіть Create pull request.
Зʼявиться екран Open a pull request. Заповніть форму:
Оберіть Create pull request.
Перед злиттям pull request члени спільноти Kubernetes рецензують та схвалюють його. k8s-ci-robot пропонує рецензентів на основі найближчого власника, зазначеного на сторінках. Якщо у вас є конкретна людина на думці, залиште коментар із її імʼям користувача на GitHub.
Якщо рецензент попросить вас внести зміни:
Якщо ви чекаєте на рецензента, виходьте на звʼязок хоча б раз на 7 днів. Ви також можете залишити повідомлення у каналі #sig-docs на Slack.
Коли рецензування буде завершено, рецензент зіллє ваш PR і ваші зміни стануть доступними через кілька хвилин.
Якщо ви більш досвідчені з git або ваші зміни більші за кілька рядків, працюйте з локальним форком.
Переконайтеся, що на вашому компʼютері встановлений git. Ви також можете використовувати застосунок, що є інтерфейсом користувача для git.
Схема 2 показує кроки, які слід виконати під час роботи з локальним форком. Деталі кожного кроку наведені нижче.
Схема 2. Робота з локальним форком для внесення змін.
kubernetes/website.У вікні термінала, клонуйте ваш форк та оновіть тему Docsy Hugo:
git clone git@github.com:<github_username>/website.git
cd website
Перейдіть до нової теки website. Встановіть репозиторій kubernetes/website як upstream remote:
cd website
git remote add upstream https://github.com/kubernetes/website.git
перевірте ваші origin та upstream репозиторії:
git remote -v
Вихід буде подібним до:
origin git@github.com:<github_username>/website.git (fetch)
origin git@github.com:<github_username>/website.git (push)
upstream https://github.com/kubernetes/website.git (fetch)
upstream https://github.com/kubernetes/website.git (push)
Отримайте коміти з origin/main вашого форка та upstream/main з kubernetes/website:
git fetch origin
git fetch upstream
Це забезпечить актуальність вашого локального репозиторію перед тим, як ви почнете вносити зміни.
main з upstream/main перед тим, як надсилати оновлення до вашого форка.Виберіть гілку, на якій буде базуватись ваша робота:
upstream/main.upstream/main.Якщо вам потрібна допомога з вибором гілки, запитайте у каналі #sig-docs в Slack.
Створіть нову гілку на основі гілки, визначеної на кроці 1. Цей приклад передбачає, що базова гілка — upstream/main:
git checkout -b <my_new_branch> upstream/main
Внесіть свої зміни за допомогою текстового редактора.
У будь-який час використовуйте команду git status, щоб побачити, які файли ви змінили.
Коли ви готові подати pull request, збережіть ваші зміни.
У вашому локальному репозиторії перевірте, які файли потрібно зберегти в репо:
git status
Вихід буде подібним до:
On branch <my_new_branch>
Your branch is up to date with 'origin/<my_new_branch>'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: content/en/docs/contribute/new-content/contributing-content.md
no changes added to commit (use "git add" and/or "git commit -a")
Додайте файли, зазначені під Changes not staged for commit, до коміту:
git add <your_file_name>
Повторіть це для кожного файлу.
Після додавання всіх файлів створіть коміт:
git commit -m "Ваше коміт-повідомлення"
Надішліть вашу локальну гілку та її новий коміт до вашого віддаленого форку:
git push origin <my_new_branch>
Перед тим, як відправити зміни або відкрити pull request, рекомендується попередньо переглянути їх локально. У статті Попередній перегляд локально пояснюється, як запустити вебсайт локально та переглянути запропоновані зміни.
На схемі 3 показано кроки для створення PR із вашого форку в kubernetes/website. Подробиці наведені нижче.
Зверніть увагу, що учасники можуть також згадувати kubernetes/website як k/website.
Схема 3. Кроки для створення PR з вашого форка в kubernetes/website.
У вебоглядачі перейдіть до репозиторію kubernetes/website.
Оберіть New Pull Request.
Оберіть compare across forks.
У спадному меню head repository, оберіть ваш форк.
У спадному меню compare, оберіть вашу гілку.
Оберіть Create Pull Request.
Додайте опис до вашого pull request:
Title (50 символів або менше): Стисло опишіть мету зміни.
Description: Опишіть зміну докладніше.
Fixes #12345 або Closes #12345 в описі. Автоматизація GitHub закриває зазначений тікет після злиття PR, якщо це використано. Якщо є інші повʼязані PR, вкажіть їх також.Оберіть кнопку Create pull request.
Вітаємо! Ваш pull request доступний у Pull requests.
Після створення PR GitHub запускає автоматичні тести та намагається розгорнути попередній перегляд за допомогою Netlify.
GitHub також автоматично призначає мітки PR, щоб допомогти рецензентам. Ви також можете додати їх, якщо це потрібно. Для отримання додаткової інформації дивіться Додавання та видалення міток до тікетів.
Після внесення змін, відредагуйте свій попередній коміт:
git commit -a --amend
-a: комітить усі зміни--amend: редагує попередній коміт, замість створення новогоЗа потреби оновіть повідомлення коміту.
Використовуйте git push origin <my_new_branch> для надсилання змін і повторного запуску тестів Netlify.
git commit -m замість редагування, вам потрібно виконати злиття комітів перед злиттям.Іноді рецензенти вносять зміни у ваш pull request. Перед внесенням будь-яких інших змін, отримайте ці коміти.
Отримайте коміти з вашого віддаленого форку та виконайте rebase вашої робочої гілки:
git fetch origin
git rebase origin/<your-branch-name>
Після rebase, зробить примусове надсилання нових змін до вашого форку:
git push --force-with-lease origin <your-branch-name>
#sig-docs по допомогу.Якщо інший учасник вносить зміни до того самого файлу в іншому PR, це може створити конфлікт злиття. Ви повинні розвʼязати всі конфлікти злиття у вашому PR.
Оновіть ваш форк та зробіть rebase вашої локальної гілки:
git fetch origin
git rebase origin/<your-branch-name>
Після rebase, зробить примусове надсилання нових змін до вашого форку:
git push --force-with-lease origin <your-branch-name>
Отримайте зміни з upstream/main репозиторію kubernetes/website та зробіть rebase у вашій гілці:
git fetch upstream
git rebase upstream/main
Перевірте результати rebase:
git status
Це призведе до позначення деяких файлів такими, що містять конфлікти.
Відкрийте кожен файл з конфліктами та знайдіть маркери конфліктів: >>>, <<< і ===.
Розвʼяжіть конфлікт і видаліть маркер конфлікту.
Додайте файли до набору змін:
git add <filename>
Продовжіть rebase:
git rebase --continue
Повторюйте кроки 2-5 за необхідності.
Після застосування всіх комітів, команда git status показує, що rebase завершено.
Зробить примусове надсилання нових змін до вашого форку:
git push --force-with-lease origin <your-branch-name>
Пул реквест більше не показує жодних конфліктів.
#sig-docs по допомогу.Якщо ваш PR має кілька комітів, ви повинні злити їх в один коміт перед злиттям вашого PR. Ви можете перевірити кількість комітів на вкладці Commits вашого PR або за допомогою команди git log локально.
vim.Розпочніть інтерактивний rebase:
git rebase -i HEAD~<number_of_commits_in_branch>
Злиття комітів є формою rebase. Параметр -i вказує git, що ви хочете виконати інтерактивний rebase. HEAD~<number_of_commits_in_branch> вказує, скільки комітів розглядати для rebase.
Результат буде схожий на:
pick d875112ca Original commit
pick 4fa167b80 Address feedback 1
pick 7d54e15ee Address feedback 2
# Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands)
...
# These lines can be re-ordered; they are executed from top to bottom.
Перша частина результату виводить перелік комітів для rebase. Друга частина має параметри для кожного коміту. Заміна слова pick змінює статус коміту після завершення rebase.
Для цілей rebase зосередьтесь на squash і pick.
Розпочніть редагування файлу.
Змініть початковий текст:
pick d875112ca Original commit
pick 4fa167b80 Address feedback 1
pick 7d54e15ee Address feedback 2
На:
pick d875112ca Original commit
squash 4fa167b80 Address feedback 1
squash 7d54e15ee Address feedback 2
Це зливає коміти 4fa167b80 Address feedback 1 та 7d54e15ee Address feedback 2 у d875112ca Original commit, залишаючи тільки d875112ca Original commit як частину хронології.
Збережіть і вийдіть з файлу.
Надішліть ваш обʼєднаний коміт:
git push --force-with-lease origin <branch_name>
Проєкт Kubernetes містить понад 50 репозиторіїв. Багато з цих репозиторіїв містять документацію: текст довідки для користувачів, повідомлення про помилки, довідку API або коментарі в коді.
Якщо ви бачите текст, який хочете покращити, скористайтеся GitHub для пошуку по всіх репозиторіях в організації Kubernetes. Це допоможе вам зрозуміти, куди подати ваш тікет або PR.
Кожен репозиторій має свої процеси та процедури. Перед тим як подати тікет або PR, прочитайте README.md, CONTRIBUTING.md та code-of-conduct.md, якщо вони існують.
Більшість репозиторіїв використовують шаблони для тікетів і PR. Подивіться на кілька відкритих тікетів та PR, щоб зрозуміти процеси команди. Обов’язково заповнюйте шаблони з якомога більшою детальністю, коли подаєте тікет або PR.