У нас есть несколько проектов, которые делятся большинством своих файлов кода / конфигурации. Фреймворк, который мы используем, имеет определенные зависимости каталогов и файлов, которые ограничивают нас в том, насколько мы можем отделить общий код. Например, между 'common', 'projectA' и 'projectB' у нас может быть:
/ Projecta
- / shared_dir1
- / common_dir2
- / dir3
- common3
- fileA4
/ projectB
- / shared_dir1
- / common_dir2
- / dir3
- common3
- fileB4
- fileB5
В настоящее время мы управляем этим с помощью 3 Git-проектов: 'common', 'projectA' и 'projectB', с общими файлами, разделенными на 'common', и файлами, специфичными для проекта, в их собственных проектах. 'projectA' и 'projectB' имеют .gitignore с записями для всех общих каталогов и всех общих файлов под каждым общим каталогом. Скрипт копирует «общий» в проект, в котором вы хотите работать, и разработка там завершена. После внесения изменений другой скрипт копирует все общие каталоги и общие файлы обратно в «общие». Изменения в «общем» и в проекте можно увидеть через «git status».
Это, очевидно, связано с головными болями: копировать туда-сюда между «обычными», сохранять точность .gitignore и переключать ветки внутри «projectA» и «projectB». Однако, поскольку мы планируем использовать 'projectC-F', этот подход кажется хорошим, поскольку мы можем избежать объединения общих изменений в N проектов.
Нужен совет о том, как лучше поддерживать этот тип структуры. Подмодули кажутся недопустимыми из-за отсутствия сегрегации, если мы не сделали большое их количество. Я видел несколько многообещающих альтернатив, использующих символические ссылки, но это также связано с проблемами. Любой совет будет оценен.