Branching and merging plays a very important role. (Git Flow)

 

Just as your planned tactics will creating the branches, it should not be the case that you are moving forward and generating n number of branches. There should be some scenario in real time. 

 

Your branches will determine particular roles assigned to them. Your integration pipelines will then be designed depending on those branches. If a modification is introduced to your release branch, a release pipeline should manage the build and subsequently handling the deployment. This is an often employed branching approach, particularly applicable in larger teams. 

 

Branching Mechanism 
git flow : - is a sophisticated branching mechanism designed to address a wide range of scenarios.  What are the scenarios?

truck based:- (see at)

 

 

git flow Branches Strategies:-

• main/master for production - main or master branch this is more for production. Keep it as primary copy of your source code. Having Production Code or Golden Copy.

 

• feature- this branch is more for new feature related activities. Having code any feature develop be developer.

 

• hotfix/ECR- branch to address more urgent issues. primary development branch to be used in CI/CD

 

• develop - for active developments as current development, future development. primary development branch to be used in CI/CD. Having code of all current and future development/stories/work items. feature branches will merge into this branch by developer

 

• release/staging - This serves as a gatekeeper for production. So, before you merge your modifications into main or master or production, your deployment to production will occur via Release branch. Having Production Release Code

 

 

git flow branching mechanism PROS

• Works well for larger teams. 
• Clearly defines how to effectively manage numerous versions of your project. 
• The responsibilities of each branch are well specified.
• Use Tags, for simple navigating of the production versions.

 

 

git flow branching mechanism CONS

• Complexity - due to numerous branches, It is more complex.
• Your team must demonstrate a commitment to following the strategy closely.

 

 

 

Merging Techniques at Real Time

Steps In Case New Feature to be develop

• Step 1: Start initially as a first Team Member:  Initialize your repository for the first time, using the main/master branch, 
  • Make main/master as Compare Branch
• Step 2: Create a development branch from the main branch
  • Where QA will Test
  • Where CI Pipeline will be created
• Step 3: Create a feature branch from the Development Branch
  • That's why we set this development branch as my default branch.
  • As development branch is holding all the future and current development code.
• Step 4: Once developer done with the development activity, he will go back to the develop branch. He will merge back to the develop branch
• Step 5: Update Release Branch
  • Once you are done with your development activity and approved by QA team, there is a release coming in.
  • Do a cherry pick from the development branch (because your development branch will have multiple changes over there), and create a PR back to release branch from development branch.
• Step 6: Update Production
  • Once the release was successful and approved, merge your changes back to main or master or production branch, keeping a golden copy, a stable production code over here.

 

 

 

Steps In Case of any Hot Fix

• if there is any ECR or hotfix required then create a hotfix branch from the development branch
• After resolve in Hotflix branch, push Hotfix branch directly into the main branch i.e.  the production branch.
  • Reason: Because ECR, includes emergency change,
  • We will test our ECR changes at the local environment and then we'll put things directly into production because we need to fix things ASAP.