Using main, dev, feature branches

When using any type of versioning software, either collaboratively or not, there are a few best practices that should be followed regarding branching strategies. This will be a short and sweet entry. No fluff!

The article git branching strategy outlines several strategies from which to choose. The strategy that I regularly adopt and recommend to my collaborators is “Feature Branching”. Chapter 7 in the above article.

How feature branching works:

• You have a main branch (called main). This is where your most recent release (if developing software) will reside. Anyone installing your software/package will expect this to be a functioning version.
• A development branch (called dev or develop) which is a branch of main. This is where all of your features are merged prior to a formal release (or merging into main)
• Multiple feature branches (named based on feature development or bug fix) that are branches of dev and are worked on independently until merged into dev

From the article above, the figure below depicts the flow:

Regardless of the branching strategy there are a few best practices that should be followed:

• Adopt a consistent naming structure for features or bug fixes
• Merge frequently to prevent merging issues (Don’t work on branches for long periods of time)
  • This is helped by breaking large tasks into small tasks
• Utilize Code reviews. All merging of code should be via pull requests
  • Adopt a policy of what a code review should involve
  • Identify how many reviewers should be requested
  • This will enhance the teams knowledge in the process and the product and will provides a check for overlooked bugs
• Add automation testing for common checks
  • Do any commits break the currently working product?
• Document these best practices
• Remove branches after they have been merged

Lots to think about!