首先明确说：完全不会有影响，Git的工作逻辑就是从当前所在目录向上遍历，直到找到第一个.git文件夹（也就是仓库根目录）就立刻停止，不会继续往上找上层的仓库配置。

这里的关键是：你要确保~/MyProject/build/doc/html/是一个独立的Git仓库——要么是直接把你的MyProject.github.io远程仓库克隆到这个目录，要么是在这里执行git init然后关联到GitHub的远程仓库。只要它是独立仓库，Git在这个目录下的所有操作（拉取、推送等）都只会用这个子目录里的.git配置，和上层~/MyProject/的主仓库完全无关。

反过来，如果这个html目录只是主仓库的一部分（没有自己的.git文件夹），那你在这里执行推送操作其实还是在操作主仓库，这肯定不是你想要的结果，所以一定要先把它变成独立仓库。

首先，嵌套Git是完全可行的——Git允许在一个仓库的子目录里创建另一个独立仓库，主仓库默认会忽略子目录里的.git文件夹，所以不会把文档仓库的内容提交到主仓库里，刚好符合你“开发物料存在BitBucket主仓库，文档单独托管到GitHub Pages”的需求。

至于submodules是否适合你的场景，分两种情况看：

• 如果你希望在主仓库里追踪文档仓库的版本（比如记录当前发布的文档对应文档仓库的哪个commit），那submodules是个不错的选择。你可以把GitHub Pages仓库作为主仓库的一个submodule，挂载到~/MyProject/build/doc/html/位置。这样在主仓库里会保留一个submodule的引用，克隆主仓库时可以选择是否同步拉取文档仓库的内容，方便你关联代码版本和文档版本。
• 如果你完全不需要主仓库和文档仓库有任何版本关联，只是想在主仓库的子目录里单独维护文档仓库，那其实没必要用submodules，直接在该子目录初始化独立仓库就行，操作更简单，也更少额外的配置麻烦。

最后给个小提醒：可以在主仓库的.gitignore文件里加上/build/doc/html/，避免误把文档仓库里的内容提交到BitBucket的主仓库里，进一步隔离两个仓库的操作。

内容的提问来源于stack exchange，提问作者katang