为什么在我已经运行过 git init 的文件夹的子文件夹中执行 git init 是个坏主意答案

【问题标题】：Why is it a bad idea to git init in a subfolder of a folder in which I have already run git init为什么在我已经运行过 git init 的文件夹的子文件夹中执行 git init 是个坏主意
【发布时间】：2016-05-14 07:52:00
【问题描述】：

on softwarecarpentry他们说输入以下命令序列是个坏主意：

cd             # return to home directory
mkdir planets  # make a new directory planets
cd planets     # go into planets
git init       # make the planets directory a Git repository
mkdir moons    # make a sub-directory planets/moons
cd moons       # go into planets/moons
git init       # make the moons sub-directory a Git

为什么这是一个坏主意。

【问题讨论】：

“为什么这样做是个坏主意？” - 你应该弄清楚。为什么不尝试并找出答案？旁注：如果您想在另一个 repo 中使用 repo，请查找 "git submodules"

标签： git version-control

【解决方案1】：

因为你会创建一个 git 嵌套的 repo，它

将被父回购记录为gitlink (special entry in the index)
但其内容会被忽略

相对于 submodule（它还记录了一个 gitlink，和父 .gitmodules 文件中的子模块 url），一个带有嵌套 git 的 repo其中的 repo 将无法取回嵌套的 repo 内容：所有父级在其索引的条目中都有一个 SHA1。它没有嵌套存储库的 url。
任何克隆父存储库的人都会为嵌套的 git 存储库获得一个“空文件夹”，而无法找到该“空文件夹”用于哪个其他存储库。
您可以在“Visual Studio 2015 Community: Commit to GitHub via command line produces inaccessible file…?”中看到此类文件夹的具体示例

【讨论】：