The beauty about Git is that there is no wrong way to do this. Here's some options.
A core repo that contains shared code between all versions.
1a. Like @bertilmuth
suggested, use feature flags. This way you can fork off of your core code and enable and disable features at will. You can host these flags in a JSON object that gets called from an API and you can deploy the same code and toggle the flags remotely.
Several repos that fork off of each other. You can update the core code and do pull requests to sync features.
1 Repo with several branches that does the same as 2, but you have 1 codebase.
Several repos using git subtree or git submodules. This is a lot more complicated, but fitting if you have a large team.
Many thanks for replying. Option 1 seems more like how I envisaged things working, so I'm going to have a play about with things and see what I can come up with.
I always seem to catch myself out and say things like 'What's the correct way to do this?', even though I know it's more about personal preference etc. What I should have asked is how others would approach a scenario like this; I'll try remember that for the future.
Again, thanks to everyone for their advice. It's been a great help.
Git is super flexible in how you can use it to solve problems. Keeping separate branches gives you the functionality of a fork, but the flexibility of having it in the same repo. Other members of the team and easily check out those different versions and you can merge branches together as you need code to sync up. You can cherry-pick commits if you want some, but not all changes.
One of the biggest challenges ANY project has to overcome is communication. We can have great tools like Git that help us track our changes and share code, but they are useless without good communication.
Especially with the idea you're working with, there's potential for merge conflicts if there isn't enough cross-collaboration between you and the other developers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The beauty about Git is that there is no wrong way to do this. Here's some options.
1a. Like @bertilmuth suggested, use feature flags. This way you can fork off of your core code and enable and disable features at will. You can host these flags in a JSON object that gets called from an API and you can deploy the same code and toggle the flags remotely.
Several repos that fork off of each other. You can update the core code and do pull requests to sync features.
1 Repo with several branches that does the same as 2, but you have 1 codebase.
Several repos using
git subtreeorgit submodules. This is a lot more complicated, but fitting if you have a large team.Hi, Jonathan.
Many thanks for replying. Option 1 seems more like how I envisaged things working, so I'm going to have a play about with things and see what I can come up with.
I always seem to catch myself out and say things like 'What's the correct way to do this?', even though I know it's more about personal preference etc. What I should have asked is how others would approach a scenario like this; I'll try remember that for the future.
Again, thanks to everyone for their advice. It's been a great help.
Git is super flexible in how you can use it to solve problems. Keeping separate branches gives you the functionality of a fork, but the flexibility of having it in the same repo. Other members of the team and easily check out those different versions and you can merge branches together as you need code to sync up. You can cherry-pick commits if you want some, but not all changes.
One of the biggest challenges ANY project has to overcome is communication. We can have great tools like Git that help us track our changes and share code, but they are useless without good communication.
Especially with the idea you're working with, there's potential for merge conflicts if there isn't enough cross-collaboration between you and the other developers.