没有遥控器的嵌套 git 存储库(又名没有遥控器的 git 子模块)
我有一个项目,我有兴趣将其部分内容作为开源进行分解。我已经设置了嵌套的 git 存储库 main、一、二和三:
main/
├── one
├── three
└── two
我认为通过进入“main”并执行
git add one
git add two
git add three
(注意缺少尾部斜杠),我可以使用子存储库设置子模块并且很好去。
但是,正如如何跟踪未跟踪的内容?中所述,这只会创建 gitlinks 而不是真正的子模块。
不幸的是,这个答案没有帮助,因为它假设在“main/one”、“main/two”和“main/two”的某个地方有一个“master”存储库。我希望这些子存储库成为主存储库。我正在考虑伪造子模块(按照 Git fake submodules< /a>),但这对于克隆来说并不是特别理想的情况。
还有其他建议吗?
I have a project of which I am interested in breaking out portions as open-source. I've set up nested git repositories main, one, two and three:
main/
├── one
├── three
└── two
I thought that by going into "main" and doing
git add one
git add two
git add three
(note the lack of trailing slashes), I'd set up submodules with the sub-repositories and be good to go.
However, as noted in How to track untracked content?, this only creates gitlinks and not real submodules.
Unfortunately, that answer doesn't help, as it assumes that there is a "master" repository somewhere else for "main/one", "main/two", and "main/three". I'd like these sub-repo's to be the master repositories. I'm considering fake submodules (as per Git fake submodules), but that's not a particularly ideal situation for cloning.
Any other suggestions out there?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您可以做您想做的事情,但是您的
one
、two
和third
需要可供任何需要克隆它们的人访问 - 这“随机”开发存储库通常情况并非如此。如果您确实进行了此设置,则需要非常小心,不要删除“您的”存储库(或使其无法访问),因为它不仅仅是“您的”:它将是您的来源协作者的克隆,它将充当“中央”/“上游”存储库(如
.gitmodules
中指定)。如果您的所有协作者都是本地的(并且可以从存储库中读取),您可以通过将本地路径作为 URL 来将现有的子存储库添加为子模块:
如果不是所有的协作者都在同一台计算机上工作,那么这可能会无法正常工作(因为它将在 .gitmodules 中存储本地路径;非本地协作者必须在 git submodule init 后调整 URL)。
如果您的
one
、two
和two
可以远程 Git 访问,那么您可以指定它们的有效 URL:在这两种情况下,因为您已经有一个子存储库,
git submodule add
将使用它,而不是尝试从指定的路径/URL 克隆。You can do what you want, but your
one
,two
, andthree
would need to be accessible to whoever will need to clone them—this is not usually the case for “random” development repositories.If you do set this up, you will need to be very careful not to delete “your” repository (or make it otherwise inaccessible) since it is not just “yours”: it will be origin in your collaborator’s clones and it will serve as the “central”/“upstream” repository (as specified in
.gitmodules
).If all your collaborators are local (and can read from the repositories), you can add your existing sub-repositories as submodules by giving their local paths as URLs:
If not all your collaborators will be working on the same machine, then that will probably not work correctly (since it will store a local path in
.gitmodules
; non-local collaborators would have to adjust the URLs aftergit submodule init
).If your
one
,two
, andthree
are remotely Git-accessible, then you can specify their effecive URLs instead:In both cases, since you already have a sub-repository in place,
git submodule add
will use that instead of trying to clone from the specified path/URL.克里斯的答案 不要假设为“
master
”存储库(master
是该存储库的默认名称) Git 中的主分支,而不是存储库)。它在“
parent
”存储库中声明子模块,在您的情况下,该子模块将是“main
”。因此,您需要在其他地方设置三个独立的存储库“
one
”、“two
”和“two
”,然后克隆并将它们作为子模块添加到您的“main
”存储库中:Chris's answer don't assume for a "
master
" repo (master
being the default name of the main branch in Git, not a repo).It declares submodules in a "
parent
" repo, which in your case would be "main
".So you need three independent repo "
one
" "two
" and "three
" setup elsewhere, and then clone and add them to your "main
" repo as submodules:我只是想出了将子模块的存储库放置为超级项目的子目录的想法。这样,整个项目仅依赖于您设置的一个存储库/位置(基于 Chris 的答案)。
例如,子模块
one
会将位置server:/path/to/your/main/one
作为其主存储库(通过git remote -v
在那个目录中)。这样,
submodule
功能(例如git submodule update --recursive
)也会指向正确的位置,因为该模块/存储库的 URL 指向。 /one
(.gitmodules)。I just came up with the idea to place the repository of the submodules exactly as a subdirectory of the superproject. That way, the project as a whole is only dependent on the one repository/ location that you set up (based on the answer from Chris).
E.g. Submodule
one
would have as its main repository the locationserver:/path/to/your/main/one
(viagit remote -v
in that dir).That way the
submodule
functionality (e.g.git submodule update --recursive
) is pointed to the right location as well since the URL of that module/repository points to./one
(.gitmodules).就我而言,我需要指定子模块地址及其应克隆的位置,并且两者都是相同的:
有关我的用例的更多详细信息:
我想开始使用 git 跟踪现有文件夹,并且该文件夹已经包含存储库。我想将所有内容保留在本地:我没有在这些存储库上与任何人合作,并且这些文件夹已经以其他方式保存在云中。
In my case, I needed to specify both the submodule address and the location where it should be cloned, and both were the same:
More detail on my use case:
I wanted to start tracking an existing folder with git, and this folder already contained repos. I wanted to keep everything local: I am not collaborating with anyone on these repos, and the folders are already otherwise saved in the cloud.