Graphite 提交首个 PR 前要遵循哪些分支命名、PR 描述与 AI 披露规则？-迪斯科星球

Graphite 提交首个 PR 前要遵循哪些分支命名、PR 描述与 AI 披露规则？

【免费下载链接】GraphiteCommunity-built comprehensive 2D content creation appplication for graphic design, digital art, and interactive real-time motion graphics powered by a node-based procedural graphics engine项目地址: https://gitcode.com/GitHub_Trending/gr/Graphite

准备给 Graphite 提交第一个 PR 时，最容易出问题的三处是分支命名、PR 描述格式和 AI 工具披露。贡献指南对这三点都有明确且具体的规定：分支名用 kebab-case 且不带feature/、fix/前缀，且绝不能从master分支开 PR；PR 标题会直接成为项目 Git 历史中该功能的 commit message，需要句子大小写加祈使语气；任何未披露的 AI 生成内容都是零容忍违规，披露要提前写好并作为 PR diff 上的自审评论提交。以下内容按"领任务 → 分支命名 → PR 描述 → AI 披露 → 打开 PR 后的验证"的顺序整理，全部来自提交贡献指南与 AI 贡献政策。

适用前提：文档假设你已经会用 Git 的 commit、branch 和多个 remote，并且已按贡献者指南加入 Discord、认领了任务。

从哪里领任务

文档指出有两个地方可以找到适合新手的开发任务：

Discord 的#✅code-todo-list频道中、带 ‼️ 表情反应的小颗粒度任务描述，通常比 GitHub issue 更容易上手；
GitHub 任务板上标记为 beginner 的 issue 列表。

不确定选哪个任务时，可以去#📄development频道提问。注意：如果做的是 GitHub issue 任务，提交 PR 后要在该 issue 里评论并附上 PR 链接（原因见文末"与 issue 的关联"一节）。

开始编码前，先切到master分支执行git pull，从master的最新 commit 出发：

git checkout master git pull

分支命名规则

在写下第一个 commit 之前，先创建一个描述分支用途的新分支。文档给出的约定：

名字要短但足够具体地描述内容；
kebab-case（单词之间用连字符）是通常约定；
不要加feature/或fix/这类前缀，文档认为这只是视觉噪音；
文档给出的示例是fix-path-tool-selection-history，并评价它"合格，但几乎太长了"。

有一条硬性警告：不要用名为master的分支开 PR，这会显著加大 code review 的难度。如果你已经错误地在master上提交了代码，就新建一个正确命名的分支（带上这些提交），从新分支开 PR。

另外两个事实：推送到 GitHub 并开好 PR 之后，分支名就不能再改了；但文档明确说不要因为名字不够理想就关掉 PR 重开，把经验留到下一次即可。

PR 标题与描述怎么填

标题：你的 PR 标题会成为该功能在master上的 commit message。要求简明但描述性地概括 PR 做了什么，使用句子大小写（sentence case）和祈使语气。文档给的三个格式示例是 "Fix X bug"、"Add Y feature"、"Make Z faster"。

描述按任务来源分三种情况：

任务来自 Discord 的#✅code-todo-list：右键那条任务消息，选择 "Copy Message Link"，把消息链接粘贴进 PR 描述；
任务对应一个 GitHub issue：描述中必须包含 issue 编号，且 GitHub 要求的触发词格式是 "Closes #123"、"Fixes #123" 或 "Resolves #123"（#123是文档示意用的 issue 编号，替换为你的实际编号）。有多个 issue 时，每个都要完整重复一次触发词；没有对应 issue 时，删掉 PR 表单里预填的 "Closes #" 文本；
对应的是 tracking issue：触发词会在合并时自动关闭 issue，这对 tracking issue 不合适，应改用 "Part of #123"（它不是触发词，不会关闭 issue）。PR 合并后再回来把描述里的 "Part of" 改成 "Closes"，这样 tracking issue 能链接到 PR 而不会被关闭。

可选项（文档称为 bonus）：花几分钟写清楚你改了什么，并附上相关截图或视频片段，对 maintainer 有帮助。另外，如果你对某个实现方式有疑虑，或某段代码不够干净，可以在打开 PR 后从 "Files changed" 标签页对自己代码的行留评论说明。

AI 工具使用与披露规则

只要你在开发流程中使用了任何形态的 AI 工具，提交 PR 前必须先阅读并遵守 AI 贡献政策。政策把用法分成三类：

允许且无需披露：非 agent 类 AI 工具可以辅助调试，以及对你本来就会自己写的单行代码做 tab 补全。

允许但必须披露：AI 聊天工具（不是 agent）可以帮你生成小的代码片段（40 行以下），前提是你手动复制粘贴，并逐行仔细审查，确认与你本人写法一致。

严格禁止：AI slop、"vibe-coded" 或由 agent 编写的 PR 被明令禁止，可能被当作针对项目的恶意 spam 攻击处理，结果是封禁。PR 描述文本和回复 reviewer 的内容必须由你本人写，不能用 AI——文档说英语不完美也没关系，比 AI 生成的文字好。

披露的具体要求：

Graphite 对未披露的 AI 生成内容零容忍；
每一行你没有亲自动手写出的内容，都必须伴随一份详细的、人写的说明，论证每一行为什么正确且合适；
这些说明要提前准备好，在 PR 刚打开或推送新代码之后，立即作为 self-review 评论写在 GitHub PR 的 diff 上。

补充一点来自 code review 礼仪的关联警告：如果你的代码完全没有实现任务或破坏了周边功能，这种明显错误严重时也可能被解读为 AI 生成 spam，同样按 AI 贡献政策处理。所以提交前真正理解并测试自己的改动是硬要求。

打开 PR 后、标记 Ready 之前：自审与 CI 验证

打开 PR 时有一个默认动作：除非代码当前已经 ready for review，否则应标记为 draft（新建 PR 时选 "Create draft pull request"，已开的 PR 可用 "Convert to draft" 转换）。当你确信代码实现了所需功能、不引入新 bug 或坏掉的功能时，再标记为 ready 并 ping 一位 maintainer。

标记 ready 之前做两件事：

自审：通读所有改动的 diff，确认正确、完整，且没有无谓的空白改动、遗留调试代码或注释掉的行。AI 生成代码行的披露（如适用）也发生在这个环节。

本地跑通 CI 会检查的命令：

cargo test --all-features cargo fmt cargo clippy

文档说明：如果你不确定 CI 是否通过，就在本机运行cargo test --all-features，或请 maintainer 替你触发 CI；cargo fmt和cargo clippy必须在 CI 中通过才能合并，所以推送前就应在本地先跑确认。

CI 判定：你的目标是名为 "Editor: Dev & CI / build (pull_request)" 的 check 显示 ✅。如果显示 ❌，需要去排查；需要构建日志时请 maintainer 提供。偶尔其他 check 失败通常不由你负责修复，可以忽略。如果你的 PR 来自 fork，CI 运行要等 maintainer 批准后才执行。

与 issue 的关联：合并前后各一步

对 PR 中引用的每个 issue（包括 tracking issue），你需要在该 issue 里留一条评论，内容不限，例如 "I opened PR #456"。原因是项目方会在 PR 合并后把 issue 指派给你，而 GitHub 只允许指派给评论过该 issue 的人，这样合并的 issue 才有署名，也保持已关闭 issue 的组织一致性。
前面提到的 tracking issue 特殊处理在合并后完成：把描述里的 "Part of #123" 改为 "Closes #123"。

PR 合并时，你的所有 commit 会被 squash 成master分支上的单个新 commit，保持历史线性易读。之后可以在 Discord 的#📄development频道发帖申请"Code Contributor"角色。

如果等待评审期间master前进了，合并前你的分支需要与之同步；无冲突时可用 PR 页面的 "Update branch"（下拉里可选 rebase），有冲突时则需要你自行解决冲突并推送更新后的代码。评审阶段本身分为 QA（维护者测试你的构建）和 code review 两部分，按流程推进即可。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析