从 CDN 而非您自己的服务器提供 javascript 库具有巨大的优势。您的服务器的工作较少，CDN 的副本可能比您的服务器更靠近用户，但最重要的是，您的用户浏览器已经从该 URL 缓存了它的好机会。最后一个意味着每个人的总工作量减少，所以这显然是一场胜利，而且我们（开发人员）越频繁地依赖 CDN 为我们的 javascript 提供服务，就越有可能。
但流行的 javascript CDN（谷歌、微软、其他？）只托管少量文件。对于其他人，我们可以选择自己托管它们，或者……使用源代码控制服务器作为一种 CDN。Github 或类似的东西不太可能有一个地理分布的文件缓存，为全球服务而优化。但是如果这是常见的做法，那么用户的浏览器很有可能会缓存它。将工作从我们的服务器卸载到 github 的论点只有在 Github 自愿自愿这样做时才有效。
那么，这是普遍做法吗？我们应该互相鼓励这样做吗？Github 介意吗？他们有明确的官方政策吗？
如果您关心性能或 IE9 兼容性，则不应对 JavaScript 文件执行此操作。
GitHub 不提供带有远期到期标题的“原始”文件。如果没有跨站点缓存的可能性，您将失去使用公共 CDN 来托管您的 JavaScript 的最大好处。事实上，使用 GitHub 作为 CDN 会比在每个用户第一次请求文件后简单地将文件托管在您自己的服务器上要慢（假设您在服务器上正确配置了缓存）。
另一个问题是 GitHub 不提供具有与文件的实际 MIME 类型匹配的内容类型标头的“原始”文件。在 IE9（可能还有其他浏览器/代理/防火墙/等）中，默认情况下会阻止未提供正确内容类型的 JavaScript 文件。您可以在 BlockUI 演示页面上看到它的实际效果，例如：
如Dave Ward 的回答所述，链接到 GitHub“原始”文件存在一些问题。
我建议您将 GitHub Pages 作为一种选择。
阅读这篇文章：
GitHub 作为 CDN。使用 GitHub Pages 缓存您的 Javascript、样式表和 Web 资产。
最近在github的支持论坛上问到这个问题，官方的回答是可以。
话虽如此，我同意其他答案：GitHub上从来没有真正的意思是一个CDN，而谷歌和微软都为特定的基础设施。
我已经做了几个月了，首先有一些担忧，但是如果您的文件公开可用没有问题，那就太酷了，如果您关心，请使用缩小版本。
但仍然 - Google 和 MS 统治着 jQuery 和 jQuery 模板的空间 - 所以我使用它们。