Git how to pull submodule

How to Pull the Latest Git Submodule

It is possible to include different git repositories into a single repository in Git. The included repositories are known as submodules. Submodules are repositories that are involved in the parent repository at a particular path in the working directory of the parent repository.

Steps to pulling the latest submodule

While working with submodules, it is often necessary to pull the latest git submodule. In case you are doing it the first time, you should initiate submodules on their repository. Follow the steps below:

Setting up a submodule

Create a new submodule by running:

Updating to latest tips of remote branch:

If your Git version is 1.7.3. Or above, you need to run:

Pushing updates in git submodule

As the submodule represents a separate repository, it allows running the git push command in the directory of the submodule.

If you invoke the git status command in your principal repository, the submodule will be in the “Changes not staged for commit” with the following text: “modified content. It will check out the code of the submodule on another commit, not the one that your main repository is pointing at. If you want the principal repository to point at the new commit, you need to invoke the git add command, commit, and finally push it.

Cloning git submodules

Generally, if you want to keep your projects in different repositories, using submodules is the right decision. Anyway, you should take into consideration the fact that working with submodules is quite tricky, and you can’t use them for all your projects.

This tutorial explains the usage of submodules with the Git version control system.

Learn more in the Learning Portal. Check out our

1.1. Using Git repositories inside other Git repositories

Git allows you to commit, pull and push to these repositories independently.

Submodules allow you to keep projects in separate repositories but still be able to reference them as folders in the working directory of other repositories.

2. Working with repositories that contain submodules

2.1. Cloning a repository that contains submodules

2.2. Downloading multiple submodules at once

2.3. Pulling with submodules

2.4. Executing a command on every submodule

3. Creating repositories with submodules

3.1. Adding a submodule to a Git repository and tracking a branch

3.2. Adding a submodule and tracking commits

Alternatively to the tracking of a branch, you can also control which commit of the submodule should be used. In this case the Git parent repository tracks the commit that should be checked out in each configured submodule. Performing a submodule update checks out that specific revision in the submodule’s Git repository. You commonly perform this task after you pull a change in the parent repository that updates the revision checked out in the submodule. You would then fetch the latest changes in the submodule’s Git repository and perform a submodule update to check out the current revision referenced in the parent repository. Performing a submodule update is also useful when you want to restore your submodule’s repository to the current commit tracked by the parent repository. This is common when you are experimenting with different checked out branches or tags in the submodule and you want to restore it back to the commit tracked by the parent repository. You can also change the commit that is checked out in each submodule by performing a checkout in the submodule repository and then committing the change in the parent repository.

You add a submodule to a Git repository via the git submodule add command.

3.3. Updating which commit you are tracking

The relevant state for the submodules are defined by the main repository. If you commit in your main repository, the state of the submodule is also defined by this commit.

The git submodule update command sets the Git repository of the submodule to that particular commit. The submodule repository tracks its own content which is nested into the main repository. The main repository refers to a commit of the nested submodule repository.

Use the git submodule update command to set the submodules to the commit specified by the main repository. This means that if you pull in new changes into the submodules, you need to create a new commit in your main repository in order to track the updates of the nested submodules.

The following example shows how to update a submodule to its latest commit in its master branch.

Another developer can get the update by pulling in the changes and running the submodules update command.

With this setup you need to create a new commit in the master repository, to use a new state in the submodule. You need to repeat this procedure every time you want to use another state in one of the submodules. See Adding a submodule to a Git repository and tracking a branch for tracking a certain branch of a submodule.

3.4. Delete a submodule from a repository

Currently Git provides no standard interface to delete a submodule. To remove a submodule called mymodule you need to:

gitaarik / git_submodules.md

Git Submodules basic explanation

In Git you can add a submodule to a repository. This is basically a repository embedded in your main repository. This can be very useful. A couple of advantages of using submodules:

You can separate the code into different repositories.

Useful if you have a codebase with big components, you could make a component a submodule. This way you’ll have a cleaner Git log (commits are specific to a certain component).

You can add the submodule to multiple repositories.

Useful if you have multiple repositories that share the same components. With this approach you can easily update those components in all the repositories that added them as a submodule. This is a lot more convienient than copy-pasting the code into the repositories.

When you add a submodule in Git, you don’t add the code of the submodule to the main repository, you only add information about the submodule that is added to the main repository. This information describes which commit the submodule is pointing at. This way, the submodule’s code won’t automatically be updated if the submodule’s repository is updated. This is good, because your code might not work with the latest commit of the submodule, it prevents unexpected behaviour.

Adding a submodule

You can add a submodule to a repository like this:

With default configuration, this will check out the code of the awesome_submodule.git repository to the path_to_awesome_submodule directory, and will add information to the main repository about this submodule, which contains the commit the submodule points to, which will be the current commit of the default branch (usually the master branch) at the time this command is executed.

Getting the submodule’s code

This will pull all the code from the submodule and place it in the directory that it’s configured to.

Pushing updates in the submodule

The submodule is just a separate repository. If you want to make changes to it, you should make the changes in its repository and push them like in a regular Git repository (just execute the git commands in the submodule’s directory). However, you should also let the main repository know that you’ve updated the submodule’s repository, and make it use the new commit of the repository of the submodule. Because if you make new commits inside a submodule, the main repository will still point to the old commit.

If there are changes in the submodule’s repository, then git status in the main repository, will show Changes not staged for commit and it has the text (modified content) behind it. This means that the code of the submodule is checked out on a different commit than the main repository is pointing to. To make the main repository point to this new commit, you should create another commit in the main repository.

The next sections describe different scenarios on doing this.

Make changes inside a submodule

Update the submodule pointer to a different commit

If someone else updated the submodule pointer

What happens if you don’t run this command?

Making it easier for everyone

It is sometimes annoying if you forget to initiate and update your submodules. Fortunately, there are some tricks to make it easier:

This will clone a repository and also check out and init any possible submodules the repository has.

This will pull the main repository and also it’s submodules.

Submodules

It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other.

Here’s an example. Suppose you’re developing a website and creating Atom feeds. Instead of writing your own Atom-generating code, you decide to use a library. You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. The issue with copying the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available.

Git addresses this issue using submodules. Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate.

Starting with Submodules

We’ll walk through developing a simple project that has been split up into a main project and a few sub-projects.

Let’s start by adding an existing Git repository as a submodule of the repository that we’re working on. To add a new submodule you use the git submodule add command with the absolute or relative URL of the project you would like to start tracking. In this example, we’ll add a library called “DbConnector”.

By default, submodules will add the subproject into a directory named the same as the repository, in this case “DbConnector”. You can add a different path at the end of the command if you want it to go elsewhere.

If you run git status at this point, you’ll notice a few things.

The other listing in the git status output is the project folder entry. If you run git diff on that, you see something interesting:

Although DbConnector is a subdirectory in your working directory, Git sees it as a submodule and doesn’t track its contents when you’re not in that directory. Instead, Git sees it as a particular commit from that repository.

When you commit, you see something like this:

Notice the 160000 mode for the DbConnector entry. That is a special mode in Git that basically means you’re recording a commit as a directory entry rather than a subdirectory or a file.

Lastly, push these changes:

Cloning a Project with Submodules

Here we’ll clone a project with a submodule in it. When you clone such a project, by default you get the directories that contain submodules, but none of the files within them yet:

The DbConnector directory is there, but empty. You must run two commands: git submodule init to initialize your local configuration file, and git submodule update to fetch all the data from that project and check out the appropriate commit listed in your superproject:

Now your DbConnector subdirectory is at the exact state it was in when you committed earlier.

Working on a Project with Submodules

Now we have a copy of a project with submodules in it and will collaborate with our teammates on both the main project and the submodule project.

Pulling in Upstream Changes from the Submodule Remote

The simplest model of using submodules in a project would be if you were simply consuming a subproject and wanted to get updates from it from time to time but were not actually modifying anything in your checkout. Let’s walk through a simple example there.

If you want to check for new work in a submodule, you can go into the directory and run git fetch and git merge the upstream branch to update the local code.

If you commit at this point then you will lock the submodule into having the new code when other people update.

When we run git status at this point, Git will show us that we have “new commits” on the submodule.

Pulling Upstream Changes from the Project Remote

Let’s now step into the shoes of your collaborator, who has their own local clone of the MainProject repository. Simply executing git pull to get your newly committed changes is not enough:

By default, the git pull command recursively fetches submodules changes, as we can see in the output of the first command above. However, it does not update the submodules. This is shown by the output of the git status command, which shows the submodule is “modified”, and has “new commits”. What’s more, the brackets showing the new commits point left ( git submodule update :

Working on a Submodule

It’s quite likely that if you’re using submodules, you’re doing so because you really want to work on the code in the submodule at the same time as you’re working on the code in the main project (or across several submodules). Otherwise you would probably instead be using a simpler dependency management system (such as Maven or Rubygems).

So now let’s go through an example of making changes to the submodule at the same time as the main project and committing and publishing those changes at the same time.

First of all, let’s go into our submodule directory and check out a branch.

If we go into the DbConnector directory, we have the new changes already merged into our local stable branch. Now let’s see what happens when we make our own local change to the library and someone else pushes another change upstream at the same time.

Now if we update our submodule we can see what happens when we have made a local change and upstream also has a change we need to incorporate.

If this happens, don’t worry, you can simply go back into the directory and check out your branch again (which will still contain your work) and merge or rebase origin/stable (or whatever remote branch you want) manually.

If you haven’t committed your changes in your submodule and you run a submodule update that would cause issues, Git will fetch the changes but not overwrite unsaved work in your submodule directory.

If you made changes that conflict with something changed upstream, Git will let you know when you run the update.

You can go into the submodule directory and fix the conflict just as you normally would.

Publishing Submodule Changes

Now we have some changes in our submodule directory. Some of these were brought in from upstream by our updates and others were made locally and aren’t available to anyone else yet as we haven’t pushed them yet.

If we commit in the main project and push it up without pushing the submodule changes up as well, other people who try to check out our changes are going to be in trouble since they will have no way to get the submodule changes that are depended on. Those changes will only exist on our local copy.

The other option is to use the “on-demand” value, which will try to do this for you.

Merging Submodule Changes

If you change a submodule reference at the same time as someone else, you may run into some problems. That is, if the submodule histories have diverged and are committed to diverging branches in a superproject, it may take a bit of work for you to fix.

If one of the commits is a direct ancestor of the other (a fast-forward merge), then Git will simply choose the latter for the merge, so that works fine.

Git will not attempt even a trivial merge for you, however. If the submodule commits diverge and need to be merged, you will get something that looks like this:

So basically what has happened here is that Git has figured out that the two branches record points in the submodule’s history that are divergent and need to be merged. It explains it as “merge following commits not found”, which is confusing but we’ll explain why that is in a bit.

To solve the problem, you need to figure out what state the submodule should be in. Strangely, Git doesn’t really give you much information to help out here, not even the SHA-1s of the commits of both sides of the history. Fortunately, it’s simple to figure out. If you run git diff you can get the SHA-1s of the commits recorded in both branches you were trying to merge.

So, in this case, eb41d76 is the commit in our submodule that we had and c771610 is the commit that upstream had. If we go into our submodule directory, it should already be on eb41d76 as the merge would not have touched it. If for whatever reason it’s not, you can simply create and checkout a branch pointing to it.

What is important is the SHA-1 of the commit from the other side. This is what you’ll have to merge in and resolve. You can either just try the merge with the SHA-1 directly, or you can create a branch for it and then try to merge that in. We would suggest the latter, even if only to make a nicer merge commit message.

We got an actual merge conflict here, so if we resolve that and commit it, then we can simply update the main project with the result.

First we resolve the conflict.

Then we go back to the main project directory.

We can check the SHA-1s again.

Resolve the conflicted submodule entry.

Commit our merge.

It can be a bit confusing, but it’s really not very hard.

Interestingly, there is another case that Git handles. If a merge commit exists in the submodule directory that contains both commits in its history, Git will suggest it to you as a possible solution. It sees that at some point in the submodule project, someone merged branches containing these two commits, so maybe you’ll want that one.

This is why the error message from before was “merge following commits not found”, because it could not do this. It’s confusing because who would expect it to try to do this?

If it does find a single acceptable merge commit, you’ll see something like this:

The suggested command Git is providing will update the index as though you had run git add (which clears the conflict), then commit. You probably shouldn’t do this though. You can just as easily go into the submodule directory, see what the difference is, fast-forward to this commit, test it properly, and then commit it.

This accomplishes the same thing, but at least this way you can verify that it works and you have the code in your submodule directory when you’re done.

Submodule Tips

There are a few things you can do to make working with submodules a little easier.

Submodule Foreach

There is a foreach submodule command to run some arbitrary command in each submodule. This can be really helpful if you have a number of submodules in the same project.

For example, let’s say we want to start a new feature or do a bugfix and we have work going on in several submodules. We can easily stash all the work in all our submodules.

Then we can create a new branch and switch to it in all our submodules.

You get the idea. One really useful thing you can do is produce a nice unified diff of what is changed in your main project and all your subprojects as well.

Here we can see that we’re defining a function in a submodule and calling it in the main project. This is obviously a simplified example, but hopefully it gives you an idea of how this may be useful.

Useful Aliases

You may want to set up some aliases for some of these commands as they can be quite long and you can’t set configuration options for most of them to make them defaults. We covered setting up Git aliases in Git Aliases, but here is an example of what you may want to set up if you plan on working with submodules in Git a lot.

This way you can simply run git supdate when you want to update your submodules, or git spush to push with submodule dependency checking.

Issues with Submodules

Using submodules isn’t without hiccups, however.

Switching branches

For instance, switching branches with submodules in them can also be tricky with Git versions older than Git 2.13. If you create a new branch, add a submodule there, and then switch back to a branch without that submodule, you still have the submodule directory as an untracked directory:

Again, not really very difficult, but it can be a little confusing.

Switching from subdirectories to submodules

You have to unstage the CryptoLibrary directory first. Then you can add the submodule:

Now suppose you did that in a branch. If you try to switch back to a branch where those files are still in the actual tree rather than a submodule – you get this error:

With these tools, submodules can be a fairly simple and effective method for developing on several related but still separate projects simultaneously.

Подмодули

Часто при работе над одним проектом, возникает необходимость использовать в нем другой проект. Возможно, это библиотека, разрабатываемая сторонними разработчиками или вами, но в рамках отдельного проекта, и используемая в нескольких других проектах. Типичная проблема, возникающая при этом — вы хотите продолжать работать с двумя проектами по отдельности, но при этом использовать один из них в другом.

Приведём пример. Предположим, вы разрабатываете веб-сайт и создаёте ленту в формате Atom. Вместо написания собственного генератора Atom, вы решили использовать библиотеку. Скорее всего, вы либо подключите библиотеку как сторонний модуль, такой как модуль CPAN или Ruby Gem, либо скопируете исходный код библиотеки в свой проект. Проблема использования библиотеки состоит в трудности её адаптации под собственные нужды и часто более сложным является её распространение, так как нужно быть уверенным, что каждому клиенту доступна изменённая версия. При включении кода библиотеки в свой проект проблемой будет объединение ваших изменений в ней с новыми изменениями в оригинальном репозитории.

Git решает эту проблему с помощью подмодулей. Подмодули позволяют вам сохранить один Git-репозиторий, как подкаталог другого Git-репозитория. Это даёт вам возможность клонировать в ваш проект другой репозиторий, но коммиты при этом хранить отдельно.

Начало работы с подмодулями

Далее мы рассмотрим процесс разработки простого проекта, разбитого на один главный проект и несколько подпроектов.

По умолчанию подмодуль сохраняется в каталог с именем репозитория, в нашем примере — « DbConnector ». Изменить каталог сохранения подмодуля можно указав путь к нему в конце команды.

Следующим пунктом в списке вывода команды git status будет запись о каталоге проекта. Команда git diff покажет для него кое-что интересное:

Хоть DbConnector и является подкаталогом вашего рабочего каталога, Git распознает его как подмодуль и не отслеживает его содержимое пока вы не перейдёте в него. Вместо этого, Git видит его как конкретный коммит этого репозитория.

При создании коммита вы увидите следующее:

Наконец, отправьте эти изменения:

Клонирование проекта с подмодулями

Далее мы рассмотрим клонирование проекта, содержащего подмодули. Когда вы клонируете такой проект, по умолчанию вы получите каталоги, содержащие подмодули, но ни одного файла в них не будет:

Каталог DbConnector присутствует, но он пустой. Вы должны выполнить две команды: git submodule init — для инициализации локального конфигурационного файла, и git submodule update — для получения всех данных этого проекта и извлечения соответствующего коммита, указанного в основном проекте.

Теперь ваш каталог DbConnector находится в точно таком же состоянии, как и ранее при выполнении коммита.

Работа над проектом с подмодулями

Теперь, когда у нас есть копия проекта с подмодулями, мы будем работать совместно с нашими коллегами над обоими проектами: основным проектом и проектом подмодуля.

Получение изменений подмодуля из удалённого репозитория

Простейший вариант использования подмодулей в проекте состоит в том, что вы просто получаете сам подпроект и хотите периодически получать обновления, при этом в своей копии проекта ничего не изменяете. Давайте рассмотрим этот простой пример.

Если сейчас вы создадите коммит, то состояние подмодуля будет зафиксировано с учётом последних изменений, что позволит другим людям их получить.

Получение изменений основного проекта из удалённого репозитория

Теперь давайте поставим себя на место нашего коллеги, у которого есть собственная копия репозитория MainProject. Простого запуска команды git pull для получения последних изменений уже недостаточно:

Работа с подмодулем

Весьма вероятно, что вы используете подмодули, потому что хотите работать над кодом подмодуля (или нескольких подмодулей) во время работы над кодом основного проекта. Иначе бы вы, скорее всего, предпочли использовать более простую систему управления зависимостями (такую как Maven или Rubygems).

Давайте теперь рассмотрим пример, в котором мы одновременно с изменениями в основном проекте внесём изменения в подмодуль, зафиксировав и опубликовав все эти изменения в одно и то же время.

Первым делом, давайте перейдём в каталог нашего подмодуля и переключимся на нужную ветку.

Теперь мы можем увидеть что происходит при обновлении подмодуля, когда локальные изменения должны включать новые изменения, полученные с удалённого сервера.

Если такое происходит — не беспокойтесь, вы всегда можете перейти в каталог подмодуля, переключиться на вашу ветку (которая всё ещё будет содержать ваши наработки) и вручную слить ветку origin/stable или перебазировать свои изменения относительно неё (или любую другую удалённую ветку).

Если вы не зафиксировали ваши изменения в подмодуле и выполнили его обновление, то это приведёт к проблемам — Git получит изменения из удалённого репозитория, но не перезапишет несохранённые изменения в каталоге вашего подмодуля.

Если ваши локальные изменения в подмодуле конфликтуют с какими-либо изменениями в удалённом репозитории, то Git вам сообщит об этом при обновлении подмодуля.

Для разрешения конфликта вы можете перейти в каталог подмодуля и сделать это как вы бы делали в обычной ситуации.

Публикация изменений подмодуля

Теперь у нас есть некоторые изменения в каталоге нашего подмодуля. Какие-то из них мы получили при обновлении из удалённого репозитория, а другие были сделаны локально и пока никому не доступны, так как мы их ещё никуда не отправили.

Если мы создадим коммит в основном проекте и отправим его на сервер, не отправив при этом изменения в подмодуле, то другие люди, которые попытаются использовать наши изменения, столкнутся с проблемой, так как у них не будет возможности получить требуемые изменения подмодуля. Эти изменения будут присутствовать только в нашей локальной копии.

Другой вариант — это использовать значение « on-demand », тогда Git попытается сделать всё вышеописанное за вас.

Слияние изменений подмодуля

Если вы измените ссылку на подмодуль одновременно с кем-то ещё, то вы можете столкнуться с некоторыми проблемами. Такое случается если истории подмодуля разошлись и они зафиксированы в разошедшихся ветках основного проекта, что может потребовать некоторых усилий для исправления.

Если один из коммитов является прямым предком другого (слияние может быть выполнено перемоткой вперёд), то Git просто выберет последний для выполнения слияния, то есть все отработает хорошо.

Однако, Git не будет пытаться выполнить даже простейшего слияния. Если коммиты подмодуля разошлись и слияние необходимо, вы получите нечто подобное:

Здесь говорится о том, что Git понял, что в этих двух ветках содержатся указатели на разошедшиеся записи в истории подмодуля и их необходимо слить. Git поясняет это как «слияние последующих коммитов не найдено» («merge following commits not found»), что несколько обескураживает, но вскоре мы объясним почему так происходит.

Куда более важным является SHA-1 хеш коммита второй ветки истории. Именно его мы должны будем слить и разрешить конфликты. Вы можете попытаться либо просто выполнить слияние, указав непосредственно этот SHA-1 хеш, либо создать из него отдельную ветку и слить её. Мы предлагаем использовать последний вариант, хотя бы только потому, что сообщение коммита слияния получается более читаемым.

Итак, перейдите в каталог нашего подмодуля, создайте ветку « try-merge » на основе второго SHA-1 хеша из git diff и выполните слияние вручную.

Мы получили конфликт слияния, поэтому если мы разрешим его и создадим коммит, то можно просто включить результирующий коммит в основной проект.

Во-первых, мы разрешили конфликт.

Затем мы вернулись в каталог основного проекта.

Мы снова проверили SHA-1 хеши.

Обновили указатель на подмодуль с учётом разрешенного конфликта.

Зафиксировали наше слияние, создав новый коммит.

Это может немного запутать, но на самом деле здесь нет ничего сложного.

Интересно, что существует ещё один случай, с которым Git умеет работать. Если подмодуль содержит некий коммит слияния, который в своей истории содержит оба первоначальных коммита, то Git предложит его как возможное решение. Git видит, что в проекте подмодуля ветки, содержащие эти два коммита, уже когда-то кем-то сливались и этот коммит слияния, вероятно, именно то, что вам нужно.

Именно поэтому сообщение об ошибке выше было «merge following commits not found» — Git не мог найти такой коммит. Кто бы мог подумать, что Git пытается такое сделать?

Если Git нашёл только один приемлемый коммит слияния, то вы увидите нечто подобное:

Предлагаемая команда обновляет индекс таким же образом, как если бы вы выполнили git add (что очищает список конфликтов), а затем создали коммит. Хотя, наверное, вам не стоит так делать. Будет лучше просто перейти в каталог подмодуля, просмотреть изменения, сместить вашу ветку на этот коммит, должным образом всё протестировать и только потом создать коммит в основном репозитории.

Это приводит к аналогичному результату, но таким способом вы получаете рабочий проверенный код в каталоге подмодуля.

Полезные советы

Существует несколько хитростей, которые могут немного упростить вашу работу с подмодулями.

Команда Foreach

Для примера допустим, что мы хотим начать работу над какой-то новой функциональностью или исправить какую-то ошибку и наша работа затронет сразу несколько подмодулей. Мы можем легко припрятать все наработки во всех наших подмодулях.

Затем мы можем создать новую ветку и переключиться на неё во всех наших подмодулях.

Вы уловили идею. Ещё одна полезная вещь, которую можно сделать с помощью этой команды — создать комплексную дельту изменений основного проекта и всех подмодулей.

Здесь видно, что мы определили в подмодуле функцию и вызываем её в основном проекте. Это, конечно, упрощённый пример, но надеемся, что мы смогли донести до вас всю полезность этой функции.

Полезные псевдонимы

Возможно, вы захотите настроить псевдонимы для некоторых из этих команд, так как они могут быть довольно длинными и для большинства из них вы не можете задать значения по умолчанию. Мы рассмотрели настройку псевдонимов Git в разделе Псевдонимы в Git главы 2, однако ниже приведен пример, который вы наверняка захотите использовать, если планируете часто работать с подмодулями Git.

Проблемы с подмодулями

Однако, использование подмодулей не обходится без проблем.

Переключение веток

Например, переключение веток с подмодулями в них может оказаться довольно запутанным, особенно для версий Git старше 2.13. Если вы создадите новую ветку и добавите в ней подмодуль, а затем переключитесь обратно на ветку без подмодуля, то каталог подмодуля всё равно останется и будет неотслеживаемым:

Опять же, это не сильно сложно, но может немного сбивать с толку.

Переход от подкаталогов к подмодулям

Первым делом вы должны удалить каталог CryptoLibrary из индекса. Затем можно добавить подмодуль:

Предположим, что вы сделали это в какой-то ветке. Если вы попробуете переключиться обратно на ветку, в которой эти файлы всё ещё являются частью основного проекта, то вы получите ошибку:

Все эти инструменты делают подмодули довольно простым и эффективным методом работы одновременно над несколькими тесно связанными, но разделёнными проектами.