How to organize shared code/assets across projects with git repositories
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)
javasrc/core
s开发者_如何学Pythonrc/projectA specific folders
web
templates
css
javascript
images
projectA specific folders
Project B (based on the base)
javasrc/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 base
branch and a branch for each subproject sounds reasonable.
Then you can checkout base
and cherry-pick
the commits you need to incorpore from your subproject (constraint e).
Your constraints definitely fit the model of forking a project, so you could treat both ProjectA and ProjectB as forks from Base. What I mean is, essentially, the derived projects are modifying the original and adding some new files. The fact that the new files are in a separate directory doesn't matter much, because you need to modify the repository that comes from Base.
Whether having three repositories, two of which are bound to a third by an external "fork policy" is any better than your current solution of keeping three branches that are perpetually kept in sync is open to discussion of course, but I think looking at open source forked projects and how they handle the two-way code merging with their origin is something worth a little bit of research time. Unfortunately, it is an area that I have no prior experience.
精彩评论