GitHub 不只是下载站:从收藏项目到参与开源

前三章，我们分清了Git与GitHub，配好了提交署名，也练习了在本地commit，再通过push把提交推送到GitHub。现在换个位置：你成了别人项目的使用者。

假设你找到一款开源Markdown导出工具。介绍看着不错，想留着以后用；用了几天，希望知道新版什么时候发布；后来发现说明书漏了一步，照着做会导出失败。你想告诉作者，甚至愿意补上那句话。

这几件事，对应的是不同入口：Star、Watch、Fork、Issue、Pull Request。它们不是必须依次完成的闯关任务。先想清楚你要做什么，再选入口。

Star：先收藏，方便再找到

刚看到工具时，你未必马上安装，也不一定准备参与维护。点Star，可以把仓库收进自己的星标列表，以后从个人的Stars页面找回来。它也有表达认可、帮助发现类似项目的作用。

但Star多，不等于工具一定安全、可靠，也不保证适合你的环境。要不要使用，仍要看说明、维护情况和实际表现。点Star也不会自动订阅仓库的全部动态；收藏与通知是两回事。官方说明

在这个情境里，你只是想记住工具，先Star就够了。没必要为了“关注一下”立刻创建仓库副本。

Watch：决定你想听到哪些消息

工具已经用起来，你关心的是“发布新版时告诉我”，这时看Watch。

Watch管理仓库通知。你可以根据菜单提供的选项，选择关注全部活动，或通过Custom选择特定事件。只关心版本发布，可以看看有没有Releases选项，而不是把所有讨论都订阅进来。

这里有个容易误会的细节：Custom中只选Releases，限定的是这个仓库的订阅事件，不是给账号套上“从此只收版本消息”的总开关。你参与了某个讨论、被别人或通过所属团队提及，仍可能收到相关通知；通知通过什么渠道送达，还受个人通知设置影响。通知设置说明／订阅说明

所以，想收藏用Star，想接收动态看Watch。只想用工具，不代表你需要跟进每一场讨论。

Fork：在自己账号下准备一份仓库副本

后来你发现说明书漏了步骤，想亲手修改，又没有原项目的写权限。Fork是常见的准备方式：在GitHub端创建一份保留上游关系的仓库副本。原项目叫上游，你的副本有自己的仓库地址，页面会标明它来自哪里。

Fork不是下载到电脑，也不会授予你修改上游的权限。你在自己的副本里改文档，不会因此直接改掉作者的仓库。要在电脑上处理文件，是另一个层面的操作。

副本也不会因为建立了上游关系，就自动持续跟上原项目。上游有更新后，你仍需按需要执行同步；“来自某项目”不等于“永远与它一致”。Fork说明／同步说明

如果只是想反馈问题，不必先Fork。它适合你准备维护一份副本、试验改动，或通过副本提出贡献时使用。

Issue：把问题说到别人能判断

说明书漏了一步，你暂时不会改，也完全可以提供有价值的反馈。Issue用来跟踪缺陷、改进需求和具体工作，不是只有程序崩溃才能提。

先读README和CONTRIBUTING等贡献说明，再查已有Issue，包括已关闭的记录。项目可能已经解释了限制，或有人报告过同样的问题。按项目给出的模板和渠道反馈，能省下双方来回询问的时间。Issue说明／贡献指南说明

比如，与其只写“导出不能用”，可以写清楚：

• 使用哪个工具版本、什么系统；
• 按文档哪几步操作，输入了什么最小示例；
• 预期出现什么，实际出现什么；
• 怀疑漏了哪一步，有什么不含隐私的报错信息。

假如搜索后发现已有一条相同问题，先读维护者的回复：也许解决办法已经给出，只是还没写进说明书。没有新的复现信息，就不必另开一条催促处理。若确实需要补充，也应提供能帮助判断的新证据。报告问题的价值，在于让别人少花时间还原现场，而不是让列表里多一个编号。

这是示例结构，不是让你编造一次故障。只有真实复现过，才能把它写成事实。暂时不确定原因，就说明“不确定”，不要把猜测写成结论。

如果发现的是可能泄露数据等敏感安全漏洞，先看项目安全策略，走指定的私密报告渠道；项目启用私密漏洞报告时可使用该入口，不要直接把可利用细节发进公开Issue。安全报告说明

Pull Request：把具体改动拿来讨论

你已经弄清缺失步骤，并补好了说明，可以用Pull Request，简称PR，提议把一个分支的改动合并到目标分支。它既能用于代码，也能用于文档纠错。

PR与push不同：push把提交送到远程仓库；PR提出合并建议，让相关人员讨论、审查并决定是否接纳。提交了PR不保证会被合并，审查中也可能要求修改。

PR不一定要先Fork。没有上游写权限时，常见方式是从自己的Fork发起；有写权限的协作者，也可以在同一个仓库的新分支上修改，再提PR。尚未合并的PR不会自动把改动写进上游默认分支。PR说明

Issue和PR可以关联：前者交代问题，后者展示具体改动。符合条件时，PR合并到默认分支可以自动关闭关联Issue。但看到Issue已关闭，不能直接推断代码已经修复并上线；还要看关闭原因、相关改动和版本发布情况。关联规则

本章先认清它们的关系，第七章再展开完整PR贡献操作。

五个入口，按目的选

回到那款工具：想留着，Star；想知道新版，Watch；遇到问题，先查资料与已有Issue；准备改，按权限选择自己的Fork或同仓分支；改好了，再考虑PR。你也可以只停在收藏或阅读这一步。

一次不打扰维护者的小练习

选一个你确实感兴趣的公开仓库，先读README。不同项目的功能设置、归档状态和你的权限，会影响入口是否可见、是否可操作；找不到某个按钮，不必硬找。

1. 试一次Star。 操作后检查是否显示已收藏，并去自己的星标列表找它。不想保留可取消，再检查状态是否恢复。   
2. 检查Watch选项。 如果有Custom和Releases，按需选中Releases并保存，再打开菜单确认选择仍在。没有就跳过。这一步检查的是订阅设置，不要求等来一封通知邮件。 
3. Fork是可选项。 只有确实想保留副本时再做。完成后检查仓库归属是否是自己的账号，以及页面是否标明上游；仅看到电脑里的文件夹，不能证明完成了Fork。公开仓库的Fork也是公开的，不要放秘密进去。   
4. Issue和PR只阅读即可。 找一条已有Issue，看看能否说清它的问题和状态；再读一条PR的描述、改动文件与合并状态，判断它提出了什么修改。不要留言“测试一下”，也不要向真实开源仓库提交练习内容。若想动手创建，留在第三章自己的练习仓库里。

能说清“我想做什么、该用哪个入口、做完后看什么结果”，这一章就达到了目的。下一章再聊：怎样搜索，才能找到值得进一步了解的项目。