git checkout --orphan 创建的分支不是空目录，因为它保留当前工作目录全部文件（含已跟踪和未跟踪），仅切断提交历史；需手动执行 git rm -rf . 清空已跟踪文件，否则首次提交仍含旧代码。
git checkout --orphan 创建的分支为什么不是“空目录”
执行 git checkout --orphan new-branch 后，工作目录里的文件**不会被自动清空**——它会保留当前分支的全部文件状态（包括已跟踪和未跟踪的），只是切断了提交历史。这常让人误以为“新建空白分支就该是空的”，结果一提交，发现新分支里全是旧代码。
真正想建一个干净起点，必须手动清理：
-
git rm -rf .删除所有已跟踪文件（注意末尾的.） - 未跟踪文件（如
node_modules、dist/）不会被删，需单独处理或确认是否需要保留 - 删完后记得
touch README.md或其他初始文件，否则git add .会失败（没东西可加）
gh-pages 分支必须用孤儿分支吗
是的，GitHub Pages 的 gh-pages 分支默认要求**无历史关联**，否则部署时可能混入开发历史、泄露敏感信息或触发不必要的构建。官方文档虽未强制，但实践表明：用 git checkout --orphan gh-pages 是最稳妥的方式。
常见错误场景：
GitHub 智能代码审查与 CI/CD 自动化
下载
GitHub 智能代码审查与 CI/CD 自动化工作流。收到 PR 或代码提交时，自动进行 AI 代码审查（bug/安全/逻辑），并根据审查结果智能生成或推荐 GitHub Actions 工作流。触发词：代码审查、review PR、生成 CI/CD、GitHub Actions。
- 直接
git branch gh-pages && git checkout gh-pages→ 新分支继承全部历史，Pages 构建时可能拉取错误版本 - 忘记
git rm -rf .→ 页面文件和源码混在一起，CI/CD 容易出错 - 首次提交没加
.nojekyll或index.html→ GitHub Pages 控制台报 “404 No site found”
孤儿分支推送到远程后为什么看不到提交记录
因为孤儿分支的首次提交没有父节点，git log 默认只显示从当前 HEAD 往前追溯的链路——而这条链在孤儿分支里只有 1 个孤立节点。所以 git log 只输出一条，git log --all 才能看到它。
更关键的是推送行为：
-
git push origin new-branch能成功，但远程仓库页面可能仍显示 “No commits” —— 这通常是因为你没完成首次提交（git commit缺失） - 如果本地
git branch -v不显示新分支，说明还没 commit；Git 要求分支必须指向一个有效 commit 才算“存在” - 用
git show-branch --all可验证孤儿分支是否真的独立：它不该出现在其他分支的历史路径中
文档仓库（如 Wiki）用孤儿分支管理的陷阱
很多团队把文档放在 docs 或 wiki 孤儿分支里，方便与主代码解耦。但容易忽略两个硬性约束：
- GitHub/GitLab 的 Wiki 功能**不依赖孤儿分支**，而是读取
<repo>.wiki专用仓库或wikiMain分支 —— 自建孤儿分支做文档，得自己搭 CI 渲染，别指望平台自动识别 - 文件名含特殊字符（如
#、/、开头/结尾的.）会导致渲染失败，尤其 Markdown 页面标题转文件名时，How to contribute?→How-to-contribute?.md是非法的 - 孤儿分支里放大量图片或附件？Git 本身不优化大文件，
git clone会变慢；建议用git-lfs单独 track，且 LFS 配置必须在孤儿分支首次提交前启用
真正要小心的，不是怎么建分支，而是建完之后有没有人记得它不继承历史——一旦有人 git merge 错分支，整个“孤立性”就崩了。
