Простой способ получить последние из всех подмодулей git
Мы используем подмодули git для управления парой крупных проектов, которые зависят от многих других библиотек, которые мы разработали. Каждая библиотека представляет собой отдельный репозиторий, внесенный в зависимый проект в виде подмодуля. Во время разработки мы часто хотим просто взять последнюю версию каждого зависимого подмодуля.
Есть ли в git встроенная команда для этого? Если нет, то как насчет пакетного файла Windows или аналогичного, который может это сделать?
Для git 1.7.3 или выше вы можете использовать (но ниже приведены некоторые вопросы о том, какое обновление все еще применяется):
если вы хотите подтянуть свои подмодули к последним коммитам вместо текущего коммита, на который указывает репо.
Смотрите git-submodule (1) для подробностей
Git впервые узнал в 1.8.5.
Пока ошибка не будет устранена, в первый раз вам нужно запустить
На init запускается следующая команда:
из каталога git repo лучше всего работает для меня.
Это потянет все последние, включая подмодули.
Разъяснения
После этого вы можете просто запустить:
из каталога git repo лучше всего работает для меня.
Это потянет все последние, включая подмодули.
Примечание: это с 2009 года и, возможно, тогда было хорошо, но сейчас есть лучшие варианты.
Мы используем это. Это называется git-pup :
Просто поместите его в подходящий каталог bin (/ usr / local / bin). Если в Windows вам может понадобиться изменить синтаксис, чтобы заставить его работать 🙂
Обновить:
После этого создайте простой скрипт, который выполняет следующие действия:
Я хотел бы отметить, что этот стиль не совсем то, для чего были созданы подмодули git. Как правило, вы хотите сказать, что «LibraryX» имеет версию «2.32» и будет оставаться такой, пока я не скажу «обновить».
Это в некотором смысле то, что вы делаете с описанным сценарием, но просто более автоматически. Требуется осторожность!
Обновление 2:
Если вы работаете на платформе Windows, вы можете захотеть использовать Python для реализации скрипта, так как он очень эффективен в этих областях. Если вы используете unix / linux, тогда я предлагаю просто скрипт bash.
Нужны какие-либо разъяснения? Просто оставьте комментарий.
The GitHub Blog
Working with submodules
Eventually, any interesting software project will come to depend on another project, library, or framework. Git provides submodules to help with this. Submodules allow you to include or embed one or more repositories as a sub-folder inside another repository.
For many projects, submodules aren’t the best answer (more on this below), and even at their best, working with submodules can be tricky, but let’s start by looking at a straight-forward example.
Adding a Submodule
flickr photo shared by young@art under a Creative Commons ( BY ) license
At the same time, in another repository, you’ve got another project called Rock—it’s just a generic rock library, but you think it’d be perfect for Slingshot.
Newer versions of Git will do this automatically, but older versions will require you to explicitly tell Git to download the contents of rock :
If everything looks good, you can commit this change and you’ll have a rock folder in the slingshot repository with all the content from the rock repository.
On GitHub, the rock folder icon will have a little indicator showing that it is a submodule:
And clicking on the rock folder will take you over to the rock repository.
That’s it! You’ve embedded the rock repository inside the slingshot repository. You can interact with all the content from rock as if it were a folder inside slingshot (because it is).
Joining a project using submodules
Now, say you’re a new collaborator joining Project Slingshot. You’d start by running git clone to download the contents of the slingshot repository. At this point, if you were to peek inside the rock folder, you’d see … nothing.
Switching to submodules
It can be a little tricky to take an existing subfolder and turn it into an external dependency. Let’s look at an example.
You can take everything from the Project Slingshot’s rubber-band folder and extract it into a new repository and even maintain the commit history.
Now that you’ve separated rubber-band into its own repository, you need to delete the old rubber-band folder from the slingshot repository:
Then update slingshot to use rubber-band as a submodule:
In addition, if we dive back into slingshot ‘s history, we’ll see the commits we originally made into rubber-band back when it was a folder—deleting the folder didn’t erase any of the history. This can sometimes be a little confusing—since the rubber-band “child” repository has a copied-and-modified version of those old slingshot commits, it can sometimes feel like you’re having déja vu.
Unfortunately, any collaborator who pulls slingshot at this point will have an empty rubber-band folder. You might want to remind your collaborators to run this command to ensure they have all the submodule’s content:
Понимание и работа с подмодулями в Git
Большинство современных программных проектов зависят от работы других. Было бы пустой тратой времени изобретать велосипед в собственном коде, если кто-то уже написал замечательное решение. Вот почему так много проектов используют сторонний код в виде библиотек или модулей.
Git, самая популярная в мире система контроля версий, предлагает отличный способ элегантного и надежного управления этими зависимостями. Его концепция «подмодулей» позволяет нам включать и управлять сторонними библиотеками, сохраняя их четко отделенными от нашего собственного кода.
Из этой статьи вы узнаете, почему подмодули в Git так полезны, что они из себя представляют и как работают.
Хранение кода отдельно
Чтобы понять, почему подмодули Git действительно являются бесценной структурой, давайте рассмотрим случай без подмодулей. Когда вам нужно включить сторонний код (например, библиотеку с открытым исходным кодом), вы, конечно, можете пойти простым путем: просто загрузите код с GitHub и скопируйте его куда-нибудь в свой проект. Хотя этот подход, безусловно, быстрый, он определенно грязный по двум причинам:
Общее правило в разработке программного обеспечения «держать отдельные вещи отдельно» существует не просто так. И это, безусловно, верно для управления сторонним кодом в ваших собственных проектах. К счастью, концепция подмодуля Git была создана именно для таких ситуаций.
Но, конечно, субмодули — не единственное доступное решение для такого рода проблем. Вы также можете использовать одну из различных систем «менеджеров пакетов», которые предоставляют многие современные языки и фреймворки. И в этом нет ничего плохого!
Однако вы можете возразить, что архитектура подмодулей Git имеет несколько преимуществ:
Что такое подмодули Git
Подмодули в Git — это просто стандартные репозитории Git. Никаких модных инноваций, все те же репозитории Git, которые мы все так хорошо знаем. Это тоже часть мощи субмодулей: они такие надежные и простые, потому что они «утомительны» (с технологической точки зрения) и прошли полевые испытания.
Единственное, что делает репозиторий Git подмодулем, — это то, что он помещается в другой, родительский репозиторий Git.
Помимо этого, подмодуль Git остается полностью функциональным репозиторием: вы можете выполнять все действия, которые вы уже знаете из своей «нормальной» работы с Git — от изменения файлов до фиксации, извлечения и отправки. В подмодуле возможно все.
Добавление подмодуля
Возьмем классический пример и предположим, что мы хотим добавить в наш проект стороннюю библиотеку. Прежде чем мы перейдем к какому-либо коду, имеет смысл создать отдельную папку, в которой такие вещи могут иметь дом:
Теперь мы готовы добавить сторонний код в наш проект — но упорядоченно, используя подмодули. Допустим, нам нужна небольшая библиотека JavaScript для преобразования часовых поясов:
Когда мы запускаем эту команду, Git начинает клонировать репозиторий в наш проект в виде подмодуля:
И если мы посмотрим на нашу папку с рабочей копией, мы увидим, что файлы библиотеки действительно прибыли в наш проект.
Посмотрим, что еще произошло:.gitmodulesв корневой папке нашего основного проекта был создан новый файл. Вот что он содержит:
Этот.gitmodulesфайл — одно из нескольких мест, где Git отслеживает подмодули в нашем проекте. Другой.git/config, который теперь заканчивается так:
И, наконец, Git также хранит копию.gitрепозитория каждого подмодуля во внутренней.git/modulesпапке.
Все это технические детали, которые вам не нужно запоминать. Однако это, вероятно, поможет вам понять, что внутреннее обслуживание подмодулей Git довольно сложно. Вот почему важно убрать одну вещь: не связывайтесь с настройкой подмодуля Git вручную! Если вы хотите переместить, удалить или иным образом манипулировать подмодулем, сделайте себе одолжение и не пытайтесь сделать это вручную. Либо используйте соответствующие команды Git, либо графический интерфейс рабочего стола для Git, например «Tower», который позаботится об этих деталях за вас.
Давайте посмотрим на статус нашего основного проекта, теперь, когда мы добавили подмодуль:
Как видите, Git рассматривает добавление подмодуля как изменение, как и любые другие. Соответственно, мы должны зафиксировать это изменение, как любое другое:
Клонирование проекта с помощью подмодулей Git
В нашем примере выше мы добавили новый подмодуль в существующий репозиторий Git. Но как насчет «наоборот», когда вы клонируете репозиторий, который уже содержит подмодули?
Если бы мы выполнили обычную операцию git clone в командной строке, мы бы загрузили основной проект — но мы обнаружили бы, что любая папка подмодуля пуста! Это еще раз является ярким доказательством того, что файлы подмодулей разделены и не включены в их родительские репозитории.
В таком случае, чтобы заполнить подмодули после клонирования их родительского репозитория, вы можете просто выполнить их git submodule update —init —recursiveвпоследствии. Еще лучший способ — просто добавить —recurse-submodulesопцию сразу при звонке git clone.
Проверка исправлений
В подмодуле мы всегда проверяем конкретную ревизию, а не ветку! Даже когда вы выполняете команду, например, git checkout mainв подмодуле, в фоновом режиме, отмечается последняя на данный момент фиксация в этой ветке, а не сама ветка.
Такое поведение, конечно, не ошибка. Подумайте об этом: когда вы включаете стороннюю библиотеку, вы хотите иметь полный контроль над тем, какой именно код используется в вашем основном проекте. Когда сопровождающий библиотеки выпускает новую версию, это хорошо… но вы не обязательно хотите, чтобы эта новая версия автоматически использовалась в вашем проекте. Просто потому, что вы не знаете, могут ли эти новые изменения сломать ваш проект!
Если вы хотите узнать, какую ревизию используют ваши подмодули, вы можете запросить эту информацию в своем основном проекте:
Это возвращает текущую проверенную ревизию нашего lib/spacetimeподмодуля. И это также позволяет нам узнать, что эта ревизия является тегом с именем «6.16.3». При работе с подмодулями в Git довольно часто используются теги.
Допустим, вы хотели, чтобы ваш подмодуль использовал более старую версию, которая была помечена как «6.14.0». Во-первых, мы должны изменить каталоги, чтобы наша команда Git выполнялась в контексте подмодуля, а не нашего основного проекта. Затем мы можем просто запустить git checkoutс именем тега:
Если мы теперь вернемся к нашему основному проекту и выполним его git submodule statusснова, мы увидим отражение нашей проверки:
Однако внимательно посмотрите на вывод: маленький +символ перед этим хешем SHA-1 говорит нам, что подмодуль имеет другую ревизию, чем в настоящее время хранится в родительском репозитории. Поскольку мы только что изменили проверенную ревизию, это выглядит правильно.
Звонок git statusв наш основной проект теперь тоже сообщает нам об этом факте:
Вы можете видеть, что Git рассматривает перемещение указателя подмодуля как изменение, как и любое другое: мы должны зафиксировать его в репозитории, если хотим, чтобы он был сохранен:
Обновление подмодуля Git
На приведенных выше шагах мы переместили указатель подмодуля: именно мы решили проверить другую ревизию, зафиксировать ее и отправить в удаленный репозиторий нашей команды. Но что, если кто-то из наших коллег изменит ревизию подмодуля — может быть, потому, что была выпущена интересная новая версия подмодуля, и наш коллега решил использовать это в нашем проекте (после тщательного тестирования, конечно…).
Давайте сделаем простой git pullв нашем основном проекте — как мы, вероятно, будем делать довольно часто в любом случае — чтобы получить новые изменения из общего удаленного репозитория:
Вторая предпоследняя строка указывает на то, что что-то в нашем подмодуле было изменено. Но давайте посмотрим внимательнее:
Я уверен, что вы помните этот маленький +знак: это означает, что указатель подмодуля был перемещен! Чтобы обновить нашу локально проверенную ревизию до «официальной», которую выбрал наш товарищ по команде, мы можем запустить updateкоманду:
Хорошо! Наш подмодуль теперь проверен в ревизии, записанной в нашем основном репозитории проекта!
Работа с подмодулями в Git
Мы рассмотрели основные строительные блоки работы с подмодулями Git. Остальные рабочие процессы действительно вполне стандартные!
Например, проверка наличия новых изменений в подмодуле работает так же, как и в любом другом репозитории Git: вы запускаете git fetchкоманду внутри репозитория подмодуля, за которой, возможно, следует что-то вроде того, git pull origin mainесли вы действительно хотите использовать обновления.
Внесение изменений в подмодуль также может быть для вас вариантом использования, особенно если вы сами управляете кодом библиотеки (потому что это внутренняя библиотека, а не сторонняя). Вы можете работать с подмодулем, как с любым другим репозиторием Git: вы можете вносить изменения, фиксировать их, отправлять их и т.д.
Использование всей мощи Git
Под капотом Git скрывается огромная мощь. Но многие из его продвинутых инструментов, таких как подмодули Git, малоизвестны. Очень жаль, что так много разработчиков упускают из виду много мощных вещей!
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
| adds a new submodule to an existing Git repository and defines that the master branch should be tracked |
| initialize submodule configuration |
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.
| adds a submodule to the existing Git repository |
| initialize submodule configuration |
3.3. Updating which commit your 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:
Подмодули
Часто при работе над одним проектом, возникает необходимость использовать в нем другой проект. Возможно, это библиотека, разрабатываемая сторонними разработчиками или вами, но в рамках отдельного проекта, и используемая в нескольких других проектах. Типичная проблема, возникающая при этом — вы хотите продолжать работать с двумя проектами по отдельности, но при этом использовать один из них в другом.
Приведём пример. Предположим, вы разрабатываете веб-сайт и создаёте ленту в формате 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 из индекса. Затем можно добавить подмодуль:
Предположим, что вы сделали это в какой-то ветке. Если вы попробуете переключиться обратно на ветку, в которой эти файлы всё ещё являются частью основного проекта, то вы получите ошибку:
Все эти инструменты делают подмодули довольно простым и эффективным методом работы одновременно над несколькими тесно связанными, но разделёнными проектами.
