Подмодули, поддеревья или что-то еще для зависимостей в Git?

#git #dependencies #workflow

#git #зависимости #рабочий процесс

Вопрос:

У меня ситуация с более крупным проектом, в котором много модулей / библиотек с их соответствующими репозиториями. Большинство этих модулей являются зависимостями других модулей, которые не являются зависимостями проекта. И теперь дошло до того, что основной проект имеет несколько подпроектов, и многие модули являются общими. Некоторые зависимости имеют глубину более 3-4 уровней.

Я читал, что можно обновлять / извлекать подмодули внутри проекта, но это работает только для подмодулей 1-го уровня. Допустим, что эти подмодули имеют свои собственные подмодули (2-го уровня) и что некоторые подмодули 1-го уровня используют одни и те же подмодули 2-го уровня. Кроме того, подмодули 2-го уровня имеют свои подмодули (lvl3) и т.д. Теперь, что я должен сделать, это сначала внести изменения, внесенные на 3-м уровне, затем обновить подмодули в модулях 2-го уровня и нажать их, теперь я могу перейти на 1-й уровень, обновить и нажать, и, наконец, обновить подмодули моего проекта и нажать их.

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

Что я могу с этим поделать? Может быть, какие-то советы по поводу рабочего процесса, кто-нибудь еще сталкивался с этой проблемой или есть какая-то функция в Git, которая решает эту проблему.

Комментарии:

1. Должно ли ваше решение работать и в Windows?

2. На данный момент нет, у вас есть какой-нибудь совет?

Ответ №1:

Я бы порекомендовал инструмент repo, который использует Android. Он достаточно общий для работы с любой средой хостинга git и не требует коммитов суперпроекта для обновления подпроектов, как это делают подмодули.

Сначала установите клиент, как описано здесь: https://source.android.com/source/downloading.html#installing-repo

Затем создайте репозиторий манифеста. Манифест — это XML-файл, который описывает местоположения репозитория git и пути, по которым они должны быть проверены. Вот так:

 mkdir manifests
cd manifests
git init
  

Создайте файл манифеста default.xml :

 <?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <remote name="github" fetch="ssh://git@github.com" />
  <default remote="github" revision="master" />
  <project name="git/git.git" path="git" />
  <project name="libgit2/libgit2.git" path="vendor/libgit2" />
</manifest>
  

Затем добавьте, зафиксируйте манифест и нажмите куда-нибудь:

 git add default.xml
git commit -m "My first try at a manifest file"
git push git@github.com:myusername/manifests.git master
  

Теперь вы готовы использовать эту repo команду.

 mkdir myproject
cd myproject
repo init -u git@github.com:myusername/manifests.git
repo sync -j2
  

Ваши репозитории git будут клонированы. Теперь вы можете работать в каждом из них, как обычно. После того, как вы перейдете к любому из проектов, все, что кому-либо еще нужно сделать, это a repo sync , и они будут обновлены до последней версии (см. Также repo start ).

Предостережения

Возможно, вам придется реорганизовать свой проект. Обычно у вас могут быть другие модули в виде подкаталогов ( myproject/vendor/dependency ). Хотя вы все еще можете поддерживать этот макет с помощью repo, это приведет к извлечению репозитория git с помощью другого репозитория. С .gitignore помощью хитрости это может быть выполнимо, но я бы рекомендовал реорганизовать ваш проект, чтобы репозитории не нужно было проверять друг в друге.

Краткое объяснение файлов манифеста

Видишь https://gerrit.googlesource.com/git-repo/ /master/docs/manifest-format.txt для получения полного объяснения каждого элемента в XML-файле.

Видишь https://source.android.com/source/using-repo.html для простой ссылки на команду. repo help также очень полезно. Примечание: вы должны игнорировать repo upload , если вы не используете Gerrit.

<remote name="github" fetch="ssh://git@github.com" />

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

<default remote="github" revision="master" />

Элемент default задает параметры по умолчанию для проектов. Это эквивалентно добавлению элементов remote и revision в каждый проект. Это просто экономит ввод текста.

<project name="git/git.git" path="git" />

Вот где происходит настоящая работа. repo sync примет имя и добавит его к удаленному с помощью косой черты. В этом случае по умолчанию используется удаленный github , поэтому он получит URL ssh://git@github.com/git/git.git . Он выполнит проверку проекта по пути git в указанной редакции (в данном случае по умолчанию master ). Последующие repo sync s будут проверять последнюю версию (в случае ветки).

Комментарии:

1. Я попробую и дам вам знать, как это происходит. Спасибо

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

3. repo manifest -r будет сделан снимок, который вы можете сохранить и использовать в будущем. Это удовлетворяет ваши потребности?

4. repo также поддерживает клонирование репозиториев git с подмодулями, так что вы можете комбинировать и сопоставлять, чтобы получить то, что вам нужно.