DEV Community

How-to manage different project release versions in Git?

Marmalade on September 03, 2018

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...
Collapse
 
sublimegeek profile image
Jonathan Irvin

The beauty about Git is that there is no wrong way to do this. Here's some options.

  1. 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.

  1. Several repos that fork off of each other. You can update the core code and do pull requests to sync features.

  2. 1 Repo with several branches that does the same as 2, but you have 1 codebase.

  3. Several repos using git subtree or git submodules. This is a lot more complicated, but fitting if you have a large team.

Collapse
 
marmalade118 profile image
Marmalade

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.

Collapse
 
sublimegeek profile image
Jonathan Irvin

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.

Collapse
 
bertilmuth profile image
Bertil Muth

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.

Collapse
 
bgadrian profile image
Adrian B.G.

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.

Collapse
 
marmalade118 profile image
Marmalade

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.

  • Client A requires the full version of the app.
  • Client B requires modules 1 and 2 and a different colour scheme.
  • Client C requires modules 1, 2, 4 and 6 and wants some changes making to some of the page layouts.

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.