变更请求
通过变更请求协作编辑内容
变更请求是您主要内容的一个副本。它来自于一个简单的概念， 分支，并且对任何使用 GitHub 的 pull request 或 GitLab 的 merge request 的人来说都会感觉熟悉。
在变更请求中，您可以编辑、更新和删除内容元素，要求对更改进行审查，然后将它们合并回主版本以应用您所做的所有更改。
创建变更请求
在禁用实时编辑的空间内，点击 编辑 按钮位于 空间标题 以开始新的变更请求。
这将打开一个新的变更请求，您可以根据需要编辑或删除内容。您的更改会自动保存，其他人可以加入您的变更请求以实时协作。
一旦您对更改感到满意，您可以使用标题栏中的按钮来 请求审查 您的变更请求，或 直接合并 它到主分支。
预览变更请求
您可以通过位于 空间标题的预览按钮预览在变更请求中所做的更改。这会切换到一个视图，在预览窗口中显示您的文档和拟议的更改，以便您在已发布文档的整体上下文中查看更改。
的空间的变更请求。如果您的内容是通过共享链接或经身份验证的访问发布的，则预览功能将不会出现。
请求对变更请求进行审查
当您想在将更改合并到主分支之前请团队成员检查您的内容时，请对变更请求发起审查。
您可以为变更请求添加描述以向审阅者提供一些上下文，并标注您希望检查您工作的特定人员。
当您点击 请求审查时，变更请求的状态将变为 正在审查中，并且您在审查请求中标注的任何人都会收到通知。
如果您的更改不需要审查，您也可以直接将更改合并到主版本。
审查变更请求
如果您收到审查变更请求的请求，您将能够编辑内容并留下反馈，以确保在合并到主版本之前内容处于良好状态。您可以在认为仍需改动时请求更改，或批准变更请求以表示它已准备好合并。
大多数审查将在变更请求的 评论中进行，协作者可以在此分享反馈并就特定内容模块或整个变更请求进行讨论。
差异视图
当您在空间标题中打开 更改 选项卡时，差异视图将会出现。差异视图会突出显示在变更请求中被编辑的每个页面和模块。它会在目录中突出显示任何已编辑的页面，并在页面上显示已添加、编辑或删除的具体模块。
使用差异视图时有两个选项：
显示所有页面 — 这是差异视图的默认模式，会在目录中显示已修改和未修改的页面。这有助于在整个空间的上下文中查看哪些页面已被编辑。
仅显示已更改的页面 — 此模式将在目录中仅显示已修改的页面，有助于您专注于已更改的内容。在包含许多页面和子页面的较大空间中，这尤其有用。
您可以切换到 更改 选项卡以检查任何变更请求中的差异视图。
合并变更请求
合并变更请求将把变更请求的更改添加到内容的主分支中，创建一个更新的版本并在空间的 版本历史记录.
中生成一条新条目。
安排合并 如果您希望在计划时间合并变更请求——例如，为了与您的产品发布周期保持一致——您可以使用外部工具如 GitHub Actions 或通过.
GitBook 的 API
例如，添加以下 GitHub 工作流程会每周合并一次变更请求：
.github/workflows/scheduled-gitbook-merge.yml
名称：计划的 GitBook 合并
触发：
计划：
- cron: '0 9 * * 3' # 每周三 UTC 时间 09:00 运行
作业：
merge_changes：
运行环境：ubuntu-latest
步骤：
- 名称：合并变更请求
运行： |
curl -X POST https://api.gitbook.com/v1/spaces/{space-id}/change-requests/{change-request-id}/merge \管理员、创建者和审阅者
可以合并变更请求。
处理合并冲突
有时，当您想要合并变更请求时，可能会发现主内容与您试图合并的内容之间存在冲突。最简单的形式，冲突是无法自动合并的一段内容。
如果发生这种情况，系统会向您显示冲突警报，以及在继续合并之前需要解决的冲突列表。 解决合并冲突 或 在解决合并冲突时，您有两种选项—— 选择要合并的版本.
手动
编辑内容
选择要合并的版本
您可以通过选择要合并的版本来解决合并冲突——要么是您即将合并的内容，要么是之前已有的内容。这允许您在两个更改之间进行选择——要么保留您最近的工作，要么保留原始内容。
如果您正在处理可以通过此方式解决的合并冲突，您可以选择要保留的版本，另一个版本将被删除。
手动编辑
如果您不想在版本之间做出选择，可以通过手动编辑冲突来解决合并冲突。您将能够删除不需要的模块，甚至完全重写它们。一旦您对更改感到满意，就可以继续下一个冲突，直到全部解决。
存档变更请求 操作菜单 
如果您决定不合并变更请求并希望将其从队列中移除，您可以将其存档。 要存档变更请求，先打开它。然后点击变更请求标题旁的，并选择 存档 。您可以通过打开 变更请求 菜单并选择
最后更新于
这有帮助吗？