跑步时jekyll --server，整个站点被重建。在足够大的站点上，这需要非常长的时间。即使与--auto标志，这应该会阻止整个站点重新生成，但完成时间相当长（对我来说 10 多秒，据报道对某些人来说需要几分钟）。这在编辑和预览单个页面时很不方便。我希望缩短那段时间。
有没有办法确定为什么 Jekyll 需要这么长时间来重建页面？
或者，是否有关于编辑工作流程的建议，允许使用 Jekyll 进行更短的（更）反馈循环？
我无法解决完整站点构建所需的时间，但我想出了一种方法来显着加快起草文档和进行布局更改的速度。所有这些都假设您在本地计算机上进行编辑，然后部署到生产服务器。如果您采用不同的流程，您的里程可能会有所不同。
核心思想是使用多个 jekyll 源目录，每个目录都指向相同的输出位置。就我而言，我使用三个。一份用于起草和编辑帖子（称为“_drafts”），一份用于布局、设计和功能更改（称为“_dev”），最后一份包含整个网站的内容（称为“_main”）。
顶层目录结构如下所示：
./_drafts
./_dev
./_main
./html
每个 jekyll 源的 _config.yml 文件设置如下，将 jekyll 生成的输出指向“html”目录：
destination: ../html
“_drafts”和“_dev”目录包含模仿“_main”站点的设计和功能所需的最小数量的文件。我在这两个目录中完成所有工作，并在正在处理的目录中运行 jekyll。我的本地网络服务器设置为指向本地域（例如http://jekyll-test/）到“html”目录，这样我就可以在进行更改时看到发生了什么。
完成编辑后，我将新更新的文件从“_dev”或“_drafts”复制到“_main”中的相应位置。文件就位后，我会在“_main”中进行最后一次 jekyll 运行。通过这种方法，您只需等待一次漫长的站点生成时间即可将站点部署到生产环境中。我已经使用这种方法有一段时间了，发现它有很大的不同。
还有一些其他方法可以优化工作流程：
-
使用符号链接有助于保持“_drafts”和“_main”的设计和功能同步。
如果您使用的是 Mac 或 Linux 计算机，请设置符号链接以指向./_drafts/_config.yml to ./main/_config.yml and ./_drafts/_layouts to ./main/_layouts（Windows 上可能存在类似的功能，但我无法谈论它）。由于某些原因，jekyll 不能很好地处理某些符号链接的目录。例如，在我的安装中，我有一个根级别的“css”目录，该目录不能用作符号链接。我必须在所有地点都有一份它的实际副本。
-
创建部署脚本。
当我准备好部署时，我不会直接运行 jekyll。我编写了一个小脚本，在“_main”目录中调用 jekyll，将输出同步到我的生产服务器，然后在完成时通知我。这不仅节省了等待 jekyll 的时间，还减少了部署站点所需的步骤数。
-
构建额外的脚本和工具。
从“_dev”和“_drafts”目录复制文件并不是什么大问题，但它是添加一些自动化的主要位置。例如，我有一个命令行脚本，它将“_config.yml”文件以及“_layouts”和“css”目录从“_dev”复制到“_drafts”和“_main”（根据需要）。
待办事项中的另一个工具是本地网络应用程序，它将帖子从“_drafts”移动到“_main”。任何能让文件移动更容易并减少创建和发布摩擦的东西都是好的。
-
使用LiveReload
本地运行，jekyll --auto非常适合在处理文件时自动生成更改。与此自然搭配的是一个名为的应用程序实时重载 http://livereload.com。它会监视您的本地“html”目录，并在内容更改时触发浏览器自动重新加载。这样做的好处是，您可以将浏览器窗口保留在文本编辑器旁边，并在保存文件时看到自动发生的更改。它时不时会有点不稳定，但是用过它之后，你就不会知道没有它你是如何生活的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
