Git fast forward VS no fast forward merge

Question

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

User · Answer

It is possible also that one may want to have personalized feature branches where code is just placed at the end of day. That permits to track development in finer detail.

I would not want to pollute master development with non-working code, thus doing --no-ff may just be what one is looking for.

As a side note, it may not be necessary to commit working code on a personalized branch, since history can be rewritten git rebase -i and forced on the server as long as nobody else is working on that same branch.

User · Answer

When we work on development environment and merge our code to staging production branch then Git no fast forward can be a better option  Usually when we work in development branch for a single feature we tend to have multiple commits  Tracking changes with multiple commits can be inconvenient later on  If we merge with staging production branch using Git no fast forward then it will have  only 1 commit  Now anytime we want to revert the feature  just revert that commit  Life is easy

User · Answer

I can give an example commonly seen in project    Here  option --no-ff  i e  true merge  creates a new commit with multiple parents  and provides a better history tracking  Otherwise  --ff  i e  fast-forward merge  is by default     git checkout master   git checkout -b newFeature         git commit -m  work from day 1          git commit -m  work from day 2          git commit -m  finish the feature    git checkout master   git merge --no-ff newFeature -m  add new feature    git log    something like below commit  add new feature               gt  commit created at merge with proper message commit  finish the feature  commit  work from day 2  commit  work from day 1    gitk                                gt  see details with graph    git checkout -b anotherFeature             gt  create a new branch             git commit -m  work from day 3          git commit -m  work from day 4          git commit -m  finish another feature    git checkout master   git merge anotherFeature          --ff is by default  message will be ignored   git log    something like below commit  work from day 4  commit  work from day 3  commit  add new feature  commit  finish the feature  commit       gitk                                gt  see details with graph       Note that here if the newFeature branch is re-used  instead of creating a new branch  git will have to do a --no-ff merge anyway  This means fast forward merge is not always eligible

User · Answer

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

[git] Git fast forward VS no fast forward merge

Examples related to git