DEV Community

Cover image for Understanding Non-Fast-Forward Merges in Git
Khanh Nguyen
Khanh Nguyen

Posted on

Understanding Non-Fast-Forward Merges in Git

#git #gitflow

Git merges are a fundamental part of collaborative development, but not all merges are created equal. While fast-forward merges are simple and linear, non-fast-forward merges play a crucial role in preserving project history and maintaining a clear record of feature development. Let's explore what non-fast-forward merges are, when to use them, and why they matter.

What Is a Non-Fast-Forward Merge?

A non-fast-forward merge occurs when Git creates a new merge commit to combine two branches, even when a fast-forward merge would be possible. This merge commit has two parent commits: one from each branch being merged.

In contrast, a fast-forward merge simply moves the branch pointer forward along a linear path when the target branch hasn't diverged from the source branch. No merge commit is created in this case.

The Anatomy of a Non-Fast-Forward Merge

Consider this scenario: You create a feature branch from main, make some commits, and meanwhile no new commits are added to main. When you merge:

Fast-Forward Merge 

Before merge:
    A---B---C     (main)
             \
              D---E---F     (feature)

After fast-forward merge:
    A---B---C---D---E---F     (main, feature)
Enter fullscreen mode Exit fullscreen mode

Git simply moves the main branch pointer to the tip of your feature branch. The history remains linear.

Non-Fast-Forward Merge 

Before merge:
    A---B---C     (main)
             \
              D---E---F     (feature)

After non-fast-forward merge (--no-ff):
    A---B---C-----------M     (main)
             \         /
              D---E---F     (feature)
Enter fullscreen mode Exit fullscreen mode

Git creates a new merge commit (M) that combines the branches, preserving the fact that development happened on a separate branch.

How to Perform a Non-Fast-Forward Merge

To force a non-fast-forward merge, use the --no-ff flag:

git checkout main
git merge --no-ff feature-branch
Enter fullscreen mode Exit fullscreen mode

This creates a merge commit even when a fast-forward would be possible. Git will open your default editor to let you customize the merge commit message.

You can also configure Git to always use non-fast-forward merges for specific branches:

git config branch.main.mergeoptions "--no-ff"
Enter fullscreen mode Exit fullscreen mode

Real-World Example: Feature Development

Let's look at a more realistic scenario with multiple features being developed:

With fast-forward merges:
    A---B---C---D---E---F---G---H---I     (main)

    Where: D,E,F = Feature 1 commits
           G,H,I = Feature 2 commits

With non-fast-forward merges:
    A---B---C-------M1------M2     (main)
             \     /  \     /
              D---E    F---G
           Feature 1  Feature 2
Enter fullscreen mode Exit fullscreen mode

Notice how the non-fast-forward approach clearly shows two distinct features merged into main, while the fast-forward approach loses this context.

Benefits of Non-Fast-Forward Merges

Non-fast-forward merges offer several advantages for project management and history tracking.

First, they preserve feature boundaries. Each feature remains visually distinct in the commit graph, making it easy to see where a feature started and ended. This grouping is invaluable when reviewing project history or tracking down issues.

Second, they simplify rollbacks. If a feature needs to be reverted, you can simply revert the single merge commit rather than identifying and reverting multiple individual commits:

Reverting a feature with non-fast-forward merge:
    A---B---C-------M1------M2------R     (main)
             \     /  \     /       |
              D---E    F---G        |
                                    └── Revert of M1

vs. trying to revert individual commits:
    A---B---C---D---E---F---G---H---I---R1---R2---R3     (main)
                └───┴───┘
            Need to identify and revert
            these specific commits
Enter fullscreen mode Exit fullscreen mode

Third, they provide better documentation. The merge commit message can describe what the feature accomplishes at a high level, while individual commits show the implementation details.

Fourth, they maintain a cleaner main branch. The main branch contains primarily merge commits representing completed features, making it easier to understand the project's evolution at a glance.

When to Use Non-Fast-Forward Merges

Non-fast-forward merges are particularly valuable in certain workflows and situations.

Git Flow Workflow

In Git Flow, non-fast-forward merges are standard:

    master    A-----------M1----------M2
               \         /  \        /
    develop     B---C---D----E---F--G
                 \     /       \   /
    feature/1     H---I         J-K
Enter fullscreen mode Exit fullscreen mode

This structure clearly shows releases (M1, M2) and feature integrations.

Pull Request / Merge Request Workflows

Many teams use non-fast-forward merges when closing pull requests:

    main      A---B---------M1--------M2
                   \       /  \       /
    PR #123         C-----D    \     /
                                 \   /
    PR #124                       E-F
Enter fullscreen mode Exit fullscreen mode

Each merge commit corresponds to a completed pull request, providing a clear audit trail.

Potential Drawbacks

While powerful, non-fast-forward merges aren't always the best choice.

They create a more complex commit graph:

Complex graph with many features:
    A---B---M1---M2---M3---M4---M5     (main)
       |   /|   /|   /|   /|   /
       |  / |  / |  / |  / |  /
       |/   |/   |/   |/   |/
       C    D    E    F    G

vs. Linear history:
    A---B---C---D---E---F---G     (main)
Enter fullscreen mode Exit fullscreen mode

For developers new to Git, the complex graph can be harder to understand than a linear history.

Best Practices

To get the most from non-fast-forward merges, consider these practices.

Clean Feature Branches Before Merging 

Before cleanup:
    main      A---B---C
                   \
    feature         D---E(WIP)---F(fix typo)---G

After cleanup (squash/rebase):
    main      A---B---C
                   \
    feature         D'---E'

After merge:
    main      A---B---C-------M
                   \         /
    feature         D'-----E'
Enter fullscreen mode Exit fullscreen mode

This gives you clean, meaningful commits within the feature while preserving the merge boundary.

Use Descriptive Merge Messages 

Good merge commit message:
    Merge: Add user authentication system (#PR-123)

    - Implements JWT-based authentication
    - Adds login/logout endpoints
    - Includes password reset functionality

    Closes #456, #457

Default merge commit message:
    Merge branch 'feature-auth'
Enter fullscreen mode Exit fullscreen mode

Visual Tools

Use git log --graph --pretty=oneline --abbrev-commit to visualize your branch structure:

* 5d3f1a2 (HEAD -> main) Merge: Add payment processing
|\  
| * 8c4b2e1 Add Stripe integration
| * 7a9c3f2 Create payment models
|/  
* 3e2d1c5 Merge: User authentication system
|\  
| * 9f8e7d6 Add JWT tokens
| * 2b3c4d5 Create login endpoints
|/  
* 1a2b3c4 Initial commit
Enter fullscreen mode Exit fullscreen mode

Conclusion

Non-fast-forward merges are a powerful tool for maintaining a clear and informative project history. While they add complexity to the commit graph, they provide valuable context about feature development, simplify rollbacks, and support collaborative workflows.

The choice between fast-forward and non-fast-forward merges ultimately depends on your team's needs and preferences. For projects that benefit from clear feature boundaries and comprehensive history, non-fast-forward merges are often the right choice. Understanding when and how to use them effectively will make you a more capable Git user and a better collaborator.

Top comments (0)