MkDocs项目中关于保留.github文件夹的技术探讨

在MkDocs项目的使用过程中，用户经常需要将文档部署到GitHub Pages。标准的gh-deploy命令虽然方便，但在某些特定场景下会带来一些限制，特别是当用户需要在部署后继续使用GitHub Actions进行持续集成时。

问题背景

MkDocs提供的gh-deploy命令是一个便捷的部署工具，它会自动完成以下操作：

1. 构建静态网站
2. 将构建结果提交到gh-pages分支
3. 推送到远程仓库

然而，这个命令在部署时会清空目标分支的所有内容，包括可能存在的.github文件夹及其中的工作流文件。这对于需要在文档部署后执行额外CI/CD操作的用户来说，会造成工作流中断的问题。

技术解决方案

针对这一需求，MkDocs官方建议采用更灵活的手动部署方式，而非依赖gh-deploy命令。以下是几种可行的技术方案：

1. 手动Git操作部署

用户可以通过编写自定义脚本，精确控制部署过程：

mkdocs build
git checkout gh-pages
# 保留必要的文件
git add .
git commit -m "Deploy docs"
git push

这种方式允许用户在部署时保留.github文件夹或其他必要文件。

2. 子目录部署方案

另一种方案是修改部署结构，将文档站点部署到子目录而非仓库根目录：

mkdocs build --site-dir docs-site
cd docs-site
# 初始化git仓库并推送到gh-pages分支

这样可以在根目录保留CI/CD配置文件，同时将文档内容部署到特定子目录。

3. 构建后处理脚本

用户可以在构建完成后添加处理步骤：

mkdocs build
# 复制.github文件夹到构建目录
cp -r .github site/
# 然后进行部署

技术考量

MkDocs团队不建议修改gh-deploy命令来特殊处理.github文件夹，主要基于以下技术考虑：

1. 单一职责原则：gh-deploy命令应保持简单和专注，不应承担过多特殊逻辑
2. 灵活性：手动部署方案提供了更大的控制空间，可以适应各种定制需求
3. 可维护性：避免在核心命令中添加过多特殊用例，保持代码简洁

最佳实践建议

对于需要在文档部署后执行CI/CD操作的用户，推荐采用以下工作流：

1. 使用mkdocs build命令构建文档
2. 通过自定义脚本或Git命令精确控制部署过程
3. 在部署完成后触发后续的CI/CD流程
4. 考虑将文档部署到子目录以保持仓库结构的清晰

这种方案虽然需要更多的手动配置，但提供了完全的灵活性和控制力，能够满足各种复杂的部署需求。