Version Control with Git: Popular Strategies

Nowadays, when we think of version control for a software project, we commonly think of Git, a tool created in 2005. Unlike other version control systems, Git does not strictly enforce a defined workflow strategy.

At an individual level, this is not a problem, but when working on complex projects, one of the initial tasks should be defining the workflow strategy that will be used with Git. This includes setting naming conventions for branches, when to create them, commit message formats, merge strategies, and other details that help maintain a clean and orderly change history.

Some known strategies include Centralized Flow, GitFlow, GitHub Flow, Feature Flow, and Trunk-Based Development. In this article, we will highlight the most popular strategies that enable better collaboration in team environments.

Trunk-Based Development (TBD)

In trunk-based development, there is a single main branch (typically main) where changes are continuously integrated. Other branches contain small changes that are frequently merged back.

The scope of tasks in this type of development is usually small to increase how often changes are added to the main branch. In some cases, changes are even made directly in main.

From the developer's perspective, not much changes besides adopting naming conventions for short-lived branches (e.g., task/ID-123, fix/ID-456). Since there is only one stable branch, new features should be kept hidden using mechanisms such as feature flags until they are officially deployed.

git checkout main
git checkout -b task/ID-124
echo "Change" >> readme.md
git add readme.md
git commit -m "Change description"
git push origin task/ID-124 # Push changes to repository

# To merge from another machine
git checkout main
git pull origin main
git fetch -a # Fetch all branches, or use: git fetch origin task/ID-124
git merge task/ID-124
git push origin main

GitFlow

GitFlow is a workflow based on feature branches. In this strategy, not only does the developer's process change, but also the application's deployment process.

• Changes are made from a develop branch, in task-specific feature branches, using a naming convention.
• Changes are merged into a release branch, which is then merged into main and develop and tagged with a version.
• For bug fixes, hotfix branches are created and merged directly into main and develop, just like with the release branch.

GitFlow has a well-defined strategy and reduces merge conflicts compared to TBD, at the cost of increased deployment complexity.

# Example skipping push/pull steps
git checkout develop
git checkout -b task/ID-123
echo "ID-123" >> readme.md
git commit -m "Task 123"
git merge task/ID-123
git checkout -b release-1 # Branch for release
git checkout main # Once all changes are in release
git merge release-1
git checkout -b hotfix/ID-456 # Hotfix after release
echo "ID-456" >> readme.md
git add readme.md
git commit -m "Hotfix 456"
git checkout main
git merge hotfix/ID-456 # Direct release of hotfix
git checkout develop
git merge main # Update develop to include hotfix

GitHub Flow

GitHub Flow is a simpler alternative to GitFlow, where all changes—whether features or hotfixes—are branched from main. These branches often contain more extensive changes than in TBD, and are typically integrated using CI/CD techniques.

It is less complex than GitFlow but more prone to conflicts and offers fewer controls over what gets deployed. The way to counter this is by using shorter development and deployment cycles, encouraging developers to keep their branches updated with main.

To ensure stability, it is common to use intermediate branches like develop with its own environment and tags for versioning. Agile teams with short cycles often implement testing at the feature branch level.

git checkout main
git checkout -b task/ID-125
echo "ID-125" >> readme.md
git commit -m "Task 125"
git push origin task/ID-125

# Changes are merged into main via pull request and CI
git checkout main
git pull origin main
git tag v1 # New tag with changes from the latest task
git push origin v1 # Deployment triggered by the new tag

How to Choose the Right Strategy

There are more strategies than the ones mentioned here, and each is better suited for specific scenarios—none of them fit every project. When choosing a strategy, consider factors like team size and maturity, software structure and complexity, desired release cycles, and stability expectations.

As a guideline, here are the typical use cases for the strategies mentioned in this article:

• Trunk-Based Development: Best for small teams with low project complexity where stability is not the main concern. Examples include command-line tools or basic libraries. It’s also used in projects migrating from other version control systems but receiving few changes.
• GitFlow: Ideal for mature teams with well-defined workflows. This strategy benefits projects that require stable deployments and manage complex or critical features.
• GitHub Flow: Common in small to medium-sized teams. It works well with agile teams due to its simplicity and fast pace, and is often complemented by CI pipelines.

Rootstack, a software development agency with experience in over 60 technologies and a team of certified experts ready to help you on your professional journey.

Recommended Video