2

I developed a general application, because I need to create some very similar app. I tried to separate the differences, so I have a settings.xml. But it’s not enough because sometimes I need to change the code in a version, but I really want to have a same codebase for every app.

I want to reach my main goal, so if I develop the same codebase, then all app version is upgraded. But I have difficulties to handle the differences.

I need your suggestions, how should I handle this in git. Should I create a brach for every app version? How should I handle the different things (app name, icon, package name, settings.xml, maybe different code parts) and still be able to develop the same codebase and upgrade every app version.

Maybe a buildserver script can handle some file replace, but it can't handle the different code versions.

Is there someone with the same problem? Maybe a working solution?

user2313423
  • 745
  • 3
  • 7
  • 12

1 Answers1

1

For a common code base, with few different files, one app per branch is the recommended approach (much simpler than submodules).

You can see an example at "Multiple Django sites with shared codebase and DB".

The problem with this approach is to prevent any merge from the app branch to master (you should only merge from master to app).
A pre-commit hook can help.
And you can protect your specific files with a .gitattributes in the app branch.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @user2313423 any good experience with `git submodules` or did you find something else that worked better meanwhile? – Norfeldt Jul 27 '18 at 18:33