Я унаследовал огромную базу данных perl. Разработчики (мы - команда из 3 человек) в настоящее время выполняем «управление версиями» через резервные файлы (файл.001, файл.002 [...] и файл - это программная ссылка на самую последнюю версию). Я заработал задачу обеспечивая надлежащий контроль версий. Я выбираю git, поскольку он является наиболее гибким, и я хочу адаптировать nvie's git-flow branching strategy, поскольку он подходит именно так, как они работают здесь.организация git repo для огромного кода устаревшего кода
Моя проблема в том, что я не знаю, как правильно организовать репозиторий. У нас есть три справочника, где хранится наш код:
- Справочник для деамонов. Это содержит ~ 200 индивидуальных деамонов. 90% из них не имеют зависимости друг от друга. Deamons находятся между 4000-10.000 строк кода
- Каталог для инструментов. Инструменты содержат ~ 400 программ. Опять же, большинство из них не связаны
- Каталог с самописными модулями. Некоторые из них имеют зависимости от деамонов (например, при изменении интерфейса/подпрограммы модуля вам также необходимо изменить некоторые деамоны). Те, кто до ~ 150.
Дополнительно:
- Существует один каталог, в котором все конфигурационные-файлы находятся
- Там есть один каталог, в котором все testcases проживают
Я думал о создании репозитория Git для каждого этих каталогов.
Следующая проблема: Двое человек работают над двумя деамонами в ветке развития, один закончен, один по-прежнему занят, каждый из них совершил свои изменения. Теперь вы не можете объединить стабильные версии для мастеринга, так как вы также подталкиваете наполовину испеченную версию вместе с готовой. Насколько я знаю, его невозможно только нажимать на отдельные файлы.
Как правило, можно было бы организовать репозитории git для каждого проекта. В нашем случае это означало бы создание ~ 800 репозиториев, по одному для каждого деамона, по одному для каждого из наших инструментов, по одному для каждого модуля. У меня возникает ощущение, что это будет очень трудно справиться, хотя это как-то решит проблему слияния с хозяином.
Есть ли у кого-нибудь опыт с такими проблемами? Любые намеки? Я также ценю намек на хорошую книгу по этому вопросу.
Похоже, что вам не хватает ветвей функций. – simbabque
Есть ли у вас аргументы против помещения всего в один огромный архив, поэтому они привыкают к git (что обычно требует некоторого убеждения, хотя это не очень сложно)? Впоследствии вы можете подумать о следующих шагах. – simbabque
Я согласен с одним из комментариев @ simbabque - бросьте все в 1 репо, чтобы начать или, возможно, 3-5 репо, на основе каталогов, которые вы указали. На самом деле не имеет большого значения, что большинство файлов не связаны друг с другом. Вы не хотите 750 различных проектов/репо, тем более, что обращение к файлам в других проектах/репозиториях потребует использования подмодулей git, и это сложность, которую вам просто не нужно запускать. – jimtut