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分支开 PRPR 标题会直接成为项目 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 替你触发 CIcargo fmt和cargo clippy必须在 CI 中通过才能合并所以推送前就应在本地先跑确认。CI 判定你的目标是名为 Editor: Dev CI / build (pull_request) 的 check 显示 ✅。如果显示 ❌需要去排查需要构建日志时请 maintainer 提供。偶尔其他 check 失败通常不由你负责修复可以忽略。如果你的 PR 来自 forkCI 运行要等 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 两部分按流程推进即可。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考