Git repos and working with multiple remotes

Question

We are using git (Gitlab) on an in house dev server for work.

We have a project that often acts as the base for a number of other projects.

As a basic example, we'll take a base code (login, sessions, tracking events, etc) and add in event specific code to better cater to the needs of that particular event. Each event is its own deployment and has its own space on the server.

What is the preferred strategy for dealing with code bases like this?

I see two options:

Option 1 Branching - for each deployment, clone the base repo down, switch to an event specific branch, and then merge in base code wide changes (refactoring of base code, etc) to the branch whenever necessary.

This seems fine, but a bit messy (what about when there are 200 events?). Someone wanting to work on the base code ends up pulling in code for a ton of events at once. These events often come with images, movies, sound files, which can be quite expensive resource wise.

Option 2 Separate repos: For each deployment, clone the repo, push the event specific code to it's own repo, and pull the origin (base code) as needed to merge in changes.

I prefer the idea of number two - browsing the repo will be cleaner and easier. My activity screen won't be a mess of every event and the commits to it.

It is also worth mentioning that every event will most likely have at least a development and production branch.

Are there already established practices for this scenario?

Are there other/better options?

If there is any more information I can provide, or specifics that would better explain this situation, please ask.

Thanks.

Answer 1

Your option 2 makes sense.

It's akin to forking: your base project is "upstream", the dependent projects are derivatives of it, going in different directions independently, "downstream". Like Ubuntu is the base (upstream), from which Kubuntu, Xubuntu and Edubuntu are derived (downstream). Much development goes into the base and gets merged downstream, while some specific development goes into derivatives only, independent from one another.

It's great when there is such clean setup where downstream repos can get changes from upstream through VCS operations, and it's not always the case in real life. It works like this in the Ubuntu example, but Ubuntu itself is derived from Debian, and I don't think there is a connection at the VCS level there.

Answer 2

Your option 2 sounds fine. This is exactly what you would call a fork on github.

Do you really need to change the base code for each event? Maybe an even cleaner option is turning your base into a library and make each event only use that library instead of including the whole code. - But depending on your language and current setup this might be a bit of work...