Розробка · 18 червня 2014, 10:29 1497

Олександр Костюк, DevOps в Innovecs

Проект в гит

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

Теми: git, GitLab, SVN

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Нестор Иванович 20.06.2014 13:18

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

Відповісти

Підтримати

Олександр Костюк DevOps в Innovecs 19.06.2014 17:38

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

Відповісти

Підтримати

Iryna Volkodav engineer в e-commerce startup 19.06.2014 17:48

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

Відповісти

Підтримати

Олександр Костюк

Олександр Костюк DevOps в Innovecs 19.06.2014 17:56

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

Відповісти

Підтримати

Vladyslav Kurmaz Looking for Solution Architect, Engineering Manager, CTO position 19.06.2014 22:55

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

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

Відповісти

Підтримати

Олександр Костюк

Олександр Костюк DevOps в Innovecs 20.06.2014 13:13

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

Відповісти

Підтримати

Vladyslav Kurmaz

Vladyslav Kurmaz Looking for Solution Architect, Engineering Manager, CTO position 20.06.2014 14:00

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

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

Відповісти

Підтримати

Олександр Костюк

Олександр Костюк DevOps в Innovecs 20.06.2014 14:08

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

Відповісти

Підтримати

Vladyslav Kurmaz

Iryna Volkodav engineer в e-commerce startup 18.06.2014 13:08

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

Відповісти

Підтримати

Олександр Костюк DevOps в Innovecs 18.06.2014 13:24

да, было бы интиресно

Відповісти

Підтримати

Iryna Volkodav engineer в e-commerce startup 18.06.2014 13:29

Выдержка из 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.

Відповісти

Підтримати

Олександр Костюк DevOps в Innovecs 18.06.2014 13:34

спасибо

Відповісти

Підтримати

Iryna Volkodav engineer в e-commerce startup 18.06.2014 13:43

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

Відповісти

Підтримати

Олександр Костюк

Vladyslav Kurmaz Looking for Solution Architect, Engineering Manager, CTO position 18.06.2014 13:55

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

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

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

Відповісти

Підтримати

Олександр Костюк

Олександр Костюк DevOps в Innovecs 18.06.2014 14:10

спасибо еще раз)

Відповісти

Підтримати

Vladyslav Kurmaz

Gabriel Angelos 18.06.2014 11:44

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

Відповісти

Підтримати

Олександр Костюк DevOps в Innovecs 18.06.2014 11:59

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

Відповісти

Підтримати

Gabriel Angelos

Java Adept 18.06.2014 17:22

github-а будет недостаточно

Для маленьких комманд достаточно вполне. У гитхаба даже свой CI есть, правда платный
travis-ci.com/plans

Відповісти

Підтримати

Gabriel Angelos

Олександр Костюк DevOps в Innovecs 18.06.2014 17:59

так gitLAB будем юзать, а не gitHUB

Відповісти

Підтримати

Java Adept 18.06.2014 18:18

github.com/...labhq/gitlab-ci

Відповісти

Підтримати

Олександр Костюк

Galip Oslon 18.06.2014 11:04

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

для каждого проекта нужно создавать отдельный репозиторий в гите — тоесть на один проект должен быть один git clone. Если хочеш вытягивать несколько взаимосвязаных проектов одновременно — пользуйся repo — это набор скриптов от линуса

Відповісти

Підтримати

Олександр Костюк DevOps в Innovecs 18.06.2014 11:06

для каждого проекта нужно создавать отдельный репозиторий в гите

неужели по-другому никак нельзя?

Відповісти

Підтримати

Galip Oslon 18.06.2014 12:28

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

Відповісти

Підтримати

Олександр Костюк

Олександр Костюк DevOps в Innovecs 18.06.2014 12:43

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

Відповісти

Підтримати

Vladyslav Kurmaz Looking for Solution Architect, Engineering Manager, CTO position 18.06.2014 12:51

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

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

Відповісти

Підтримати

Олександр Костюк DevOps в Innovecs 18.06.2014 13:23

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

Відповісти

Підтримати

Vladyslav Kurmaz

Oleg Okunevych Ruby Engineer в Self employed 18.06.2014 12:52

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

Відповісти

Підтримати

Олександр Костюк

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

Ваша пошта

Не підписуватись