包含 git 子模块和父存储库的单个目录
a single directory containing git submodule and parent repository
用例：
我们有一个包含 IDE 配置的目录，其中一些应该在一组项目中共享，一些是特定于项目的。这意味着配置目录的某些部分必须与项目共享，而某些部分应该来自集中源。
由于 Project 是一个 git 存储库，我考虑使用 git 子模块来解决这个问题。据我了解，如果我将 config 设为子模块，我必须通过该子模块共享 project specific 1 & project specific 2。另一种方法是制作 shared 1 和 shared 2 单独的子模块。 git book 没有帮助我找到解决方案。
问题：
- 有没有办法让 一个 子模块或其他结构包含
shared1 & shared2 而 project specific 1 & project specific 2 仍然是 Project git 存储库的一部分吗？
- 如果是这样，解决方案是什么样子的？
- 如果不是，是该方法有缺陷（以及如何缺陷）还是我运气不好？
编辑 1：
对的回复：我们讨论的文件不是运行时配置，而是IDE的配置。因此，试图在构建阶段解决这个问题并不方便。
编辑 2：
我按照 的提示使用符号链接。我创建了一个包含 shared1 和 shared2 的子模块 sharedConfig，它被放置在 project 中，然后在 config 中有两个符号链接，它们针对 [= 中的目录22=]。可悲的是，我使用的 IDE 不遵循符号链接而是崩溃了。如果您使用更成熟的工具，这可能是适合您的解决方案。
编辑 3：
在我尝试了所有之后，我同意 ，尽管有 workarounds/hacks 可能适用于某些 platform/tool 组合，但无法按照我的意图进行。
最后，我将每个 shared# 目录作为一个单独的子模块。
我知道子模块无法与父存储库共享目录[1]。
您可以使用多个模块，甚至可以让它们共享相同的物理存储库（通过为每个模块使用不同的分支）；但我认为这很快就会变得不方便。
如果在运行时使用配置文件，那么使用构建过程将文件移动到运行时需要它们的正确位置可能就足够了。这样一来，您的源代码管理工作树结构就不必与上面显示的相匹配，并且可以为如何共享代码 [2] 提供很多选项。您可以使用子模块，或者（IMO 甚至更好）您可以单独打包配置文件（作为 (npm|maven|nuget|whatever's-appropriate-for-your-technology-stack) 工件用作项目的依赖项需要它。
如果在开发时使用配置文件（如果开发工具坚持将它们放在特定位置），那就有点棘手了——但仍然可以通过在结帐后四处移动文件来管理。这可以编写脚本，甚至可以使用挂钩（或者可能是 IDE 或其他开发工具的某些功能）自动执行。在这种情况下，您可能希望父存储库到 .gitignore config/shared* 目录。
[1] 虽然这在您的用例中应该如何工作可能很清楚，但通常它会引入很多问题，而答案充其量只会导致一些违反直觉的行为。 （如果共享目录的父模块和子模块 TREE 对象都有一个相同文件名的条目，会发生什么？如果一个新文件被添加到工作目录，它被添加到哪个 repo（或者你如何指定哪个）？
[2] 与评论中的建议相反，我认为单一存储库是项目共享代码的最糟糕方式之一。造成问题的可能性远大于解决问题的可能性。
用例： 我们有一个包含 IDE 配置的目录，其中一些应该在一组项目中共享，一些是特定于项目的。这意味着配置目录的某些部分必须与项目共享，而某些部分应该来自集中源。
由于 Project 是一个 git 存储库，我考虑使用 git 子模块来解决这个问题。据我了解，如果我将 config 设为子模块，我必须通过该子模块共享 project specific 1 & project specific 2。另一种方法是制作 shared 1 和 shared 2 单独的子模块。 git book 没有帮助我找到解决方案。
问题：
- 有没有办法让 一个 子模块或其他结构包含
shared1&shared2而project specific 1&project specific 2仍然是Projectgit 存储库的一部分吗？ - 如果是这样，解决方案是什么样子的？
- 如果不是，是该方法有缺陷（以及如何缺陷）还是我运气不好？
编辑 1：
对
编辑 2：
我按照 shared1 和 shared2 的子模块 sharedConfig，它被放置在 project 中，然后在 config 中有两个符号链接，它们针对 [= 中的目录22=]。可悲的是，我使用的 IDE 不遵循符号链接而是崩溃了。如果您使用更成熟的工具，这可能是适合您的解决方案。
编辑 3：
在我尝试了所有之后，我同意 shared# 目录作为一个单独的子模块。
我知道子模块无法与父存储库共享目录[1]。
您可以使用多个模块，甚至可以让它们共享相同的物理存储库（通过为每个模块使用不同的分支）；但我认为这很快就会变得不方便。
如果在运行时使用配置文件，那么使用构建过程将文件移动到运行时需要它们的正确位置可能就足够了。这样一来，您的源代码管理工作树结构就不必与上面显示的相匹配，并且可以为如何共享代码 [2] 提供很多选项。您可以使用子模块，或者（IMO 甚至更好）您可以单独打包配置文件（作为 (npm|maven|nuget|whatever's-appropriate-for-your-technology-stack) 工件用作项目的依赖项需要它。
如果在开发时使用配置文件（如果开发工具坚持将它们放在特定位置），那就有点棘手了——但仍然可以通过在结帐后四处移动文件来管理。这可以编写脚本，甚至可以使用挂钩（或者可能是 IDE 或其他开发工具的某些功能）自动执行。在这种情况下，您可能希望父存储库到 .gitignore config/shared* 目录。
[1] 虽然这在您的用例中应该如何工作可能很清楚，但通常它会引入很多问题，而答案充其量只会导致一些违反直觉的行为。 （如果共享目录的父模块和子模块 TREE 对象都有一个相同文件名的条目，会发生什么？如果一个新文件被添加到工作目录，它被添加到哪个 repo（或者你如何指定哪个）？
[2] 与评论中的建议相反，我认为单一存储库是项目共享代码的最糟糕方式之一。造成问题的可能性远大于解决问题的可能性。