维护包含其他克隆git回购的git repo [英] Maintaining git repo containing other cloned git repo

问题描述

我正在使用 Sharelatex（github）在网站上工作，但它包含用于其他存储库建立主要项目。我克隆了主存储库，并执行了 grunt install ，它用于下载这些存储库。

但问题是我需要更改主存储库和下载库中的代码。

由于这些项目可以获得新的更新，我也想合并这些更改。我还需要维护一个回购，但是当我将更改推送到Github时，它只会显示主回购库中的更改。

我在git中遇到了子模块，但由于主项目没有包含任何子模块类型，我无法使用

例如：

有一个回购 web 用于主项目。我从 web 中的文件开始一些编辑。我需要这些更改以反映在我的远程存储库中，以便其他人可以使用它们。

现在假设在一段时间后， web repo的重要更新可用，我应该如何使用它？

我在命令行中输入 grunt install 来下载此回购。它不创建子模块，但克隆回购到我的文件夹，随后由我的主git回购忽略。

这个问题可能似乎不清楚，但我尽我所能解释问题。

在坚果壳中：

• 我不仅希望在主要和任何其他回购协议中执行更改，但是当它们的更新可用时，也可以将其他回购协议进行合并。

我也是需要维护我的项目的远程仓库。



解决方案




我在使用Sharelatex（github）的网站上工作，但它包含用于构建主项目的其他存储库。 [...]我在git中遇到子模块，但由于主项目不包含任何子模块类型的东西，我无法使用它。


实际上，您确实有一个子模块。这就是一个嵌套的存储库，并且（我对此很认真），只要你需要理解grok子模块，那就是 all 子模块。要理解子模块，想象你有一个嵌套的存储库（你这样做）并考虑管理需求，需要做什么才能在dvcs中支持该设置。对于初学者来说，当人们克隆一个使用来自某些回购的子模块的项目时，你已经决定包含已发布的提交，该克隆显然不会获得子项目存储库（当然它不应该让你的私人和神知道你做了什么版本）。因此，他们也必须从其自己发布的某个仓库中获得子项目回购。





你如何告诉人们提交你的提交以获得必要的子项目提交？显然，你必须在一个提交文件的某处放置一个注释，说这里有一个回购，应该有任何需要的$子项目提交。 git submodule 已经在 .gitmodules 的位置上存储，用于存储这样的笔记。





接下来：呃，如果你交给他们的网址离线，别人怎么办？他们显然需要使用另一个回购。因此， .gitmodules 只是建议， git子模块命令使用中的当前值， .git / config ，其中 git子模块init 已经从建议的.gitmodules中填充。





git submodule 的操作都是所有 。忘掉它。除非你需要一点帮助来做你已经发现的事情，否则你甚至都不会去看命令。从知识开始，简单的事实是，子模块只不过是一个嵌套的回购，而使用它的项目提交的只是一个提交ID，它应该在嵌套回购的某处。而已。这就是所有的子模块。





当您在需要做的繁琐任务中运行时，请查找 git submodule 子命令为他们做他们。您不必使用子命令。所有子命令正在做的是自动执行简单的任务，否则会很费力。它是一个工具箱，可以做任何你需要做的事情，而且它不可能或者应该对世界上的每个人强加一些任意和充分的（< - 那是困难的部分）抽象。所以这是一个抓包。





也就是说，有一个重要的安全机制 git submodule update 和<$当你为你完成 git clone 时，c $ c> git submodule add 为你执行。存储库通常在[sub]项目顶层 .git 下具有实际的回购内容，但是如果签出的分支没有那个子项目或者需要或想要那个子项目不见了，它的 .git 也会消失 - 而不是你想要的，当它不仅包含你签出的内容，还包括整个实际的回购。因此，当 git子模块更新执行其初始克隆时，它将子模块的 .git 目录提升为方便（任意）在包含项目的回购库中小小的角落，并用 .git .git 目录>文件，其中包含移动目录的相对路径。





要获得您当前具有的回购的初始吊装，请将其移出当前回购，添加和更新从任何地方放置它，然后修复 .gitmodules 中的上游url以方便其他人。





那里。现在，您知道了解git子模块所需知道的所有知识，并且只是在您发现需要它们时逐步获取详细信息，才能了解 git子模块命令为您执行的操作，以及为什么你实际上不必在意它的帮助页面上关于理解每一件小事。至少，我是这么认为的。





如果我错过了任何重要的东西，我会很高兴（温柔或钝，我真的不在乎）更正在评论。




I am working on a website using Sharelatex(github) but it contains other repositories that are used to build the main project. I cloned the main repository and did grunt install which is used to download those repositories.

But the problem is that I need to change the code in both main repository and the downloaded ones.

Since these projects can get new updates I want to merge those changes as well. I also need to maintain a repo, but when I push changes to Github it only shows changes in the main repo.

I came across submodules in git but since the main project does not contain any submodule types I am unable to use that.

For example:

There is a repo web used in the main project. I begin with some edits in the files in web. I need these changes to reflect in my remote repository so that others can use them.

Now suppose after some time an important update for web repo is available, how should I use that?

I enter grunt install in the command line to download this repo. It does not create a submodule but clones that repo into my folder, which is subsequently ignored by my main git repo.

The question might seem unclear but I tried my best to explain the problem.

In the nut-shell:

• I want not only to perform changes in both main and any other repo that's involved, but pull and merge those other repos, as well, when their updates are available.

• I also need to maintain a remote repo of my project.

解决方案

I am working on a website using Sharelatex(github) but it contains other repository that are used to build the main project. [...] I came across submodules in git but since the main project does not contain any submodule kind of thing I am unable to use that.

Actually, you do have a submodule. That's what a nested repository is, and (I'm serious about this) so far as what you need to understand to grok submodules, that's all there is to submodules. To understand submodules, imagine you have a nested repository (you do) and think about the administrative requirements, what needs to be done to support that setup in a dvcs.

For starters, when people clone a project that uses submodules from some repo you've all decided contains published commits, that clone obviously won't also get the subproject repository (certainly it shouldn't get your private and god-knows-what-you've-done-to-it version). So they also have to get the subproject repo from some one of its own published repositories.

How do you tell people fetching your commits where to get the necessary subproject commits? Plainly, you have to drop a note somewhere in a committed file saying "here's a repo that should have any needed $subproject commits". git submodule has settled on .gitmodules as the conventional place to store notes like this.

Next up: well, what are others to do if the url you handed them goes offline? They're plainly going to need to use another repo. Hence, .gitmodules is just suggestions, the git submodule command uses the current values in your .git/config, which git submodule init has populated from the suggested ones in .gitmodules`.

git submodule's operations are all like this. Forget about it. Don't even bother looking at the command until you need a little assistance doing what you have already found needs doing. Start from the knowledge, the simple fact, that a submodule is nothing more than a nested repo, and the project using it commits nothing more than a commit id that's supposed to be somewhere in that nested repo. That's it. That's all a submodule is.

As you run across tedious tasks that need doing, look for a git submodule subcommand that does them for you. You don't have to use the subcommand. All that subcommand is doing is automating straightforward tasks that would be laborious otherwise. It's a toolkit for doing whatever it is you need to do, and there's no way on earth it could or should impose some arbitrary and sufficient (<-- that's the hard part) abstraction on everybody in the world. So it's a grab-bag.

That said, there is one important safety play git submodule update and git submodule add perform for you when they do the git clone for you. Repositories conventionally have the actual repo content under the [sub]project toplevel .git, but if you check out a branch that doesn't have that subproject there or otherwise need or want that subproject gone, its .git will also go away -- not what you want when it holds not just your checked out content but the entire actual repo. So when git submodule update does its initial clone, it hoists the submodule's .git directory into a handy (and arbitrary) little nook in the containing project's repo, and replaces the .git directory it just moved out of the submodule with a .git file containing the relative path to the moved directory.

To get that initial hoisting done on the repo you currently have, move it out of your current repo, add and update from wherever you put it, and then fix up the upstream urls in .gitmodules for the convenience of others.

There. Now you know absolutely everything you need to know to understand git submodules and incrementally acquire details only as you find you need them, to understand what the git submodule command is doing for you, and why you don't actually have to care about understanding every little thing on its manpage up front. At least, I think so.

If I've missed anything important, I'd be very glad of (gentle or blunt, I really don't care) corrections in the comments.

这篇关于维护包含其他克隆git回购的git repo的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！