Version Control Branching Strategies

Version control systems helps developers to track, manage, and organize their code. In particular, it helps developers collaborate on code with teammates; combining features like commits and branches with specific principles and strategies. That helps teams organize code and reduce the time needed to manage versioning.

Branching strategy determines how team approaches code branching. There are 2 different branching patterns: long-lived and short-lived.

Long-lived branching is a good option for a longer-term, deeply complex project with multiple distributed development teams. A long-lived branch is a copy or branch of the mainline code that is used to work on a feature. A long-lived branching pattern works best for a feature isolation development approach.

Short-lived pattern offers a different working approach through short-lived branches. Unlike long-lived branching, which can take weeks of development, short-lived branching requires developers to integrate feature updates in days. This style of branching works best for a continuous integration development approach.

GitFlow branching strategy

Git flow is a popular Git branching strategy aimed at simplifying release management, and was introduced by software developer Vincent Driessen in 2010. It involves the use of feature branches and multiple primary branches. It has numerous, long-lived branches and larger commits.

Git flow strategy uses 5 branches: main, develop, feature, release and hotfix.

Main branch

The purpose of the main branch in the Git flow workflow is to contain production-ready code that can be released. The main branch is created at the start of a project and is maintained throughout the development process. The branch can be tagged at various commits in order to signify different versions or releases of the code, and other branches will be merged into the main branch after they have been sufficiently vetted and tested.

Develop branch

The develop branch is created at the start of a project and is maintained throughout the development process, and contains pre-production code with newly developed features that are in the process of being tested. Newly created features should be based off the develop branch, and then merged back in when ready for testing.

Feature branch

The feature branch is the most common type of branch in the Git flow workflow. It is used when adding new features to your code. When working on a new feature, you will start a feature branch off the develop branch, and then merge your changes back into the develop branch when the feature is completed and properly reviewed.

Release branch

The release branch should be used when preparing new production releases. Typically, the work being performed on release branches concerns finishing touches and minor bugs specific to releasing new code, with code that should be addressed separately from the main develop branch.

Hotfix branch

The hotfix branch is used to quickly address necessary changes in your main branch. The base of the hotfix branch should be your main branch and should be merged back into both the main and develop branches. Merging the changes from your hotfix branch back into the develop branch is critical to ensure the fix persists the next time the main branch is released.

Summary of Git Flow strategy

1. A develop branch is created from main

2. A release branch is created from develop

3. Feature branches are created from develop

4. When a feature is complete it is merged into the develop branch

5. When the release branch is done it is merged into develop and main

6. If an issue in main is detected a hotfix branch is created from main

7. Once the hotfix is complete it is merged to both develop and main