Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Git fast forward VS no fast forward merge

Tags:

git

Git merge allow us to perform fast forward and no fast fast forward branch merging. Any ideas when to use fast forward merge and when to use no fast forward merge?

like image 985
Chau Chee Yang Avatar asked Jul 14 '11 23:07

Chau Chee Yang


People also ask

What is Fast Forward and non-Fast-forward in git?

A non-fast-forward merge is a merge where the main branch had intervening changes between the branch point and the merge back to the main branch. In this case, a user can simulate a fast-forward by rebasing rather than merging. Rebasing works by abandoning some commits and creating new ones.

Should I fast forward in git?

A Git fast forward is an extremely useful and efficient mechanism for harmonizing your project's main branch with changes introduced in a given feature branch. Git makes ample use of fast-forwarding merges behind the scenes, speeding up your development workflow in the process.

What is Fast forward only in Git?

Fast forward merge can be performed when there is a direct linear path from the source branch to the target branch. In fast-forward merge, git simply moves the source branch pointer to the target branch pointer without creating an extra merge commit.

What are the disadvantages of Fast Forward merge in Git?

The drawback of merge commit is that it becomes hard to read and understand the commit history, especially when we have many branches. If your team prefers to keep a linear history of branches, then one should go for fast forward merge. Disabling fast forward merge will create merge commits, which pollutes the commit history.

What is a fast forward commit in Git?

A fast-forward is when, instead of constructing a merge commit, git just moves your branch pointer to point at the incoming commit. This commonly occurs when doing a git pull without any local changes.

When to use Fast Forward merge and when to use no-FF?

Git merge allow us to perform fast forward and no fast fast forward branch merging. Any ideas when to use fast forward merge and when to use no fast forward merge? Show activity on this post. The --no-ff option is useful when you want to have a clear notion of your feature branch.

What is the difference between REBASE and Fast Forward in Git?

@ThanosFisherman, Fast-Forward maintains the same base and tries to merge all file changes from the same changes after the shared base. A rebase "detaches" your branch, and then applies commit after commit on top of the base (as if you just checked out a fresh e.g. master branch), and THEN, tries to, apply the changes done on the new base.


1 Answers

The --no-ff option is useful when you want to have a clear notion of your feature branch. So even if in the meantime no commits were made, FF is possible - you still want sometimes to have each commit in the mainline correspond to one feature. So you treat a feature branch with a bunch of commits as a single unit, and merge them as a single unit. It is clear from your history when you do feature branch merging with --no-ff.

If you do not care about such thing - you could probably get away with FF whenever it is possible. Thus you will have more svn-like feeling of workflow.

For example, the author of this article thinks that --no-ff option should be default and his reasoning is close to that I outlined above:

Consider the situation where a series of minor commits on the "feature" branch collectively make up one new feature: If you just do "git merge feature_branch" without --no-ff, "it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache [if --no-ff is not used], whereas it is easily done if the --no-ff flag was used [because it's just one commit]."

Graphic showing how --no-ff groups together all commits from feature branch into one commit on master branch

like image 70
Ivan Danilov Avatar answered Sep 17 '22 15:09

Ivan Danilov