DEV Community

Jose Luis
Jose Luis

Posted on

Gitflow Workflow: A Dynamic Guide for Development Teams

#gitflow #git #software

Introduction: Why Gitflow is still relevant?

Gitflow

If you are working in a development team, you've probably heard about Gitflow. Maybe you even use it frequently. But, do you really know when to use it and when to avoid using it?

In this article, I'm not just going to teach you the standard workflow, instead, I'll show you real-world case studies, modern alternatives, and how to implement it efficiently. As a developer who has worked both in agile startups and large corporations, I've seen Gitflow shine and also fail spectacularly.

What exactly is Gitflow?

Gitflow is a branching strategy created by Vincent Driessen by 2010. It's not a tool from Git, but a convention about how to use branches. Its main structure includes:

Permanent branches: 

main/master # Production - only stable
develop     # Integration - next release
Enter fullscreen mode Exit fullscreen mode

Permanent branches

Support branches: 

feature/*  # New functionalities
release/*  # Getting ready for production
hotfix/*   # Urgent corrections in production
Enter fullscreen mode Exit fullscreen mode

Support branches

Workflow step by step with Real Examples

1. Building a new feature:

Scenario: Your team need to add authentication OAuth2 for the App.

#1. Create feature branch from develop
git checkout develop
git pull origin develop
git checkout -b feature/oauth2-integration

#2. Working in the feature (many commits)
git add .
git commit -m "Add Google OAuth2 basic setup"
git commit -m "Implement token refresh logic"
git commit -m "Add user profile sync"

#3. Finish feature
git checkout develop
git merge --no-ff feature/oauth2-integration
git branch -d feature/oauth2-integration
git push origin develop
Enter fullscreen mode Exit fullscreen mode
Why --no-ff (no fast-forward)?

Preserve historical from branch feature as a logical group.

2. Preparing a Release:

Scenario: Version 2.1.0 is ready for production.

#1. Create release branch
git checkout develop
git checkout -b release/2.1.0

#2. Prepare release (bump version, docs, etc)
# Update version in package.json
git commit -am "Bump version to 2.1.0"

#3. Merging main and develop
git checkout main
git merge --no-ff release/2.1.0
git tag -a v2.1.0 -m "Release version 2.1.0"

git checkout develop
git merge --no-ff release/2.1.0

#4. Delete release branch
git branch -d release/2.1.0
Enter fullscreen mode Exit fullscreen mode

3. Hotfix Urgent in Production.

Scenario: Critic security error found in production.

#1. Create hotfix from main
git checkout main
git checkout -b hotfix/security-patch

#2. Fix issue
# Apply security fix
git commit -am "Fix SQL injection vulnerability"

#3. Apply to main and develop
git checkout main
git merge --no-ff hotfix/security-patch
git tag -a v2.1.1 -m "Security hotfix"

git checkout develop
git merge --no-ff hotfix/security-patch

#4. Delete hotfix branch
git branch -d hotfix/security-patch
Enter fullscreen mode Exit fullscreen mode

Gitflow in practice: Configuration and Tools

Initial configuration in repository 

# 1. Initialize repository
git init
git add .
git commit -m "Initial commit"

# 2. Create main branches
git branch develop
git checkout develop

# 3. Configurate upstream(in remote)
git remote add origin <url>
git push -u origin main
git push -u origin develop
Enter fullscreen mode Exit fullscreen mode

Complete workflow

Automation scripts (package.json) 

{
    "scripts":{
        "feature:start": "git checkout develop && git pull origin develop && git checkout -b",
        "feature:finish": "git checkout develop && git merge --no-ff",
        "release:start":"git checkout develop && git checkout -b release/",
        "hotfix:start":"git checkout main && git checkout -b hotfix/"
    }
}
Enter fullscreen mode Exit fullscreen mode

CI/CD Integration (Github Actions example) 

name: Gitflow CI

on: 
    push:
        branches: [develop, main, feature/*, release/*, hotfix/*]

jobs: 
    test: 
        runs-on: ubuntu-latest
        strategy:
            matrix:
                branch-type: [feature, release, hotfix]

        steps:
        - uses: actions/checkout@v3

        - name: Detect branch type
            id: branch-type
            run: |
                if [[ ${{ github.ref }} == refs/heads/feature/* ]]; then
                    echo "Type=feature" >> $GITHUB_ENV
                elif [[ ${{ github.ref }} == refs/heads/release/* ]]; then
                    echo "TYPE=release" >> $GITHUB_ENV
                fi

        - name: Run tests
            if: env.TYPE == 'feature'
            run: npm run test:unit

        - name: Integration tests
            if: env.TYPE == 'release'
            run: npm run test:integration
Enter fullscreen mode Exit fullscreen mode

Common patterns and best practices

Nomenclature conventions 

# Features: specific funcionality
feature/user-dashboard
feature/payment-processing

# Releases: Semantic version
release/1.2.0
release/2.0.0-rc.1

# Hotfixes:  short description
hotfix/login-error
hotfix/security-patch-cve-2024
Enter fullscreen mode Exit fullscreen mode

Optimal branch size

  • Feature branches: 1-5 days max.
  • Release branches: 1-2 weeks.
  • Hotfix branches: Hours, not days.

Conclusion: Gitflow 2026

Gitflow's not death, but evolve. In 2026, I recommend:

  1. Using modified Gitflow for big enterprise projects.
  2. Automatize everything with scripts and CI/CD.
  3. Consider Feature Flags to reduce needing release branches.
  4. Evaluate every 6 months if the workflow is still optimized.

My personal recommendation: Start with Gitflow if your team is just starting with Git, but keep an open mind to evolve and change workflow to something new and simpler.

Additional resources

Top comments (0)