Git 存储库中的 Git 存储库

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/5980960/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-10 10:53:54  来源:igfitidea点击:

Git repository in a Git repository

git

提问by MP0

I have a Git repository including a Git repository.

我有一个 Git 存储库,包括一个 Git 存储库。

repo1/
     .git/
     files
     repo2/
          .git/
          files
     files

Is it possible to work with this architecture?

是否可以使用这种架构?

采纳答案by VonC

You can have nested git repos:
The parent repo will simply ignore nested repo.

您可以嵌套 git 存储库:
父存储库将简单地忽略嵌套回购.

jleedevcomments and illustrates with this gist scriptthat the parent repo would track the nested repo state through a gitlink.
(gitlink = SHA-1 of the object refering to a commit in another repository. Git links can only be specified by SHA or through a commit mark.
A gitlink has a special mode '160000', used for submodules, but also present for simple nested repos).

jleedev的意见,并与这说明要点脚本父回购将通过跟踪嵌套回购州一个gitlink
(gitlink = 对象的 SHA-1 引用另一个存储库中的提交
。Git链接只能由 SHA 或通过提交标记指定。gitlink 具有特殊模式 ' 160000',用于子模块,但也用于简单嵌套回购)。

However, usual commands would not acknowledge the nested repo: addor commitwould apply only in one repo, not the other.

但是,通常的命令不会确认嵌套的 repo:add或者commit仅适用于一个 repo,而不适用于另一个。

git submodulewould allow to reference the nested repo from the parent repo, and keep an exact reference of the child repo.

git submodule将允许从父存储库引用嵌套存储库,并保留子存储库的精确引用。

Another alternative could involve:

另一种选择可能涉及:

  • two separate Git repos (not nested)
  • a symlink from one to a specific part of the other (both Unix, but also Windows Vista+ have symlinks)
  • 两个单独的 Git 存储库(非嵌套)
  • 从一个到另一个特定部分的符号链接(Unix 和 Windows Vista+ 都有符号链接)

回答by Artusamak

You are trying to accomplish something called a "submodule".

您正在尝试完成称为“子模块”的事情。

Please check out Git Tools - Submodulesto find out how it's working.

请查看Git 工具 - 子模块以了解它是如何工作的。

回答by Bob Ray

I've used that structure for quite a while, with the sub-repo directories specified in .gitignore in the outer repo.

我使用这种结构已经有一段时间了,在外部存储库的 .gitignore 中指定了子存储库目录。

It confuses the git tool in my editor (PhpStorm), which always wants to commit to the outer repo, but otherwise works fine. I load the whole outer repo (which includes all innner repos) as a single project in the editor. That allows me to easily search for and examine code in the outer repo while working on an inner one.

它混淆了我的编辑器 (PhpStorm) 中的 git 工具,它总是想要提交到外部存储库,但其他方面工作正常。我将整个外部存储库(包括所有内部存储库)作为单个项目加载到编辑器中。这使我可以在处理内部存储库的同时轻松搜索和检查外部存储库中的代码。

I do all Git operations from Git bash in whatever repo I'm working on.

我在我正在处理的任何存储库中从 Git bash 执行所有 Git 操作。

Submodules might be a better approach. I haven't had time to investigate whether they would work better with PhpStorm.

子模块可能是更好的方法。我还没有时间研究它们是否会与 PhpStorm 一起工作得更好。

回答by mattHymanets

Yes, you can use this pattern. I've used it in the past to bring in SVN externals into a git-svn clone. Submodules may handle this better now, but didn't suit my needs at the time.

是的,您可以使用此模式。我过去曾使用它将 SVN 外部组件引入 git-svn 克隆。子模块现在可以更好地处理这个问题,但当时不适合我的需求。

You'll want to add the following to repo1/.git/info/exclude to ensure changes in repo2 don't mix with repo1:

您需要将以下内容添加到 repo1/.git/info/exclude 以确保 repo2 中的更改不会与 repo1 混合:

repo2

回答by drugan

I also agree with Ronald William's answer. The main purpose of Git submodules is updating the code taken from the outside world without need to commit changes if that code were modified by the update.

我也同意罗纳德威廉的回答。Git 子模块的主要目的是更新从外部世界获取的代码,如果该代码被更新修改,则无需提交更改。

The Composer package management system does the same. Actually they don't recommend to commit those changes eitherand ignore the vendorfolder in .gitignore in the root of project.

Composer 包管理系统也是如此。实际上,他们也不建议提交这些更改并忽略项目根目录中 .gitignore 中的供应商文件夹。

It is a nightmare if you'd try to commit this folder because some of the vendor/some_repocan be of a development version, and consequently they have a .git folder which results in all those packages become submodules even if you don't add them with git submodule add. You could see something like this if you modify some_filein a nested .git repository:

如果您尝试提交此文件夹,那将是一场噩梦,因为某些vendor/some_repo可能是开发版本,因此它们有一个 .git 文件夹,即使您不添加,也会导致所有这些包成为子模块他们与git submodule add. 如果您some_file在嵌套的 .git 存储库中进行修改,您可能会看到类似的内容:

~/project_root $ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#   (commit or discard the untracked or modified content in submodules)
#
#    modified:   vendor/nested_repo (modified content)

Note the modified content in submodulesentry and that you don't see the some_filename in the output. Instead you see the (modified content)notice, because the root_project .git sees the vendor/nested_repo as a submodule and does not track individual files in that folder.

请注意子模块条目中的修改内容,并且您some_file在输出中看不到名称。相反,您会看到(修改后的内容)通知,因为 root_project .git 将 vendor/nested_repo 视为子模块,并且不会跟踪该文件夹中的单个文件。

If you run git add --allyou'll get no result until you commit changes in vendor/nested_repoand only after that can you commit changes in the root repository.

如果您运行,git add --all您将不会得到任何结果,直到您提交更改,vendor/nested_repo并且只有在此之后您才能在根存储库中提交更改。

Don't do this. Instead if you want to keep your project as a whole .git repository (any, not only Composer built repository), which is very convenient sometimes, add this entry to the root .gitignore BEFOREthe initial commit:

不要这样做。相反,如果您想将您的项目作为一个完整的 .git 存储库(任何,不仅是 Composer 构建的存储库),有时非常方便,请在初始提交之前将此条目添加到根 .gitignore 中:

.git
!/.git

Unfortunately, for the whole recipe to work you need to run the git addcommand for each of the nested repositories you want later to modify individually. Notice that trailing slash in paths of repositories is a MUST.

不幸的是,git add要使整个配方起作用,您需要为以后希望单独修改的每个嵌套存储库运行该命令。请注意,存储库路径中的尾部斜杠是MUST

~/project_root $ git add vendor/some_repo/ vendor/another_repo/

Then modify some_filein the vendor/some_repoand see the difference:

然后some_file在里面修改,vendor/some_repo看看区别:

~/project_root $ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#    modified:   vendor/some_repo/some_file

That way you can run git add --alland then git commit "Changes ..."in the project_rootas usual.

这样,你可以运行git add --all,然后git commit "Changes ..."project_root照常进行。

回答by Ronald Williams

There are also package management solutions.

还有包管理解决方案。

It is true that Git submodules would allow you to develop with the architecture you described, and Git subtrees provide a similar solution that many people prefer.

Git 子模块确实允许您使用您描述的架构进行开发,并且 Git 子树提供了许多人喜欢的类似解决方案。

In my opinion, package management software is an integral part of any complex project. I like Composerbecause of the intuitive workflows it supports.

在我看来,包管理软件是任何复杂项目不可或缺的一部分。我喜欢Composer,因为它支持直观的工作流程。

Unfortunately Git submodules are not supported by PhpStorm:

不幸的是,PhpStorm 不支持 Git 子模块:

Git submodules should be supported (IDEA-64024)

应支持 Git 子模块 (IDEA-64024)