I have a Github project for a Django web-app that one team uses. Other teams are interested in also using it and they'll need separate instances of it (it's a stock tracking database so they need to not see each other's stock). It's also likely that they'll be small modifications that different teams will need.

For the different instances of the database, I can easily solve that by having a different database connection. However, I'm not sure of the best way to go about maintaining the different versions.

The project is currently on GitHub, as they'll all be based off the same original code would it make sense to manage the differences using GitHub branches, even if the intent is never to merge them? Or would it make more sense to just make different repositories to maintain the different versions?

  • 4
    Would it be possible to maintain the same codebase across all teams, but to enable or disable features using toggle switches? I personally would not recommend maintaining either multiple repositories or multiple branches of the same project. – Vincent Savard Mar 11 '20 at 13:22
  • Currently yes, as we're all on the same Local Network and I had thought about assigning a 'team' to each user and users can only see items from their team... But there is a possibility of some people external to our Network using this database so for that, I would need two versions of the code for separate deployments (allowing external connections to the site is not possible) – KJTHoward Mar 11 '20 at 13:35
  • Agree with Vincent's comments. I had to maintain a project with different related code on branches, and the end result was that every change had to be made in each branch independently. This was ClearCase, not git, so maybe git's merging will help some, but the fundamental problem remains. – Sean McMillan Mar 11 '20 at 14:07
  • Best keep one, single codebase, and use some kind of a configuration file (just a plain text file) to define the list of stocks. Your Github repo would contain an "example" configuration file. Each instance of the code in production would have its own configuration that isn't shared. – workerjoe Mar 11 '20 at 18:13

Let them fork your repository, so they can work in different repository, make their own changes anywhere they want and keep synced with the original's project upcoming changes without affecting your team's project and not demanding any special attention (code related, you still have that DB thing).

A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project.


Other solutions like work in the same repository with different branches or make manual syncs may be more difficult to maintain and increase potential for further problems.


Multiple branches are horrible for this. You will forever be merging branches.

But it depends on how long that other team will be interested. If they lose interest in six months, let them branch. If you are not responsible for maintaining their branch and not interested in their changes, let them branch. (There is little difference between having a branch that is never merged back and a repository, but the separate repository makes very clear they are in their own).

If this is long term, and you expect valuable modifications in their branch, and you want what’s best for your team, then you separate things out that are specific to your team, and control things with configuration, #ifdef, whatever, to maximise the amount of common code.

Obviously forced pull requests will be absolutely needed so you don’t lose control.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.