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?