Параллельный контроль версий

Question

[Sergey Cherepanov]

Ситуация: Есть код, который включает в себя определенный набор компонентов, фреймверк, cms, модули для cms, шаблоны, и тд. Код часто пересекается и разделить его не всегда возможно.

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

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

Возможно есть какое то готовое решение?

Comments

[Sergey Cherepanov]

Основная задача частичный возврат обновленного кода в репозиторий первоисточник.

Answer 1

[Sergey Cherepanov]

Нашел решение github.com/colinmollenhour/modman, реализовывает практически то что я хотел)

Answer 2

[FunFun]

Я уверен, что вам поможет ветвление и создание меток.

Если вы используете git и еще не знакомы с ветвлением, то вот хорошая статья и так же про использование меток .

Если возникнут трудности, буду рад проконсультировать, пишите в личку.

Comments

[Sergey Cherepanov]

С ветками знаком поверхностно, помню пытался такое провернуть. Но после того как я слил к себе ветку в которой было в ходе разработки удаление файлов, нужных для второй ветки, и git удалил их. Мне показало это не то что мне нужно. Так же мне не совсем понятно, если в третей ветке я поменял логику и мне надо слить новый функционал который только под версией первой ветки. Как быть?

Если на пальцах: к примеру у нас отдельная ветка Image Gallery, мы ее + еще десаток таких веток сливаем в Master, разрабатываем проект, в ходе появляются новые функции у Image Gallery которые надо выгрузить обратно в ее ветку, но только файлы этого модуля.

За ссылки спасибо, почитаю.

Answer 3

[vsespb]

Может Вам не Version Control а Release management нужен… (тогда система управления версиями тут ни при чём)

Comments

[Sergey Cherepanov]

А можно подробнее? как бы там решалась моя задача.

[vsespb]

Управление релизами — Раз код пересекается, хранить в одном репозитории.

Иметь скрипты которые будут делать релизы отдельно каждого компонента. У них будут версии.

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

Т.е. одним словом — система управления версиями тут не причём.

Вообще из описания не на 100% понятно в чём именно задача.

[Sergey Cherepanov]

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

Совместимость компонентов не попадает в разрез задачи (как раз для этого вполне подошли бранчи и теги).

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

Answer 4

[ctacka]

Меня инетресует примерно то же, но для «гетерогенной» структуры репозиториев (svn+git). Можно использовать git submodules. Я правда не понял, что значит «общий корень» в вашем варианте. Мне кажется, что ваш вариант именно git submodules.

Comments

[Sergey Cherepanov]

Это значит что структура файлов и папок для всех репозиторие идентична, и один и тот же файл может одновременно присутствовать в нескольких репозиториях.

[ctacka]

А зачем тогда много репозиториев? Почему не сделать один с несколькими ветками?

[Sergey Cherepanov]

Потому что они независимые друг от друга, и их нельзя смешивать. На выходе надо иметь множество независимых проектов.

Точнее один большой + множество независимых.

[ctacka]

У вас есть множество мелких независимых репозиториев и один большой общий? Почему бы не подключать сабмодулями большой общий в мелкие?

[Sergey Cherepanov]

Хм, а можно как то подробнее?

Answer 5

[ctacka]

Не получится, я подумал. У вас же файлы в общем и мелком репозитории могут пересекаться.
По хорошем вам надо переворошить ваши репозитории, реорганизовать их. Иначе ждут всякие неприятности вас, боюсь.

Comments

[Sergey Cherepanov]

Да это все пока мысли по автоматизации того что есть, менять я ничего не могу.