有没有一种方法可以发布到项目的 gh-pages 分支， 版本控制在该分支中生成的 css/js？
例如，here是生成的 css 文件 desktop.css 的 gh-pages 分支版本历史。似乎每次更改和提交 scss 文件时，desktop.css 文件也会重新生成并提交。这似乎没有必要存储。
我正在考虑使用 Sass 或 Javascript bundler 等 css 预处理器的项目中的并行。我们通常不会对生成的代码进行版本控制，因为它只是重复我们已有的数据(预编译/预捆绑代码)。例如，如果我们想回到较早的版本，我们将恢复较旧版本的 Sass，并从那里重新生成 css。重新生成早期版本的 gh-pages 页面也是如此，不是吗？此外，这些生成的文件还存在不必要的工件和膨胀到存储库的问题。
是否有一种变通方法可以在版本控制生成的 css/js 的情况下构建代码？我想到的一种可能性是每次我需要重新生成时清除和重新分支 gh-pages 分支，但这似乎很极端。有时我想知道 Github 是否应该提供 gh-pages 作为 标签 以及一个分支，以便我们可以在需要 Travis CI 时移动该标签以指向不同的提交或者你有什么要再生的。
其他人如何解决这个问题？还是这没什么大不了的？
更新于 2014 年 12 月 18 日星期四 19:28:16 EST
David 在下面给出了一个很好的答案，它是特定于 Jekyll 的，展示了一个 jekyll site with just scss但是谁的hosted github page是用生成的 CSS 构建的。看起来魔法就在 _config.yml 文件中。虽然我喜欢这个答案(并赞成它)，但它并没有解决一般情况。
现在我想我会采用定期 git purge 方法。我将部署到 gh-pages 分支，让它对生成的 css/js 进行版本控制。然后每隔一段时间，如果我觉得 repo 变得过于臃肿，我将使用 git filter-branch 命令清空分支，如 explained by Github或者只是在本地和远程删除它并重新创建它。这样，我就可以灵活地使用我想要的任何静态站点生成器，根据需要调整和生成，并保持 repo 大小可管理。以额外几步为代价。
最佳答案
你可以看看Jekyll静态站点生成器 supported by Github page . native 使用 sass 和仅版本源文件。 干净!
关于sass - 在没有版本控制工件的情况下发布到 github 页面？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27553567/