I'm relatively new to using Git and I was hoping someone might be able to help me out with a scenario I have found myself in?
I have a requirement to create multiple versions of an app, each with a different feature set activated depending on the client's requirements; but also continue to develop a core feature set available to all versions.
Initially I was going to put each version in it's own repository, but, from what I can tell, that would mean a lot more administrative overhead when releasing updates that are relevant to all versions, and isn't taking advantage of Gits features.
I'm guessing the correct way to go with this is to use branches and merge the core updates in to each client specific branch but, I've only ever used Git to manage a single solution with a master, dev and sometimes a release branch, so I have no idea if this is the right or wrong way to go, how I would structure the repository etc.
Any advice would be greatly appreciated.
Top comments (6)
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.
You may want to consider another solution, that has nothing to do with Git:
Feature Toggles.
To be clear: I am not saying "use feature toggles", I just want to point to it as another potential option.
The main question answer is: git tags. This is usually how you mark a release commit, saying: this commit marks the version "v1.0".
As for the structure of the project, for smaller ones you may need a simplified version of the common Git Workflows. Generally you work on different branches and merge when ready. The main branch has the most recent stable version.
Bi/huge teams/projects use Trunk based workflow, because the previous one have limitations. This is the opposite as previous techniques, everyone works with the master and you have release branches. The main branch has the most recent but not so stable version.
BG Adrian and Bertil Muth, many thanks to you both for your responses.
My plan is to add application configuration options to allow people to enable/disable a module as required, however, in the interim period I need to provide different versions of the app to different clients, before I will have chance to get that part completed (management pressure). Currently I'm using git tags for my releases but I was worried I would find myself in a bit of a mess trying to manage a minimum of 3 different versions of each release, using tags alone. And that I would be creating a lot of extra work for myself because I wasn't leveraging some of Git's features.
I'll elaborate on my scenario a bit to make sure I've explained things correctly.
Example:
The current version of the app is version 1.0.0.0 and includes 10 modules.
Should I just have the full version in the repository with all modules activated, then for each release - and version of said release - manually change the solution as per client requirements, then commit it and tag it? Or should I have a branch for the main app and a branch for each client version?
Apologies if I have misunderstood something you've already said. I find git to be a tad confusing at times.
Again, many thanks for any help provided. It's much appreciated.