проверить другие проекты с открытым исходным кодом - хорошая идея. Потратите некоторое время, чтобы посмотреть на некоторые из них.
я есть сценарий, из которого состоит базовый проект, код Java и файлы веб-сайта (jsp / html / javascript, шаблоны, CSS, изображения и т. Д.).
Варианты этого базового проекта созданы по следующим причинам:
а) белая маркировка + настройка
б) Новый проект, основанный на этом проекте, но с дополнительными функциями (как в Java, так и в веб-файлах)
Базовый проект
Ява
Web
шаблоны
CSS
Javascript
картинки
Проект А (на основе базы)
Ява
SRC / ядро
src / projectA определенные папки
Web
шаблоны
CSS
Javascript
картинки
ProjectA конкретные папки
Проект Б (на основе базы)
Ява
SRC / ядро
src / projectB определенные папки
Web
шаблоны
CSS
Javascript
картинки
специфичные для проекта папки
Важные ограничения
а) ProjectA и projectB совместно используют довольно много кода из базового проекта
b) В дополнение к собственным файлам и коду, ProjectA и ProjectB могут добавлять, изменять или удалять файлы в папках web / templates, web / css, web / image - для настройки и белой маркировки
c) В будущем может быть создано больше проектов, таких как projectA и projectB
d) Когда базовый проект изменяется, должна быть возможность отразить изменения обратно в подпроектах.
e) Иногда изменения, вносимые в projectA / projectB в общие файлы, следует возвращать в базовый проект.
Первоначально я думал, что у меня будет отдельный репозиторий git для базового проекта и каждого из проектов A, B и т. Д. Но, учитывая, в частности, вышеупомянутые ограничения, мне кажется, что подходы git поддерево или подмодуль не работают (для очевидных ограничений)
Итак, я склоняюсь к тому, чтобы иметь один репозиторий и использовать подход «ветвления», где projectA и projectB будут ветвями, а base будет «master». Насколько хорошо ограничение (е) работает в этом подходе?
Есть ли лучшие способы управления этим в git?