Akhil Bhadwal | 14 Dec, 2023

Difference Between Git Merge and Git Merge --no-ff


Git is a version control system or VCS that is primarily employed for source code management and also for keeping track of changes made to a file or a set of files. It enables streamlining the individual processes of multiple developers working on the same project.

Simply put, Git bridges the gap between the individual working of various developers assigned to a single task and the desired output. One of the top Git commands is the git merge. It has several variations, including the git merge --no-ff command.

Although the basic function that the two git commands perform is the same i.e., merging two or more branches into a single branch, there is some level of distinction among the two variations of the Git merge command that must be known so as to put these two to the best use possible.

But before comparing the two git commands, let’s first understand what does the git merge operation exactly means and some other related concepts, namely fast-forward merge and 3-way merge.

The Git Merge Command

The git merge command takes different lines of development created by the git branch and combines them into a single branch. Although the current branch is updated to reflect the resulting merge, the target branch remains unaltered. The git command is usually used with:

  • git checkout - Selects the current branch.
  • git branch -d - Deletes the obsolete target branch.

The Process

The Git merge command combines (merges) many commit sequences into a single, unified history. The command starts by accepting two commit pointers that are typically the most recent commits in the two branches that are to be merged.

Next, it starts looking for a common base commit for the two. When found, the git merge command creates a new merge commit, which combines the changes made by each one of the two queued merge commit sequences.

A merge commit is unique as compared to other commits in the way that it has two parent commits. Git automatically tries to merge the separate histories when creating a merge commit. In case it comes across data that is altered in both histories, user intervention is required.

The Preparation

For ensuring a smooth merge process, the following things need to be taken care of prior to performing the merge commit:

  • Confirming the Receiving Branch - To do so, execute the git status command for ensuring that the HEAD is pointing to the relevant merge-receiving branch. If not, use the git checkout <branch> command to switch to the desired receiving branch.
  • Fetching the Latest Remote Commits - Ensure that the receiving and merging branches are as per the latest remote changes by executing the Git fetch command, for pulling the latest remote commits, followed by the Git pull command that is for ensuring that the master branch has the latest updates.

The Fast Forward Merge and the 3-way Merge

A fast-forward merge is when the Git moves the branch pointer to point at the incoming commit rather than constructing a merge commit. Although this typically happens when performing a git pull command without any local changes, it can also happen for a git merge command.

Because all of the commits reachable from the target branch are now available through the current branch, the fast forward merge combines the histories of the two branches. A fast-forward merge, however, isn’t possible when the branches have diverged.

Git combines two branches using the 3-way merge when there isn’t a linear path to the target branch. It uses a dedicated commit to tie the two histories together. It is called so because, in the 3-way merge, Git uses three commits to generate the merge commit; two branch tips and their common ancestor.

Typically, the fast forward merge is used by developers for small features or bug fixes while the 3-way merge is reserved for integrating longer-running features.

git merge vs. git merge --no-ff

Usually, developers leverage the git merge command to merge two branches. The git command merges (combines) two or more commits into a single history. It’s general syntax is:

git merge <branch>

By default, the git merge command is a fast-forward merge. A fast-forward merge is possible when there is a linear path from the current branch tip to the target branch.

In this scenario, rather than actually merging the two branches, Git integrates the histories, i.e., previous commits, that are to move the current branch tip up to the target branch tip.

For scenarios that require a merge commit during a fast forward merge, we use the Git merge command with the --no-ff flag. The general syntax for this git command is:

git merge --no-ff <branch>

The Git merge --no-ff command merges the specified branch into the command in the current branch and ensures performing a merge commit even when it is a fast-forward merge. It helps in record-keeping of all performed merge commands in the concerning git repo.

Using the --no-ff parameter prevents the Git merge command from performing a fast-forward merge when Git detects that the current HEAD is an ancestor of the commit that you’re trying to merge.

No Fast-forward Merge

At most times, the fast forward merge is preferred. Sometimes, however, there might be a requirement to prevent the fast-forward merge from happening. Typically, this is when maintaining a definite branch topology.

For doing so, the --no-ff parameter can be passed with the git merge command. Resultantly, the git merge command will construct a commit merge rather than fast-forwarding.

What if the git merge can’t fast-forward?

What if you wish to perform the Git merge command for explicitly performing a fast-forward merge and need to withdraw if it can’t fast-forward? Is there some way to do so? Yes, there is.

For doing so, instead of using the --no-ff parameter, you must use the --ff-only parameter. In such a scenario, you can go back and decide whether to merge or rebase if some error occurs during the process.

How to Merge More Than 2 Branches?

The git merge command provides support for a range of merging strategies. For merging more than two branches, two strategies are available:

1. Octopus

This Git merging strategy is mainly used for merging topic branch heads. It is the default merge strategy while pulling or merging more than a single branch. Hence, this is the strategy used when merging two branches.

Although the octopus merge strategy is suitable for resolving cases with more than two heads, it can’t be used for performing a complex merge requiring manual resolution.

2. Ours

Ours merge strategy resolves any number of heads. The resulting tree of the merge, however, belongs to that of the current branch head and ignores all changes from the remaining branches. It is typically used to supplant the old development history of the side branches.

The Git & Github Bootcamp

Git Merge and Git Merge --no-ff: Head-to-Head Comparison


Git Merge

Git Merge --no-ff


Merges two branches

Integrates the histories


git merge <branch>

git merge --no-ff <branch>

Fast Forward




By now, you must be clear with the difference between the git merge and Git merge --no-ff commands. Understanding the difference is important to put both the git commands to the appropriate use.

Spotted something wrong/misleading information in the article? Apologies! Please share the same with us via the dedicated comments section below to help us mend it ASAP. Thanks already. Want to improve your Git skills? Try these best Git tutorials.

People are also reading:


By Akhil Bhadwal

A Computer Science graduate interested in mixing up imagination and knowledge into enticing words. Been in the big bad world of content writing since 2014. In his free time, Akhil likes to play cards, do guitar jam, and write weird fiction.

View all post by the author

Subscribe to our Newsletter for Articles, News, & Jobs.

Thanks for subscribing! Look out for our welcome email to verify your email and get our free newsletters.

Disclosure: Hackr.io is supported by its audience. When you purchase through links on our site, we may earn an affiliate commission.

In this article

Learn More

Please login to leave comments