Branches

Branching Approach

What is a branch and why do we need them

Multi Version File Systems (MVFS) have been with us for a long time. Usually associated with version controls systems, they allow us to manage multiple versions of file system components (files, directories, etc) at the same time. I see three key things (at a minimum) that they provide:

1. Head: the most recent part of the mainline (master) version of the file system
2. Branches: a way to change code away from the mainline
3. Labels: a mechanism to refer to a version of the code with a friendly name

The ability to develop code away from the mainline is a key feature for collaborative teams to work alongside each other. If you think of a MVFS as graph (specifically a Directed Acyclic Graph - DAG) with nodes and edges, where each branch of the graph is a named flow of change you can build up a mental picure of a Version Control System (VCS).

In the above image you can see

Artefact promotion over branch promotion

Standards

• All code changes happen on a feature branch separated from the main (master) branch and is tested and reviewed before merge
• Branches are short lived as they break Continuous Integration principles
• Applications are versioned based on their date and work partition. Year/sprint/patch. Include brahch name if not from master.
• Master should be releasable at all times
• Plan to segregate functionality instead of feature branching, use tests to verify functionality
• Use a single standard release approach/mechanism
• anything on a branch should be nmerged back to mainline … no implicit forking

Merge to master rules

References and Links

• Github Flow
• Git Flow
• Feature Branching (Fowler)