开发者

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)

java

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 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.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜