#提交文章

由 GPT 5.3 翻译自 CONTRIBUTING.md

#管理结构

本项目采用扁平化的组织结构，仅设两种角色：审核者（管理员）和作者（用户）。
审核者由内部作者团队轮流担任。除此之外，外部贡献者与内部作者之间没有区别。

#轮值审核员

审核者将在作者团队中轮流担任。

审核者的职责包括：

• 执行写作规范
• 进行事实核查
• 解决合并请求中的冲突
• 审批合并请求

#参与贡献

只需克隆本仓库，通过拉取最新变更保持同步，然后提交包含你文章的合并请求。若满足以下条件，审核者将会审核并合并你的文章：

• 符合我们的质量标准
• 所有冲突均已解决

#Git 规范

我们不希望对贡献者强制要求掌握任何 git 知识。然而，为了保证编辑历史的可追溯性和透明性，我们仍然需要对提交（commit）施加一些规范。

如果你不熟悉 git，不用担心。我们的在线编辑器使用 Git 和 Pull Request 作为后端，但大多数技术细节对贡献者是隐藏的，因此只需按照网站指引操作，就可以轻松满足大部分规范。如果你熟悉 git 并在本地编辑器中写作，建议阅读以下规范，以确保你的 PR 能顺利合并。

审核者也应阅读这些规范，并在审核 PR 时加以执行。

#清晰的提交标题和描述

提交信息应清晰且具有描述性。像 Update 这样的信息是不可接受的。一个好的提交信息应简洁，同时足够清楚，使人无需查看 diff 就能理解你的改动。

在适用的情况下，应遵循 scope: subject 的格式，例如：entity ai: add code walkthrough for the pathfinding algorithm。标题尽量不要超过 72 个字符，必要时可以在正文中补充详细描述。

#合并方式

为了在 main 分支上保持严格的线性历史，所有分支应通过 squash merge 合并，或在极少数情况下使用 rebase merge。以下情况可以考虑使用 rebase merge：

• 你的分支包含较长且有价值的提交历史，不希望在 squash 时丢失
• 分支中的大多数提交本身结构良好且具有明确意义
• 分支包含大量修改，难以合理压缩为单个提交

严格禁止使用 merge commit。不要在你自己的 fork 中创建任何此类提交。有关如何避免创建 merge commit 的说明，请参见 Preventing Merge Commits。如果 PR 中包含 merge commit，我们将对其进行修改以移除这些提交。