Git branching strategies

As an engineer when I was making small project in colleges, I used Git as version-control system. Back then, as a rookie, the way I use to implement this was very crude and the way most of newbies start.

I created the repository on GitHub and started committing my code to master branch without any hesitation. But, eventually when I started collaborating with others on projects, I started realising that single branch approach was creating more friction. Many different approaches were tried after this.

I started creating branches, with developer's names which, merged in master branch. Eventually this wore out when I developed my first real-life website for my college robotics club - The Robotics Forum.
One time I had to revert back changes which didn't workout well with this strategy.

Then I adapted a staging branch before merging in master, but the problem here with now the branches with developer names became difficult to track. Also, it there was no definite purpose of the branch from code perspective i.e. it only had advantages to developers and not the actual code.

The time I started my first job at HSBC Technology India as a 'Trainee Software Engineer', that is when I saw the complexity. Different environments and parallel development of features were the way.

This is when I read about Git Flow, a popular branching strategy.

This workflow dictates that there should be two permanent branches in you repository namely master, develop.
Both these branches should be parallel to each other.

In addition to this there would be three types of supporting branches hotfix-*, release-* and feature-*.

The feature-* branches are created from develop branch and are merged back to develop.

The release-* branches are created from develop branch and are merged into develop and master.

The hotfix-* branches are created from master branch and are merged into develop and master.

There is another famous strategy called trunk-based development. You can read more here https://trunkbaseddevelopment.com/

In the upcoming blogs I would be writing about which merging strategies should be used, which branches should be deployed in different environments, how we can implement an automatic sem-ver maintainer.