Gitflow workflow - Deep Dive

Overview - Gitflow workflow

What is it?

Gitflow workflow is a way to organize work in Git by using specific branches for different purposes. It uses main branches like 'main' and 'develop' plus special branches for features, releases, and fixes. This helps teams work together without mixing unfinished work with stable code. It makes managing changes clear and safe.

Why it matters

Without Gitflow, teams can get confused about where to put new code or fixes, leading to mistakes and broken software. Gitflow solves this by giving clear rules for branching and merging, so everyone knows where to work and how to deliver stable updates. This reduces bugs, speeds up releases, and keeps projects organized.

Where it fits

Before learning Gitflow, you should know basic Git commands like commit, branch, and merge. After Gitflow, you can explore advanced Git topics like rebasing, continuous integration, and deployment pipelines that use Gitflow branches.

Mental Model

Core Idea

Gitflow is a branching strategy that separates development, features, releases, and fixes into dedicated branches to keep code organized and stable.

Think of it like...

Gitflow is like a kitchen in a restaurant where different chefs work on appetizers, main courses, and desserts in separate stations before the final meal is served to customers.

┌─────────┐      ┌───────────┐      ┌─────────────┐
│  main   │◄─────│  release  │◄─────│  develop    │
└─────────┘      └───────────┘      └─────────────┘
                     ▲                  ▲    ▲
                     │                  │    │
               ┌───────────┐      ┌───────────┐
               │ hotfix    │      │ feature   │
               └───────────┘      └───────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Git Branch Basics

Concept: Learn what branches are in Git and how they let you work on different versions of code separately.

In Git, a branch is like a separate path where you can make changes without affecting the main code. You can create, switch, and merge branches. This lets multiple people work on different parts safely.

Result

You can create and switch branches to isolate your work.

Knowing branches is essential because Gitflow depends on using multiple branches for different tasks.

2

Foundation

Introducing Main and Develop Branches

Concept: Learn the two main branches in Gitflow: 'main' for stable code and 'develop' for ongoing work.

'main' holds the production-ready code. 'develop' is where developers add new features and fixes before they are ready. Changes flow from 'develop' to 'main' after testing.

Result

'main' stays stable while 'develop' is active for new work.

Separating stable and development code prevents unfinished work from breaking production.

3

Intermediate

Feature Branches for New Work

🤔Before reading on: do you think feature branches merge directly into 'main' or 'develop'? Commit to your answer.

Concept: Feature branches let you work on new features isolated from others until ready.

Create a feature branch from 'develop' to add a new feature. When done, merge it back into 'develop'. This keeps 'develop' updated with finished features only.

Result

Features are developed separately and integrated safely into 'develop'.

Using feature branches avoids mixing incomplete features with ongoing development.

4

Intermediate

Release Branches for Preparing Launch

🤔Before reading on: do you think release branches are created from 'main' or 'develop'? Commit to your answer.

Concept: Release branches prepare code for production by final testing and fixes.

When 'develop' has enough features, create a release branch. Use it to fix bugs and prepare documentation. After ready, merge into 'main' and 'develop'.

Result

Production releases are stable and well-tested before going live.

Release branches let you polish code without blocking new feature work.

5

Intermediate

Hotfix Branches for Urgent Fixes

Concept: Hotfix branches fix problems in production quickly without waiting for the next release.

Create a hotfix branch from 'main' to fix a critical bug. After fixing, merge back into 'main' and 'develop' to keep all branches updated.

Result

Critical fixes reach production fast and keep development in sync.

Hotfixes allow emergency fixes without disrupting ongoing development.

6

Advanced

Managing Branch Lifecycles and Merges

🤔Before reading on: do you think merges in Gitflow are mostly fast-forward or require explicit merge commits? Commit to your answer.

Concept: Understand how and when to merge branches in Gitflow to keep history clear and conflicts minimal.

Feature branches merge into 'develop' with merge commits to keep history. Release and hotfix branches merge into both 'main' and 'develop' to sync changes. Deleting branches after merge keeps repo clean.

Result

Branch history is organized, and code stays synchronized across branches.

Proper merging prevents confusion and keeps the project history understandable.

7

Expert

Scaling Gitflow in Large Teams

🤔Before reading on: do you think Gitflow scales well for continuous deployment environments? Commit to your answer.

Concept: Explore challenges and adaptations of Gitflow in big teams and fast release cycles.

In large teams, many feature branches run in parallel. Coordination is key to avoid conflicts. For continuous deployment, Gitflow can be adapted by automating merges and using feature toggles. Some teams simplify Gitflow to speed releases.

Result

Gitflow can support complex projects but may need tweaks for speed and scale.

Knowing Gitflow's limits helps teams choose or adapt workflows for their needs.

Under the Hood

Gitflow works by using Git's branching and merging features to isolate different types of work. Each branch type has a role: 'main' holds stable code, 'develop' holds integration code, feature branches isolate new work, release branches prepare production, and hotfix branches fix urgent bugs. Merges synchronize changes between branches, and branch deletion cleans up after work is done.

Why designed this way?

Gitflow was created to solve the problem of managing multiple developers working on different tasks without breaking the main code. It balances stability and flexibility by separating ongoing work from production-ready code. Alternatives like trunk-based development exist but Gitflow offers clear structure for teams needing formal release cycles.

┌───────────────┐
│    main       │
│ (stable code) │
└──────┬────────┘
       │
       │ merges release & hotfix
       ▼
┌───────────────┐
│   release     │
│ (prepares    │
│  production)  │
└──────┬────────┘
       │
       │ merges features
       ▼
┌───────────────┐
│   develop     │
│ (integration) │
└──────┬────────┘
       │
       │ branches for new features
       ▼
┌───────────────┐
│  feature      │
│ (new work)    │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think feature branches merge directly into 'main'? Commit yes or no.

Common Belief: Feature branches merge directly into 'main' to add new code quickly.

Reality: Feature branches merge into 'develop', not 'main'. 'main' only gets stable, tested code.

Why it matters: Merging features directly into 'main' risks breaking production with unfinished code.

Quick: Is 'develop' always stable and ready for production? Commit yes or no.

Common Belief: 'develop' branch is stable and can be deployed anytime.

Reality: 'develop' is for ongoing work and may contain unfinished or unstable code.

Why it matters: Deploying from 'develop' can cause bugs and unstable releases.

Quick: Do you think hotfix branches come from 'develop'? Commit yes or no.

Common Belief: Hotfix branches are created from 'develop' to fix bugs.

Reality: Hotfix branches are created from 'main' to fix production bugs immediately.

Why it matters: Creating hotfixes from 'develop' delays urgent fixes and can cause conflicts.

Quick: Does Gitflow work perfectly for continuous deployment? Commit yes or no.

Common Belief: Gitflow is ideal for all projects, including continuous deployment.

Reality: Gitflow can be too heavy for continuous deployment and may slow down releases.

Why it matters: Using Gitflow without adaptation can block fast, frequent deployments.

Expert Zone

1

Feature branches should be short-lived to avoid complex merges and conflicts.

2

Release branches allow last-minute fixes without freezing feature development on 'develop'.

3

Merging hotfixes back into both 'main' and 'develop' keeps all branches synchronized and prevents regressions.

When NOT to use

Gitflow is not ideal for projects needing continuous deployment or very fast release cycles. Alternatives like trunk-based development or GitHub flow are better for those cases because they simplify branching and encourage frequent integration.

Production Patterns

Teams use Gitflow with automated CI/CD pipelines that build and test each branch type. Feature toggles are often combined to deploy incomplete features safely. Hotfixes are prioritized and merged quickly to minimize downtime.

Connections

Trunk-Based Development

Alternative branching strategy with fewer branches and more frequent merges.

Understanding Gitflow helps appreciate why trunk-based development simplifies workflows for faster releases.

Continuous Integration (CI)

Gitflow branches trigger CI pipelines to test and build code automatically.

Knowing Gitflow clarifies how CI systems manage different code stages and ensure quality.

Project Management Kanban

Both organize work into stages and track progress systematically.

Seeing Gitflow like Kanban helps understand how code changes flow through defined phases before completion.

Common Pitfalls

#1 Merging feature branches directly into 'main' instead of 'develop'.

Wrong approach:

git checkout main
git merge feature/login

Correct approach:

git checkout develop
git merge feature/login

Root cause:

Misunderstanding the role of 'develop' as integration branch leads to unstable 'main'.

#2 Creating hotfix branches from 'develop' instead of 'main'.

Wrong approach:

git checkout develop
git checkout -b hotfix/urgent-fix

Correct approach:

git checkout main
git checkout -b hotfix/urgent-fix

Root cause:

Confusing where production code lives causes delays in urgent fixes.

#3 Not deleting branches after merging, cluttering the repository.

Wrong approach:

git branch feature/login
# merged but branch not deleted

Correct approach:

git branch -d feature/login

Root cause:

Neglecting branch cleanup leads to confusion and harder repo management.

Key Takeaways

Gitflow organizes work by using dedicated branches for features, releases, and fixes to keep code stable and development clear.

The 'main' branch holds production-ready code, while 'develop' is for integrating new work before release.

Feature branches isolate new work and merge into 'develop', not 'main', to avoid breaking stable code.

Release branches prepare code for production with final testing and fixes, then merge into both 'main' and 'develop'.

Hotfix branches fix urgent production bugs quickly by branching from 'main' and merging back to keep all branches updated.

Practice

1. What is the main purpose of the develop branch in the Gitflow workflow?

easy

A. It serves as the integration branch for features before release.

B. It contains the production-ready code only.

C. It is used to fix urgent bugs directly in production.

D. It stores experimental code that is not stable.

Solution

1. Step 1: Understand the role of the develop branch

   The develop branch is where all completed features are merged and tested together before release.

2. Step 2: Compare with other branches

   The master branch holds production-ready code, hotfix branches fix urgent bugs, and experimental code is not part of Gitflow standard branches.

3. Final Answer:

   It serves as the integration branch for features before release. -> Option A

4. Quick Check:

   Develop = integration branch [OK]

Hint: Develop branch integrates features before release [OK]

Common Mistakes:

• Confusing develop with master branch
• Thinking develop is for hotfixes
• Assuming develop holds only stable code

2. Which command correctly starts a new feature branch named login using Gitflow?

easy

A. git flow start feature login

B. git flow feature start login

C. git start feature login

D. git feature start login

Solution

1. Step 1: Recall Gitflow feature start syntax

   The correct syntax to start a feature branch is git flow feature start <name>.

2. Step 2: Check each option

   Only git flow feature start login matches the correct syntax exactly. Others have incorrect order or missing 'flow'.

3. Final Answer:

   git flow feature start login -> Option B

4. Quick Check:

   Feature start = git flow feature start [OK]

Hint: Use 'git flow feature start <name>' to start features [OK]

Common Mistakes:

• Omitting 'flow' in the command
• Swapping command word order
• Using 'git start' instead of 'git flow feature start'

3. Given the commands below, what is the final branch after finishing a release?

git flow release start 1.0.0
git flow release finish 1.0.0

medium

A. The branch is switched to master.

B. The branch is switched to develop.

C. The branch remains on release/1.0.0.

D. The branch is switched to feature/1.0.0.

Solution

1. Step 1: Understand what 'git flow release finish' does

   This command merges the release branch into both master and develop, tags the release, and deletes the release branch.

2. Step 2: Identify the branch after finishing release

   After finishing, Gitflow switches to master branch by default.

3. Final Answer:

   The branch is switched to master. -> Option A

4. Quick Check:

   Release finish switches to master [OK]

Hint: Release finish merges and switches to master [OK]

Common Mistakes:

• Assuming branch stays on release
• Thinking it switches to develop
• Confusing feature branches with release

4. You ran git flow feature finish login but your changes are not in develop. What is the likely problem?

medium

A. You forgot to push the develop branch after finishing the feature.

B. You did not commit changes before finishing the feature.

C. You started the feature branch from master instead of develop.

D. You finished the feature on the master branch.

Solution

1. Step 1: Recall feature branch base in Gitflow

   Feature branches should start from develop to ensure changes merge back there.

2. Step 2: Analyze why changes are missing in develop

   If the feature branch was started from master, finishing it merges changes into master, not develop, causing missing updates in develop.

3. Final Answer:

   You started the feature branch from master instead of develop. -> Option C

4. Quick Check:

   Feature base must be develop [OK]

Hint: Feature branches must start from develop [OK]

Common Mistakes:

• Assuming finishing auto-pushes changes
• Not committing before finishing
• Confusing master and develop as base

5. Your team wants to prepare a hotfix for a critical bug in production while a release is in progress. According to Gitflow, which sequence of commands correctly handles this situation?

hard

A. git flow hotfix start fix-bug; git flow release finish; git flow hotfix finish fix-bug

B. git flow release finish; git flow hotfix start fix-bug; git flow hotfix finish fix-bug

C. git flow feature start fix-bug; git flow feature finish fix-bug

D. git flow hotfix start fix-bug; git flow hotfix finish fix-bug

Solution

1. Step 1: Understand hotfix purpose in Gitflow

   Hotfix branches are created from master to quickly fix production bugs, independent of ongoing releases.

2. Step 2: Check command sequence for hotfix

   Starting and finishing a hotfix with git flow hotfix start and git flow hotfix finish is the correct way, regardless of release status.

3. Step 3: Evaluate options

   git flow hotfix start fix-bug; git flow hotfix finish fix-bug correctly starts and finishes the hotfix. git flow release finish; git flow hotfix start fix-bug; git flow hotfix finish fix-bug delays hotfix until release finishes, which is not required. git flow feature start fix-bug; git flow feature finish fix-bug uses feature instead of hotfix. git flow hotfix start fix-bug; git flow release finish; git flow hotfix finish fix-bug incorrectly mixes release finish before hotfix finish.

4. Final Answer:

   git flow hotfix start fix-bug; git flow hotfix finish fix-bug -> Option D

5. Quick Check:

   Hotfix runs independently during release [OK]

Hint: Hotfix branches start and finish independently from release [OK]

Common Mistakes:

• Waiting for release to finish before hotfix
• Using feature branch for hotfix
• Finishing release before hotfix finish