Публикация определенных путей частного репозитория git

109
15

Я работаю с командой из ~ 10 разработчиков в частном репозитории gitlab, который содержит следующие проекты:

сервер искусственный интеллект клиент Интерфейс Разное (Протоколы, PR-материалы и т.д.)

Каждый из которых, помимо Misc, имеет свои собственные зависимости Maven и модульные тесты, содержащиеся в их конкретной папке.

Мы используем git-flow, так что все ветки будут объединены с одной develop отрасль в какой - то момент.

Вопрос:

В настоящее время мы только продаем клиента & интерфейс с источником и хотели бы, чтобы предоставить нашим клиентам доступ только к этим (sub-) проектов, в том числе их истории, в то же время иметь возможность легко передавать обновления, а также используя gitlab issues функциональность.

Идеи, которые у меня были:

Если бы это было публичное репо, я бы просто использовал git submodules, но это решение не работает безупречно с частными репозиториями. (Если вообще - много читали о проблемах с неверными путями) Если бы у меня были суперчистые ветки для Client и Interface, я мог бы добавить еще один новый remote репозиторий и просто подтолкнуть эти два ветки к нему. Проблема с этим решением состоит в том, что у нас есть неопытные разработчики на борту, и один грязный толчок или один толчок от develop ветки в основном сделает эту идею бесполезной. Риск слишком высок. Еще одна идея, которую я перенесла, заключалась в переносе этих 2 sub- проектов из частного репо, создавая подмодули внутри частного репо. Что-то также чувствует себя довольно неудобно, потому что наша continuous integration будет работать в другом репо, а также будут отслеживаться наши собственные проблемы.

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

спросил(а) 2021-01-25T16:05:17+03:00 4 месяца, 4 недели назад
1
Решение
109

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

Это решение также публикует git-историю вашего проекта. В зависимости от того, насколько тщательно ваша команда работала заранее, вы можете отфильтровать ее, хотя: Git Documentation о том, как это сделать. Вы должны выполнить этот шаг после очистки ветки (ов).

Идея этого решения состоит в том, чтобы...

Создавайте суперчистые ветки, включая только каталоги для развертывания Затем потянув эти ветки в новый репозиторий Control-Step, чтобы проверить, являются ли ветки чистыми и готовы к развертыванию развертывание

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

Шаги для выполнения в private local repository:

# Assure we are on the latest stable state within our main repo
git checkout <CURRENT_STATE>

# Create a new deployment branch from HEAD
git branch <DEPLOYMENT_BRANCH> HEAD

# Enter the new branch
git checkout <DEPLOYMENT_BRANCH>

[Вариант 1]: если вы намерены удалить структуру пути каталога и развернуть все файлы в корневой каталог вашего нового репозитория, используйте следующую стратегию

# Filter every comment outside of this subdirectory (execute from root directory of repo)
git filter-branch -f --subdirectory-filter <DIRECTORY_PATH> -- <DEPLOYMENT_BRANCH>

[Вариант 2]: Фильтровать и сохранить дерево каталогов

##
# Force filter-branch using the tree-filter (keeps the
# directory-structure) while deleting all files outside
# this directory (Check if you are on <DEPLOYMENT_BRANCH>
# first). Folders are kept, but since Git does not push
# empty folders this is no problem

git filter-branch --tree-filter -f \
'find . -path <DIRECTORY_PATH> -prune -o -type f -print0 | xargs -0 rm -f' \
--prune-empty HEAD

Мы хотели бы добавить master файл .gitignore.

# Take master .gitignore and add it to the branch
git checkout master -- .gitignore

Вы также должны обновить его, чтобы игнорировать все остальные каталоги, но ваш <DIRECTORY_PATH>:

##
# In .gitignore:
# Ignore everything:
*

# Except for these directories:

!path/
!path/*/
!.gitignore

Этап и зафиксировать эти изменения:

git add .gitignore
git commit -m "Add .gitignore"

Сообщите своим коллегам-разработчикам отслеживать новую ветку в своих private local repositories:

##
# If you would pull this branch, Git would attempt a merge it into your current HEAD.
# Do NOT pull! Instead start tracking the remote branch

git checkout --track origin/<DEPLOYMENT_BRANCH>

Шаги для выполнения в новом destination/deployment repository

Клонировать или создать destination/deployment repository. Внутри него добавьте удаленный доступ к нашему private local repository и потяните/объедините ветки в мастер:

# Add remote to local private repo
git remote add local <PATH/TO/PRIVATE/REPO/.git>

git checkout master

[Вариант 1]: вытащить и, следовательно, слить изменения непосредственно в мастер

# Pull changes from private repo and allow unrelated histories

git pull local <DEPLOYMENT_BRANCH> --allow-unrelated-histories

[Вариант 2]: Отслеживание ветвей без мгновенного слияния

# Track branches for more granular control
git checkout --track local/<DEPLOYMENT_BRANCH>

Развертывание:

# Deploy option 1: (For option 2 simply push your tracked branches)
git push origin master

ответил(а) 2021-01-25T16:05:17+03:00 4 месяца, 4 недели назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема