I have a scenario where the base project consists of java code and web site files (jsp/html/javascript, templates, css, images etc).
Variants of this base project are created for the following reasons:
a) white labelling + customization
b) A new project based on this project but additional features (both in java and web files)
Base project
java
- src/core
web
-
templates
-
css
-
javascript
-
images
Project A (based on the base)
java
-
src/core
-
src/projectA specific folders
web
-
templates
-
css
-
javascript
-
images
-
projectA specific folders
Project B (based on the base)
java
-
src/core
-
src/projectB specific folders
web
-
templates
-
css
-
javascript
-
images
-
projectB specific folders
Important constraints
a) Both projectA and projectB share quite a bit of code from base project
b) In addition to having their own files and code, ProjectA and ProjectB could add, modify or delete files in web/templates, web/css, web/image folders – for customization and white labelling
c) More projects like projectA and projectB could be created in the future
d) When base project is changed, it should be possible to have the changes reflected back in sub-projects
e) Occasionally, changes made in projectA/projectB to common files should be folded back into base project.
Initially, I thought I will have separate git repository for base project and each of Project A, B etc. But keeping particularly the above constraints in mind, It looks to me that both git subtree or submodule approaches do not work(for obvious limitations)
So, I am tending towards having a single repository and using “branching” approach where projectA and projectB will be branches and base will be the “master”. How well does constraint (e) work in this approach ?
Are there better ways of managing this in git ?
Your approach of having a
basebranch and a branch for each subproject sounds reasonable.Then you can checkout
baseandcherry-pickthe commits you need to incorpore from your subproject (constraint e).