Github Action：2 用github Action把源码仓库部署项目到github Page仓库的真正意义

(00:09-00:32) 1.2: 手动部署痛点与自动化优势

• ♈指出传统方式下，每次修改完文件后，都需要手动将生成的 public 文件夹上传到服务器或托管平台，这个过程比较麻烦。
• ♈使用 GitHub Actions 可以实现自动化：自动帮我们生成 public 目录，并将其部署到静态页面网站（如 GitHub Pages）。
• ♈优点：只需提交代码 (git push)，后续的构建和部署过程就能自动完成，方便很多。x x <-https://aistudio.google.com/prompts/1dv1SBgRsYgFBSgYe1Dseg0dyYouTZ3_P 《《《♐可以源码仓库和静态资源仓库分开；因为源码仓库很重要，每次项目回溯时回溯源码仓库的代码才有意义，回溯静态资源仓库的代码没意义，这意味着未来版本控制就必须要push推送源码仓库，♓但要推送源码仓库就意味着每次推送都要同时push推送源码仓库和静态资源仓库，手动维护两个独立的 Git，需再手动进行第二次推送 流程退冗余了；♐而有了action部署静态资源后，每次只需要推送最重要的源码仓库，无需做冗余的推送静态资源仓库的步骤，无需再手动进行第二次推送> 《♓我觉得最主要作用是源码静态资源仓库和源代码仓库分开；♐其实不要action也行，不要action就不去推送源代码仓库了，在本地只推送public静态资源即可，反正都是推送步骤不会减少 《《♐用action把部署静态资源到github page的真正价值：多人协作，多人协作时，需要所有人都遵循同样的流程，但很是有人知道我们要推送的是public静态资源，不是源码，这就导致源码把静态资源给污染了（目录混入源代码仓库会极大地污染 Git 历史）》 <设置好 Action 后，你甚至可以通过 GitHub 网页界面直接编辑 Markdown 文件并提交，Action 照样能完成部署，你此时甚至不需要本地安装 Hugo；因此未来你更换了本地开发机器，构建环境都是一致的，每次 Action 运行时，都是用同一个版本、同一种配置的 Hugo 工具在同一种操作系统环境下进行构建，结果更可控>