Проект в гит

В общем есть проект в svn. Нужно перенести его в гит. Проблема не в переносе, а в том, как реализовать структуру. Нужно приблизительно следующее: все файлы и папки с которыми будут работать разработчики лежали в одном репозитории, в нем было несколько проектов, причем некоторые файлы и папки могут быть в разных проектах и изменение в одном, были видны в другом проекте(сабмодули не подходят ибо будет очень много репозиториев). Разработчики получают бранч с определенного проекта и работают с ним. Все это нужно админить через gitlab. Подскажите пожалуйста как это все реализовать.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

у меня такое странное впечатление что у вас методом разделения на 100500 проектов решается проблема не желания наладить управление зависимостями как то по другому.

И вот тут снова проблема(( Поддержки submodules & subtree нет в Gitlab. Увы((

Ну может кто-то сможет ответить и по остальным возможным вариантам решения проблемы. Может не стоит зацикливаться на Gitlab’е в таком случае? Например тут по ссылке Tale of three Git systems проводят сравнение 3х инструментов под Git...

Да дело в лом что уже гитлаб поставил и настроил( ох, как же с нуля все сложно дается)

А какой функционал ожидал увидеть?

Я Gitlab не разворачивал, а просто поднимал git на сервере.
В двух словах: submodules — .gitmodules в корне, папки по одной на каждый внешний репозиторий, плюс при вытягивании версии добавляется одна команда
git pull <remote> <branch>
git submodule update
но и их можно связать в одну команду.
Тоесть атомарность git репозитория с позиции Gitlab остаётся.

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

Да все правильно, submodule это просто связь одного репозитория с определённым комитом другого. Другими словами
repo1
repo2
repo3
main-repo
— .gitmodules
-\ repo1: link to the repo1
-\ repo2: link to the repo2

тоесть repo1, repo2, repo3, main-repo — полнофукциональные git репозитории со своими бранчами, тегами и ремоутами. И они все будут у тебя на одном уровне в GitLab.

Вот только почему-то в с main-repo при переходе на сабмодуль «404 The page you were looking for doesn’t exist.» Пытался играть с линками в .gitmodules, пока не помогло.
Я не знаю почему, но уже работает)

Ребята, а как насчёт Alternatives To Git Submodule: Git Subtree? Есть ли у кого опыт с этим решением?

Выдержка из Why your company shouldn’t use Git submodules по этому решению (на Git Subtree):


The upside is that you avoid all the issues with submodule merging because the contents of your subprojects are stored directly in the parent repository and thus are treated like any other tracked files when pulling and merging.


The downside is that all of your subproject files are present in the parent repository, which means you’re giving up some of the reason for originally splitting up your project repositories: having one canonical repository for a given set of shared code. If someone makes a change to a subproject, they can merge it with other changes locally, but they’d have to explicitly split that change back out of their project if they wanted to share it with projects.

Да незачто, Саша. Если бы был у меня реальный опыт с этим, то помогла бы больше, но увы, только теоретически рассуждать могу после прочтенных Why your company shouldn’t use Git submodules, Git Submodules: Core Concept, Workflows And Tips, Alternatives To Git Submodule: Git Subtree статей... Самой было бы интересно услышать человека с реальным практическим опытом...

Внизу написал, но повторюсь. Вне зависимости на чём остановитесь submodules\subtree\custom wheels, сделаёте рабочие прототипы. Такая миграция осуществляется пару раз в жизни, так что в данном случае: лучше день потерять, потом за пять минут долететь.

IMHO: subtree очень близко к тому, от чего я убежал из SVN-а, branch -> полная копия файловой структуры.

Ну и как всегда «Diamond solution» здесь нет (

github-а будет недостаточно, вам нужно несколько репозиториев и сервер CI:
1) центральный репозиторий, изменения, которого будет подтягиваться в другие
2) собственно другие репозитории
3) CI-сервер, например Jenkins, который по хуку на центральном репе будет подтягивать изменения и мёржить их в другие репы, скорее всего несколько Jenkins-job-ов
При мёржах обязательно будут конфликты и проблемы гита — надо будет мёржить вручную.
Скажу по-секрету — геморрой еще тот.

а разве gitlab не умеет мержить? Ну не автоматом конечно, но пару кнопок нажать не так трудно. Ибо ставить еще и jenkins ой как не хочется(

github-а будет недостаточно
Для маленьких комманд достаточно вполне. У гитхаба даже свой CI есть, правда платный
travis-ci.com/plans
все файлы и папки с которыми будут работать разработчики лежали в одном репозитории, в нем было несколько проекто
для каждого проекта нужно создавать отдельный репозиторий в гите — тоесть на один проект должен быть один git clone. Если хочеш вытягивать несколько взаимосвязаных проектов одновременно — пользуйся repo — это набор скриптов от линуса
для каждого проекта нужно создавать отдельный репозиторий в гите
неужели по-другому никак нельзя?

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

ну проекты взаимосвязаны, бренч может включать в себя несколько проектов. Так хочет мой начальник)

Поддержу, по предоставленной инфе в топике — без submodules не обойтись.
Но перед тем как принимать окончательное решение, сделайте маленький тест структуры:
* определитесь сколько у вас будет репозиториев, как они буду взаимосвязаны
* сделайте тестове репозитории (по одно файлу в каждом) и свяжите их вместе, а после отработайте все ваши рабочие схемы: новый сотрудник, новый проект, новая версия, хот фикс, ночная сборка и т.д и т.л.
* принимайте окончательное решение

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

спасибо, буду убеждать начальника что несколько репозиториев это хорошо и будем юзать сабмодули.

submodules и под каждый проект отдельный репо

Подписаться на комментарии