GitHub发布的两类文件：另附二进制与自动仓库压缩包

一个GitHub发布页可以同时提供几个下载文件。它们虽然归在同一次release下，来源却未必一样：有的文件由发布者另行附加，有的压缩包由GitHub按仓库内容自动提供。理解这层区别，才能知道下载说明实际上承诺了什么，而不是把每一个链接都读成同一种安装包。

GitHub的About releases说明，release基于Git标签，标签标记仓库历史中的特定位置。标签日期和release日期可以不同，因为两者可以在不同时间创建。[1] 因此，发布日期与所指仓库位置各自提供一项信息。某个日期较新，不表示标签所对应的内容也在同一天重新形成；本篇没有检查任何实际项目的版本记录。

另附文件是发布资料中的一类交付对象。官方管理文档明确提到，可以在release中加入编译程序等二进制文件。[2] 这是可选的附加内容，不是看到release存在，就能推定每个项目必定上传了编译程序。文件叫什么、适用于什么环境，还需要那次发布自己的说明，文档并没有替所有项目给出同一个答案。

自动压缩包则有另一条来源链。GitHub会自动提供zip和tarball下载链接，包含标签创建时点的仓库内容。[1] 这里应保留“仓库内容”这项定义：它没有被说明成GitHub替项目自动完成编译的结果。若只把它简称为安装包，就省略了从仓库内容到可安装程序之间尚未由这段资料证明的部分。本文没有下载、解压或运行任何文件。

日期也不宜压成一栏。官方说明，release详情会在各个asset旁显示其创建日期。[1] 这与标签日期、release日期共同提醒读者，不同时间字段可能属于不同对象。整理下载清单时，可以对应记录文件身份、它是另附内容还是自动仓库压缩包，以及实际页面给出的日期字段。这样的记录用于解释出处，不是判定某个文件更新、更可信或更适合安装。

还有一个不能省略的范围条件：管理员可以选择GitHub生成的zip与tarball是否包含Git LFS对象。[1] 因此，自动压缩包的存在没有单独证明全部LFS内容都在其中。这里仅保留这一条件，不展开备份方案或修改设置，也不从某一设置名称推断实际项目当前采用了什么状态。

两类文件最终服务的是不同的阅读问题：另附二进制需要理解发布者提供了哪项交付物，自动压缩包需要理解它对应哪一份仓库内容。把链接放在同一个release下，便于集中交付，却没有抹去各自的来源。本篇限定于已读GitHub.com文档，无明确首发日期；不提供发布操作、权限更改、安装兼容或软件安全保证。