本文档旨在帮助你开始使用 git 与 Gutenberg 协作。Git 是一个强大的源代码管理工具；如果想深入学习 git，请查阅可在线免费阅读的《Pro Git》一书，该书以 CC BY-NC-SA 3.0 许可协议发布。
如果你不熟悉 git 的使用，值得去探索和练习一下。可以试试 git 教程以及 git 用户手册，以帮助你入门。
Gutenberg 项目遵循标准的拉取请求（pull request）流程进行贡献。有关拉取请求的更多细节，请参阅 GitHub 文档中的拉取请求相关详情。
概述
贡献者的流程概览如下：
- Fork Gutenberg 仓库。
- 克隆 fork 后的仓库。
- 创建一个新分支。
- 进行代码更改。
- 确认测试通过。
- 在新创建的分支内提交代码更改。
- 将该分支推送到 fork 后的仓库。
- 向 Gutenberg 仓库提交拉取请求。
有关 Gutenberg 项目如何使用 GitHub 的更多信息，请参阅仓库管理文档。
Git 工作流程详解
代码和文档的工作流程是相同的，因为两者都在 GitHub 中管理。你可以观看贡献文档的视频教程以及配套的向 Gutenberg 贡献的教程。
下面是 Git 工作流程的可视化概览：
第 1 步：前往 GitHub 上的 Gutenberg 仓库并点击 Fork。这会将主 Gutenberg 仓库的一个副本创建到你的账户中。
第 2 步：将你 fork 的仓库克隆到本地。它位于：`https://github.com/YOUR-USER-NAME/gutenberg`。克隆会将所有文件复制到你的计算机上。打开终端并运行：
git clone https://github.com/YOUR-USER-NAME/gutenberg
这将创建一个名为 gutenberg 的目录，其中包含该项目的所有文件。这可能需要几分钟时间，因为它会下载整个 Gutenberg 项目的历史记录。
第 3 步：为你的更改创建一个分支（分支命名见下文）。在本例中，分支名是完整的字符串：update/my-branch
git switch -c update/my-branch
第 4 步：进行代码更改。构建、确认并彻底测试你的更改。请参阅编码指南和测试概览以获取指导。
第 5 步：使用一条规范的提交信息提交你的更改。这会将你的更改提交到仓库的本地副本。
git commit -m "Your Good Commit Message" path/to/FILE
第 6 步：将你的更改推送到 GitHub。更改将被推送到 GitHub 上你的仓库 fork 中
git push -u origin update/my-branch
第 7 步：前往 GitHub 上你 fork 的仓库——它会自动检测到该更改，并为你提供一个创建拉取请求的链接。
第 8 步：创建拉取请求。这将在 WordPress Gutenberg 仓库上创建请求，以整合来自你 fork 仓库的更改。
第 9 步：持续关注拉取请求上的新动态。如果被要求进行任何额外的更改或更新，请在本地进行更改并推送，按照第 4-6 步操作。
不要为更新创建新的拉取请求；通过将你的更改推送到你的仓库，它会更新同一个 PR。从这个意义上说，PR 是 WordPress Gutenberg 仓库上指向你副本的一个指针。因此，当你更新你的副本时，PR 也会随之更新。
就是这样！一旦获得批准并合并，你的更改将被并入主仓库。🎉
分支命名
你应该使用前缀加简短描述来命名分支，如下所示：[type]/[change]。
建议的前缀：
add/= 添加新功能try/= 实验性功能，“尝试添加”update/= 更新现有功能remove/= 移除现有功能fix/= 修复现有问题
例如，add/gallery-block 表示你正在致力于添加一个新的相册区块（gallery block）。
保持分支最新
当许多不同的人同时参与一个项目时，拉取请求很快就会过时。“过时的”拉取请求是指不再与主线开发保持同步的请求，在合并到项目之前需要对其进行更新。
有两种方法可以做到这一点：合并（merge）和变基（rebase）。在 Gutenberg 中，推荐使用变基。变基意味着重写你的更改，就好像它们是在主线开发之上进行的一样。这可以确保提交历史始终保持干净且线性。在处理拉取请求期间，可以根据需要多次执行变基。请尽早分享你的工作，即创建拉取请求，并在推进过程中保持历史变基。
主线开发被称为 trunk 分支。如果你有一个因冲突而无法合并到 trunk 的拉取请求分支（这种情况可能发生在长期运行的拉取请求中），那么在变基过程中，你需要在本地副本中手动解决所有冲突。了解更多信息，请参阅《How to Rebase a Pull Request》的 Perform a rebase 一节。
在本地解决所有冲突后，你可以使用 git push --force-with-lease 更新拉取请求。使用 --force-with-lease 参数很重要，它可以确保你不会意外覆盖他人的工作。
总而言之，你需要获取仓库中的任何新更改，将你的分支变基到 trunk 之上，并将结果推送回仓库。以下是对应的命令：
git fetch
git rebase trunk
git push --force-with-lease origin your-branch-name
保持你的 fork 最新
参与拉取请求的工作始于 fork Gutenberg 仓库，也就是你的独立工作副本。随着新的拉取请求被合并到主仓库，这个副本很容易失去同步。这里，你的工作仓库是 fork，而 Gutenberg 主仓库是 upstream。在处理新的拉取请求时，你应该始终先更新你的 fork，然后再执行 git checkout -b my-new-branch 来开发某项功能或修复。
你需要添加一个 upstream 远程仓库，以保持你的 fork 处于最新状态。
git remote add upstream https://github.com/WordPress/gutenberg.git
git remote -v
origin git@github.com:your-account/gutenberg.git (fetch)
origin git@github.com:your-account/gutenberg.git (push)
upstream https://github.com/WordPress/gutenberg.git (fetch)
upstream https://github.com/WordPress/gutenberg.git (push)
要同步你的 fork，你首先需要获取 upstream 的更改并将它们合并到你的本地副本：
git fetch upstream
git checkout trunk
git merge upstream/trunk
一旦你的本地副本更新完毕，推送你的更改以更新 GitHub 上的 fork：
git push
以上命令将从 upstream 更新你的 trunk 分支。要更新任何其他分支，请将 trunk 替换为相应的分支名称。
其他
Git 考古
在查找引入某项特定更改的提交时，忽略仅包含样式或格式更改的修订版本可能会很有帮助。
幸运的是，较新版本的 git 获得了跳过历史中某些提交的功能：
git blame --ignore-rev f63053cace3c02e284f00918e1854284c85b9132 -L 66,73 packages/api-fetch/src/middlewares/media-upload.js
所有样式和格式修订版本都通过 Gutenberg 仓库中的 .git-blame-ignore-revs 文件进行跟踪。你可以使用此文件一次性忽略它们：
git blame --ignore-revs-file .git-blame-ignore-revs -L 66,73 packages/api-fetch/src/middlewares/media-upload.js