Насколько глубоко разделен большой проект в разных хранилищах?

Недавно я перенес репозиторий Subversion в Git. Все прошло хорошо. Я использовал философию git для создания отдельных репозиториев каждого модуля программного обеспечения. Но теперь разработчики говорят мне, что они часто выполняют работу, которая меняет что-то в главном приложении и одном из модулей, что делает две коммиты, где было бы целесообразно сделать это в одном коммите. Это говорит мне, что модули на самом деле не отделены от основного приложения. Таким образом, один большой репозиторий будет иметь смысл. С другой стороны, наш основной продукт является открытым исходным кодом и некоторыми модулями, и мы синхронизируем эти репозитории с Github и Sourceforge. Но есть также несколько закрытых исходных модулей, которые действительно не должны выходить за пределы. Поэтому они должны быть в отдельном репо в нашей внутренней Гитлабе.

Они просят меня создать два больших (svn-style) репозитория: один для открытого кода и один для закрытого источника. Я, с другой стороны (QA и управление выпуском), чувствую, что это связано с тем, как разные части взаимодействуют и как вы ничего не можете изменить в одном месте, не изменяя что-то еще в другом месте. Но я не являюсь разработчиком на полный рабочий день, и я не углублялся в глубину этой конкретной базы кода.

Другой аргумент: программное обеспечение существует в Java и C #. Java-версия была ранее построена из svn в разных заданиях Jenkins, по одному для каждого модуля (так что разделение git-репозиций было совершенным с точки зрения CI), а версия C # построена в одной большой задаче TeamCity (придается одна большая, svn-стиль репо).

Я знаю, что общая практика git состоит в том, чтобы разделить вещи, но насколько глубоко вы должны разделиться?

Solutions Collecting From Web of "Насколько глубоко разделен большой проект в разных хранилищах?"

Это зависит от того, сколько независимых модулей у вас есть, сколько из них часто перемещаются вместе. В нашей команде у нас было 4 различных модуля java (которые перемещались независимо), база кода C #, библиотека модулей perl, артефакты баз данных и набор сценариев оболочки.

Наша кодовая база существует уже 4-5 лет, что приводит к большому количеству кода, фиксации и неиспользуемых филиалов. Несмотря на то, что git работает быстро и имеет много инженерных решений для крупных репозиториев, по прошествии некоторого времени нездорово иметь так много трещин в VCS (git / svn /) по тем или иным причинам. Кроме того, если у нас есть независимые репозитории, их легче объединить, а также перезагружать каждый раз, когда разработчик помещает репозиторий (это происходит нечасто), не затрагивая другие репозитории.

Кроме того, у нас была аналогичная зависимость между нашим C # и java-интерфейсом API, где бывали моменты, когда необходимо было совершать коммиты в обоих репозиториях, но мы подсчитали, что количество отдельных коммитов на уровне API или C # было гораздо больше, чем скоординировано, поэтому переход к нескольким репозициям имел смысл для нас. Это также помогло, чтобы все наши модули не были тесно связаны и имели здравые внутренние системы управления версиями, которые помогают нам поддерживать их в архитектуре микросервисов.

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