Q:

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

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?

A:

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.

