#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 с подмодулями, так что вы можете комбинировать и сопоставлять, чтобы получить то, что вам нужно.