How do I maintain post deployment older versions of my code on GitLab?

Question

My project is moving from TFS version controlling to GitLab. This is how we used to go about TFS:

Each production release will be a version branch. For example, 2.0 for release 1, 2.1 for next and 2.2 for next (Sub branching to 2.2.x was also there to track). If at any point I wanted to check exactly what code was deployed 5 releases back to production, I can dial back the version numbers (Say current is 2.6, so 5 releases back will be 2.1) and check that branch code in my TFS repo.

What I am not sure is, how to maintain this same thing on Git (very new to it). The two methods I know are:

Method 1: Keep older code in branches under the same project. So for instance, I will have branches like this: 1.0 1.1 1.2 . . . . 2.5 (Current master) 2.5 Test - Separate branch to track what dev changes have gone to test environments 2.5 Feature/DEV

Method 2: Each release will be treated like a sub-project under my project. If I am working on current 2.5 branch, the older branches code will be available as a sub-project under my main project folder and the current sub-project will be the latest code I am working on for the next production release.

The question: Which of the two is correct and is there another third way that I am not aware of that works better?

Answer 1

With git, you can check out arbitrary commits. You use tags to mark commits that have been released.

Branches should be used when there is parallel development (for example, to create a bugfix release for the currently released version while development already includes new and possibly untested features.)

New projects should never be used for separate versions of the same software, unless you do a complete rewrite from scratch, which is a very rare situation, or you want to hide the development history, which is also highly unusual.

Your first option sounds reasonable, though you could postpone release branching to the time when a need for a bugfix release arises.

Answer 2

There are different ways of going about this. The simplest and most common is probably to use tags for releases. You only really need a branch from there if you need to provide bugfixes to a release.

There are many other models, one of which is becoming common:

• create a "Master" and "Development" branch
• Work against "Develop" (commit daily work there, create branches to develop features on from there)
• Merge "Develop" into "Master" from the commit that was released (and only then)
• "fix" branches then start from these commits on "Master" and have their own parallel development branch (e.g. "1.2-Master" and "1.2-Develop"

The approach you choose depends on how your team is set up as well, so I suggest you map the last 2-3 releases from TFS to your shortlist of approaches and run through how everything would have worked out with your team setup.