发起拉取请求
注意
代码开发人员:如果你正在为即将发布的 Kubernetes 版本编写新功能的文档,请参阅为新功能编写文档。要贡献新的内容页面或改进现有的内容页面,请发起一个拉取请求(PR)。请确保遵循开始之前部分中的所有要求。
如果你的更改很小,或者你不熟悉 Git,请阅读使用 GitHub 进行更改,了解如何编辑页面。
如果你的更改很大,请阅读从本地 fork 工作,了解如何在你的计算机本地进行更改。
使用 GitHub 进行更改
如果你对 Git 工作流程不太熟悉,这里有一个更简单的发起拉取请求的方法。图 1 概述了步骤,详细信息如下。
图 1. 使用 GitHub 发起 PR 的步骤。
在出现问题的页面上,选择右侧导航面板中的编辑此页面选项。
在 GitHub Markdown 编辑器中进行更改。
在编辑器下方,填写提议文件更改表单。在第一个字段中,为你的提交消息添加标题。在第二个字段中,提供描述。
注意
不要在你的提交消息中使用任何 GitHub 关键字。你可以稍后将它们添加到拉取请求描述中。选择提议文件更改。
选择创建拉取请求。
将出现打开拉取请求屏幕。填写表单
- 拉取请求的 Subject 字段默认为提交摘要。你可以根据需要更改它。
- Body 包含你扩展的提交消息(如果有)和一些模板文本。添加模板文本要求提供的详细信息,然后删除额外的模板文本。
- 保持选中 允许维护人员编辑 复选框。
注意
PR 描述是帮助审阅者理解你的更改的好方法。有关更多信息,请参阅打开 PR。选择创建拉取请求。
在 GitHub 中处理反馈
在合并拉取请求之前,Kubernetes 社区成员会对其进行审查并批准。k8s-ci-robot
会根据页面中提及的最近的所有者建议审查者。如果你心中有特定的人,请在评论中留下他们的 GitHub 用户名。
如果审阅者要求你进行更改
- 转到 Files changed 选项卡。
- 在拉取请求更改的任何文件上,选择铅笔(编辑)图标。
- 进行请求的更改。
- 提交更改。
如果你正在等待审阅者,请每 7 天联系一次。你也可以在 #sig-docs
Slack 频道中发布消息。
当你的审查完成时,审阅者会合并你的 PR,你的更改会在几分钟后生效。
从本地 fork 工作
如果你对 Git 更有经验,或者你的更改大于几行,请从本地 fork 工作。
请确保你的计算机上安装了 git。你也可以使用 Git UI 应用程序。
图 2 显示了从本地 fork 工作时要遵循的步骤。每个步骤的详细信息如下。
图 2. 从本地 fork 工作以进行更改。
Fork kubernetes/website 存储库
- 导航到
kubernetes/website
存储库。 - 选择 Fork。
创建本地克隆并设置上游
在终端窗口中,克隆你的 fork 并更新 Docsy Hugo 主题
git clone [email protected]:<github_username>/website cd website git submodule update --init --recursive --depth 1
导航到新的
website
目录。将kubernetes/website
存储库设置为upstream
远程cd website git remote add upstream https://github.com/kubernetes/website.git
确认你的
origin
和upstream
存储库git remote -v
输出类似于
origin [email protected]:<github_username>/website.git (fetch) origin [email protected]:<github_username>/website.git (push) upstream https://github.com/kubernetes/website.git (fetch) upstream https://github.com/kubernetes/website.git (push)
从你的 fork 的
origin/main
和kubernetes/website
的upstream/main
中获取提交git fetch origin git fetch upstream
这确保你的本地存储库在你开始进行更改之前是最新的。
创建一个分支
确定你的工作基于哪个分支
- 对于对现有内容的改进,请使用
upstream/main
。 - 对于有关现有功能的新内容,请使用
upstream/main
。 - 对于本地化的内容,请使用本地化的约定。有关更多信息,请参阅本地化 Kubernetes 文档。
- 对于即将发布的 Kubernetes 版本中的新功能,请使用功能分支。有关更多信息,请参阅为发布版本编写文档。
- 对于多个 SIG Docs 贡献者协作进行的长期工作,如内容重组,请使用为该工作创建的特定功能分支。
如果你需要帮助选择分支,请在
#sig-docs
Slack 频道中提问。- 对于对现有内容的改进,请使用
基于步骤 1 中确定的分支创建一个新分支。此示例假设基本分支是
upstream/main
git checkout -b <my_new_branch> upstream/main
使用文本编辑器进行更改。
随时使用 git status
命令查看你已更改的文件。
提交你的更改
当你准备好提交拉取请求时,提交你的更改。
在你的本地存储库中,检查你需要提交哪些文件
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 "Your commit message"
注意
不要在你的提交消息中使用任何 GitHub 关键字。你可以稍后将它们添加到拉取请求描述中。将你的本地分支及其新提交推送到你的远程 fork
git push origin <my_new_branch>
在本地预览你的更改
在推送更改或打开拉取请求之前,最好在本地预览您的更改。预览可以让您捕获构建错误或 Markdown 格式问题。
您可以构建网站的容器镜像,也可以在本地运行 Hugo。构建容器镜像速度较慢,但会显示 Hugo 短代码,这对于调试很有用。
注意
以下命令默认使用 Docker 作为容器引擎。设置CONTAINER_ENGINE
环境变量可以覆盖此行为。在本地构建容器镜像
只有在测试对 Hugo 工具本身的更改时才需要此步骤# Run this in a terminal (if required) make container-image
在容器中启动 Hugo
# Run this in a terminal make container-serve
在 Web 浏览器中,导航到
https://127.0.0.1:1313
。Hugo 会监视更改并根据需要重建站点。要停止本地 Hugo 实例,请返回终端并键入
Ctrl+C
,或关闭终端窗口。
或者,在您的计算机上安装并使用 hugo
命令
安装 Hugo 版本,该版本在
website/netlify.toml
中指定。如果您尚未更新您的网站存储库,则
website/themes/docsy
目录为空。如果没有主题的本地副本,则无法构建站点。要更新网站主题,请运行git submodule update --init --recursive --depth 1
在终端中,转到您的 Kubernetes 网站存储库并启动 Hugo 服务器
cd <path_to_your_repo>/website hugo server --buildFuture
在 Web 浏览器中,导航到
https://127.0.0.1:1313
。Hugo 会监视更改并根据需要重建站点。要停止本地 Hugo 实例,请返回终端并键入
Ctrl+C
,或关闭终端窗口。
从您的 fork 向 kubernetes/website 打开拉取请求
图 3 显示了从您的 fork 向 kubernetes/website 打开 PR 的步骤。详细信息如下。
请注意,贡献者可以将 kubernetes/website
简称为 k/website
。
图 3. 从您的 fork 向 kubernetes/website 打开 PR 的步骤。
在 Web 浏览器中,转到
kubernetes/website
存储库。选择 New Pull Request(新建拉取请求)。
选择 compare across forks(跨分支比较)。
从 head repository(头部存储库)下拉菜单中,选择您的 fork。
从 compare(比较)下拉菜单中,选择您的分支。
选择 Create Pull Request(创建拉取请求)。
为您的拉取请求添加描述
标题(50 个字符或更少):总结更改的意图。
描述:更详细地描述更改。
- 如果存在相关的 GitHub 问题,请在描述中包含
Fixes #12345
或Closes #12345
。如果使用了 GitHub 的自动化功能,会在合并 PR 后关闭提到的问题。如果还有其他相关的 PR,请同时链接它们。 - 如果您想就特定内容征求意见,请在描述中包含您希望审阅者考虑的任何问题。
- 如果存在相关的 GitHub 问题,请在描述中包含
选择 Create pull request(创建拉取请求)按钮。
恭喜!您的拉取请求可以在 Pull requests(拉取请求)中找到。
打开 PR 后,GitHub 会运行自动化测试并尝试使用 Netlify 部署预览。
- 如果 Netlify 构建失败,请选择 Details(详细信息)以获取更多信息。
- 如果 Netlify 构建成功,选择 Details(详细信息)将打开一个已应用您更改的 Kubernetes 网站的暂存版本。审阅者会通过这种方式检查您的更改。
GitHub 还会自动为 PR 分配标签,以帮助审阅者。您也可以根据需要添加它们。有关更多信息,请参阅 添加和删除问题标签。
在本地处理反馈
在进行更改后,修改您之前的提交
git commit -a --amend
-a
:提交所有更改--amend
:修改之前的提交,而不是创建新的提交
如果需要,请更新您的提交消息。
使用
git push origin <my_new_branch>
推送您的更改并重新运行 Netlify 测试。
审阅者的更改
有时审阅者会提交到您的拉取请求。在进行任何其他更改之前,请获取这些提交。
从您的远程 fork 获取提交并变基您的工作分支
git fetch origin git rebase origin/<your-branch-name>
变基后,强制推送新更改到您的 fork
git push --force-with-lease origin <your-branch-name>
合并冲突和变基
如果另一位贡献者在另一个 PR 中更改了同一文件,则可能会产生合并冲突。您必须解决 PR 中的所有合并冲突。
更新您的 fork 并变基您的本地分支
git fetch origin git rebase origin/<your-branch-name>
然后强制将更改推送到您的 fork
git push --force-with-lease origin <your-branch-name>
从
kubernetes/website
的upstream/main
获取更改并变基您的分支git fetch upstream git rebase upstream/main
检查变基的结果
git status
这将导致许多文件标记为冲突。
打开每个冲突文件,并查找冲突标记:
>>>
、<<<
和===
。解决冲突并删除冲突标记。注意
有关更多信息,请参阅 如何呈现冲突。将文件添加到变更集
git add <filename>
继续变基
git rebase --continue
根据需要重复步骤 2 到 5。
应用所有提交后,
git status
命令将显示变基已完成。强制将分支推送到您的 fork
git push --force-with-lease origin <your-branch-name>
拉取请求不再显示任何冲突。
压缩提交
如果您的 PR 有多个提交,则必须在合并 PR 之前将其压缩为一个提交。您可以通过 PR 的 Commits(提交)选项卡或在本地运行 git log
命令来检查提交次数。
注意
本主题假定使用vim
作为命令行文本编辑器。启动交互式变基
git rebase -i HEAD~<number_of_commits_in_branch>
压缩提交是变基的一种形式。
-i
开关告诉 git 您要进行交互式变基。HEAD~<number_of_commits_in_branch
表示在变基中查看多少个提交。输出类似于
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.
输出的第一部分列出了变基中的提交。第二部分列出了每个提交的选项。更改
pick
一词会在变基完成后更改提交的状态。出于变基的目的,请关注
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 时,请确保尽可能详细地填写模板。
下一步是什么
- 阅读 审阅 以了解有关审阅过程的更多信息。