Git 用于协作的子模块或子树

TLDR：我不确定是否应该使用

子树

或

子模块

，以及如何设置/使用适当的解决方案

当前工作流 我有一个私人存储库

a

，其中有我研究的几个子目录（例如

a

），只有我可以访问。基于其中的一些工作，我希望在“第二个”存储库中提供这项工作的子集（包含在子目录

b

）供第二位作者编辑。理想情况下，第二个存储库应该像普通存储库（主分支、github页面等）一样呈现给其他作者

编辑

b

的我的合作者应该不能访问或查看

b

之外的任何内容。因此，如果我在

a

下的一次提交中同时提交了

a

，我就厌倦了在

a

登录的

b

中意外地发生更改（请参阅下面几段关于提交更改的关注点）

子目录应该是协作的第二个存储库 如果我在

a

或

b

中进行了更改，那么我认为这应该在

a

git日志中进行跟踪。但是，如果我只在

a

中进行更改，则不应在

b

的git日志中跟踪。如果合作者应该在

b

中进行更改，那么我应该能够提取这些更改

如果我在

a

下的一次提交中对

a

和

b

都做了一些更改，那么我有点不确定应该如何最好地处理这一点，并愿意接受建议/评论。就我的情况而言，我认为最好将它们分成两个单独的提交，因为

b

在

A

中是独立的，并且与

A

无关。如果这需要我在犯下罪行时格外警惕，那么就这样吧，尽管如果这是一个常见的陷阱，而这是一个需要解开的噩梦，那么请给出建议

子树还是子模块？ 基于一点阅读（例如），我正在努力区分子树和子模块，两者似乎都合适。我还不够精通，甚至无法区分这些问题和他们正在解决的问题之间的区别

相关问题 我认为以下问题是相关的，但我不认为它们完全符合我的情况：

目前我认为

子树

可能是最合适的，但我仍然不确定（参见）

A       # Main git repo
├── a   # My private work
└── b   # Work I would like a collaborator to contribute to.