Вы, вероятно, застряли в совместном использовании повторно используемых компонентов через модули вашего проекта. Если npm делает это, мне потребовалось много времени, чтобы поделиться базой кода между модулями. Итак, у git есть ответ: git submodules.

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

Думаю, вы знаете, что git - это распределенная система управления версиями с исходными кодами, на которой установлены origin и local. Таким образом, origin может быть либо bitbucket, либо github, либо любым другим. Затем он спускается в хранилище. Итак, что означает этот репозиторий? Это виртуальный код, основанный на URL-адресе. Представьте, что это папка где-то в облаке. Итак, чтобы идентифицировать и иметь имя и адрес (URL).

Подождите, а где эти подмодули? Просто подумайте, что если у этого репозитория есть репозиторий в детстве. А? Например, папка внутри папки является дочерней по отношению к родительской папке. Все просто, правда?

Это то, что он называется подмодулем. Bellow содержит ваш основной код репозитория на основе.

Затем субмодули внутри /src

Итак, как вам добавить подмодуль в свой проект?

git submdoule add -b developer [email protected]:<YourCompanyWorkspace>/us.icons.git

Об этом заботится родительский репозиторий?

да. Конфигурации дочерних модулей хранятся в .gitmodules файле в корне репозитория.

Здесь вы видите, что вы можете настроить каждый модуль по

  1. путь: где вы хотите клонировать модуль
  2. url: исходный URL (bitbucket, github или где угодно)
  3. ветка: ветвь по умолчанию для обновлений pull и push из источника

Также и другие конфигурации.

Хорошо, тогда как вы push и извлекаете изменения из модуля?

давайте перейдем к us.style подмодулю.

Измените свой каталог с помощью cd src/us.styles

Затем используйте

git add -a

git commit -m '<COMMIT_MESSAGE>' и

git push origin <BRANCH>

Все просто, правда?

Так что правильно.

Итак, как это воспринимается другим соавтором?

Есть два пути.

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

git submodule update --remote

Это позволит получить все обновления субмодулей до последней фиксации самостоятельно.

or

git submodule update

Но при этом будут обновлены все подмодули, относящиеся к основному репозиторию.

В чем разница?

Чтобы собрать проект через CI или поделиться определенной версией (тегом) родительского репозитория, вам необходимо прикрепить к нему стабильную фиксацию. Причина в том, что подмодули независимо хранят свою собственную историю git. Вы найдете папку .git внутри каждой папки подмодуля. Поэтому при публикации репозитория вам необходимо прикрепить последние коммиты или конкретный коммит / ветку к родительскому репозиторию.

Какие еще преимущества вы получаете при использовании концепции модуля git?

  1. Ограничьте уровни доступа участников. Для определенных модулей вы можете установить доступ только для чтения для некоторых участников и написать доступ или некоторые другие.
  2. Минимальные конфликты кода. Поскольку каждый подмодуль хранит свою собственную историю git, участники могут легко работать вместе без конфликтующего кода на основе
  3. Поддержка Visual Code из коробки

Вы можете push pull checkout fetch и многие другие, используя Visual Code.

Поддерживает ли это CI?

да. Подмодуль поддержки AWS, Azure, Jenkins из коробки.

Big Smile :) Спасибо git и разработчикам за эту замечательную функцию.

Подробнее читайте в оригинальной статье.

Спасибо за чтение, и я надеюсь, что вам понравилась эта статья. Не забывайте читать предстоящие статьи.