过于复杂的 Git 和大型项目嵌套存储库

发布于 2025-01-12 07:40:26 字数 1331 浏览 3 评论 0原文

我正在开发一个大型项目，其中有许多子组件，所有子组件都相互关联并相互引用。目录结构看起来像这样，每个项目符号都是一个目录，并且给定目录的内容的依赖关系用括号标注。

为了让每个人都在同一页面上，我需要将整个结构成为一个具有以下要求的（超级）存储库。我希望每个子目录都是它自己的存储库，或者至少这样运行 git log 在 ./docs 中运行仅显示与 相关的 git 提交>./docs；目标是让工作更容易划分，以便当我或其他同事在 ./src/fw/base-library 中工作时，我可以输入 git log 和精神上不需要对与./docs/doc-template相关的提交进行排序，并且我不想输入git log ./src/fw/base-library 。或多或少，每个目录都是它自己的存储库，具有自己的子模块/子树依赖项。

至于相互依赖的目录，例如 ./src/sw/driver-linux 依赖于 ./src./sw/driver-shared 和./brd/docs/design-notes 依赖于./docs/doc-template，我打算将它们作为子模块（而不是子树），因为我没有真正需要在其自身之外编辑依赖项代码目录。换句话说，我实际上只需要每个子代表（例如./brd/docs/trade-off_explanation）指向其依赖项的“工作”提交，例如。 /docs/doc-template，但实际上并不包含我可以编辑然后推送到上游的源代码副本，例如./docs/doc-template。

我无法理解 git 是否可以实现我想要的功能。

git clone [super-project]需要从远程克隆整个超级项目结构。应该如何将子存储库（例如./docs/design-notes）集成到超级项目存储库中以实现此目的？它们只是子模块或子树似乎没有意义，因为它们必须指向远程上的“真实”存储库，这将需要复制目录结构以维护超级项目结构，正确吗？
这就是我想要的真正的子存储库和git log（而不是git log ./src/sw/brd-test）甚至可能？
10,000 英尺的视图：我和同事之间的项目文件共享和同步是否过于复杂化了。

原文

I'm working on a large project with many sub-components all related to one another and referencing each other. The directory structure looks something like this, with each bullet being a directory, and dependencies for the contents of a given directory being parenthetically notated.

To keep everybody on the same page, I need this whole structure to be a (super)repo with the following requirements. I would like for each sub-directory to be its own repository, or at least such that running git log run in ./docs shows only the git commits related to ./docs; the goal is to allow work to be more easily compartmentalized so that I can type git log when I or another coworker is working in ./src/fw/base-library and not mentally have to sort through commits related to ./docs/doc-template, and I don't want to type git log ./src/fw/base-library. More or less, each directory is its own repo with its own submodule/subtree dependencies.

As for the directories that are dependent on one another, e.g., ./src/sw/driver-linux being dependent on ./src./sw/driver-shared and ./brd/docs/design-notes being dependent on ./docs/doc-template, I intend for these to be submodules (not subtrees), as I have no real need to edit the dependency code outside of its own directory. In other words, I really only need each sub-rep, e.g., ./brd/docs/trade-off_explanation, to point towards a "working" commit of its dependency, e.g., ./docs/doc-template, but not actually contain a copy of the source code I could edit and then push upstream, e.g., to ./docs/doc-template.

I'm having trouble understanding if what I want is possible with git.

git clone [super-project] needs to clone the entire super-project structure from the remote. How should the sub-repos, e.g., ./docs/design-notes be integrated into the super-project repo to do this? It doesn't seem to make sense that they would be simply submodules or subtrees, as they would have to be pointing to the "real" repos on a remote, which would necessitate duplication of directory structure in order to maintain the super-project structure, correct?
Is what I'm wanting with true sub-repos and git log (instead of something like git log ./src/sw/brd-test) even possible?
The 10,000 ft. view: am I grossly overcomplicating the sharing and syncing of project files among myself and my co-workers.