Hugging Face Hub Pull Request 与 Discussion 协作教程

在 Hugging Face Hub 上协作，其实就两件事：要么讨论问题，要么提交改动。无论哪种，都得从仓库的

入口走。但区别在于：纯讨论问题，用 ；有实际文件改动，就开 。选对入口，维护者那边接收到的东西——入口类型、状态标识、审核信息——都会清晰很多，协作效率自然就上去了。

这套规则对模型、数据集和 Space 仓库都通用。日常讨论，确认需求、反馈问题、商量方案，随便聊；但 Pull Request 不一样，它绑定了真实文件改动，页面会额外显示来源引用和

标签。还有个关键点：Hub 的 PR 不需要先 fork 仓库，改动直接保存在来源仓库的自定义 Git 引用里，省去了不少中间环节。

先去 Community 找对入口

打开目标仓库，点仓库导航里的

。页面左侧能看到 和 两个按钮，列表上方还有 、 和 三个筛选选项。下面这张图很清楚地展示了，两个协作入口确实在同一页，而不是散落在仓库设置的某个角落里。

1. 入口：
   目标仓库顶部的 Community。

   操作：
   先浏览现有条目，再用标题筛选框搜搜相近的问题。

   成功标志：
   列表里没有重复议题，左侧两个新建按钮都能看到。

   出错了怎么办：
   如果只看到登录提示，先登录 Hugging Face 账号；如果找不到新建按钮，确认你打开的是具体仓库，不是全站搜索结果页。

2. 入口：
   Community 列表上方的类型筛选。

   操作：
   点

   Pull requests
   ，只查看文件改动类的协作内容。

   成功标志：
   Pull requests 按钮呈选中状态，列表条目都用绿色分支图标标识。

   出错了怎么办：
   如果列表是空的，打开

   View closed
   检查已关闭或已合并的记录，别把旧改动又重新提交一遍。

筛选生效后，页面上还是会保留

和 按钮，右侧的 可以切换查看已结束的记录。碰到“明明有人改过，但列表里找不到”的情况，先去 里找，通常比重开一条要快得多。

开 Discussion 把问题讲明白

没有文件改动的时候，就点

。标题直接写清楚问题或者预期结果，比如“模型卡缺少推理示例”就可以。正文里要补上复现条件、期望结果，还有你已经试过的办法。编辑区支持 Markdown 和 LaTeX，长日志只保留能定位问题的片段就行，别全贴。

1. 入口：
   Community 左侧的 New discussion。

   操作：
   填好明确的标题和可复现的描述后提交。

   成功标志：
   跳转到带编号的详情页，标题下方显示 Discussion 类型，正文下面就是评论区。

   出错了怎么办：
   如果提交按钮点不了，检查账号有没有登录、标题是不是空的；涉及私有仓库的话，还要确认账号有访问权限。

2. 入口：
   Discussion 详情页底部的评论框。

   操作：
   补充测试结果，或者回复维护者的问题。

   成功标志：
   新评论出现在时间线里。

   出错了怎么办：
   如果评论框输不了字，先看看线程是不是已经锁定了；锁定后旧评论还能看，但没法再加新评论了。

普通 Discussion 页面只有讨论线索，不会出现文件差异标签。下面这张图里，标题旁的编号、Discussion 标记和正文区域，就是判断的依据。没登录的时候也能看公开内容，但要回复的话会受登录状态限制。

编辑、置顶、锁定和隐藏评论的权限说明

讨论发起者、仓库作者，或者有写权限的成员，都可以编辑标题。置顶和锁定操作需要仓库写权限。评论作者可以编辑自己发的评论，有写权限的成员也能处理评论；页面会保留所有编辑历史。

隐藏评论之前可得想清楚：这个操作是不可逆的。锁定就不一样了，它不会删掉现有内容，只是不让大家再发新评论。公开协作的时候，最好先发一条说明原因的回复，再锁定线程，这样看的人更容易明白为啥事情就结束了。

用 Pull Request 提交可审阅的改动

已经改了模型卡、数据文件或者 Space 代码的话，就点

。简单改动可以直接在网页上编辑文件后创建 PR；要是需要改多个文件、多次提交，或者得在本地测试，用高级模式或者 Git 工作流更合适。高级模式创建后先是 Draft 状态，确认内容完整再发布为 Open；发布后就没法退回 Draft 了。

1. 入口：
   Community 左侧的 New pull request，或者文件编辑后的创建 PR 选项。

   操作：
   核对目标分支，填好标题和改动说明，再创建。

   成功标志：
   详情页标题下方同时显示 base 目标分支和 from 来源引用，还会出现 Discussion、Files changed 两个标签。

   出错了怎么办：
   如果只能创建 Discussion，说明当前没有可提交的文件改动；如果目标分支不对，别发布，退回创建页重新选择就行。

2. 入口：
   Draft PR 页面。

   操作：
   把提交内容、说明和测试结果都补全后再发布。

   成功标志：
   状态由 Draft 变为 Open，维护者可以按正式 PR 来审阅。

   出错了怎么办：
   发布前发现内容不够就继续保留 Draft；一旦转为 Open，页面不支持恢复 Draft，只能接着改或者关闭。

PR 标题下的

表示目标分支， 表示这条 PR 的来源引用。这个页面也说明 Hub 的 PR 不依赖 fork：改动是通过编号引用保存在来源仓库里的。

在 Files changed 页审完再合并

1. 入口：
   PR 详情页的 Files changed。

   操作：
   按文件逐项检查增删行，确认改动范围和标题说的一致。

   成功标志：
   页面顶部的文件数、绿色新增数和红色删除数都和预期对得上，差异区没有无关文件。

   出错了怎么办：
   发现误删、密钥、缓存或者大文件的时候别合并，回到来源分支修正后再推送，新提交会自动进到同一条 PR 里。

2. 入口：
   PR 的 Discussion 标签。

   操作：
   写清楚具体的审阅意见，说明是哪个文件、哪个位置、期望改成什么样。

   成功标志：
   作者能根据评论继续提交改动，Files changed 会跟着新提交更新。

   出错了怎么办：
   如果只是方向还没确定，先关闭或者保留 Draft，别把讨论性意见直接当成可合并的结论。

3. 入口：
   拥有写权限的维护者操作区。

   操作：
   确认文件差异和讨论都解决了之后再合并；不采用的改动就关闭。

   成功标志：
   PR 进入 merged 或 closed 状态，在 View closed 里能查到。

   出错了怎么办：
   看不到按钮通常是因为没有写权限，得由仓库维护者完成最终操作。

Files changed 页面会把每个文件的差异直接列出来。绿色代表新增，红色代表删除，顶部的统计数能很快发现“只想改一行，却带进了整份文件”这类问题。

需要在本地检查 PR 时怎么办

PR 引用可以按编号获取。比如编号是 42 的话，对应的引用就是 refs/pr/42。本地检查的时候，把这个远程引用抓到一个临时分支里，再运行仓库自己的测试就行。确认没问题了，再回到网页完成讨论或者合并。

关闭或合并后的 PR 引用可以删除来释放存储空间，但这个操作是不可逆的。只有确认再也不需要从该引用恢复提交的时候再删；如果只是暂时不合并，保留关闭状态更稳妥。

完成一次协作前的核对清单

• 只是讨论问题就用 Discussion，有真实文件改动就用 Pull Request。
• 新建前查过 All、类型筛选和 View closed，没有重复条目。
• 标题能说明对象和结果，正文包含复现条件、改动范围或测试结果。
• PR 的目标分支和来源引用正确，Files changed 里没有无关文件或敏感内容。
• 每条审阅意见都指出了具体位置和预期改法，合并前已解决关键讨论。
• 锁定、隐藏评论和删除 PR 引用前，已经确认过权限和不可逆影响。