Why does git perform fast-forward merges by default

Question

Coming from mercurial  I use branches to organize features  Naturally  I want to see this work-flow in my history as well   I started my new project using git and finished my first feature  When merging the feature  I realized git uses fast-forward  i e  it applies my changes directly to the master branch if possible and forgets about my branch   So to think into the future  I m the only one working on this project  If I use git s default approach  fast-forward merging   my history would result in one giant master branch  Nobody knows I used a separate branch for every feature  because in the end I ll have only that giant master branch  Won t that look unprofessional   By this reasoning  I don t want fast-forward merging and can t see why it is the default  What s so good about it

User · Answer

Let me expand a bit on a VonC s very comprehensive answer     First  if I remember it correctly  the fact that Git by default doesn t create merge commits in the fast-forward case has come from considering single-branch  equal repositories   where mutual pull is used to sync those two repositories  a workflow you can find as first example in most user s documentation  including  The Git User s Manual  and  Version Control by Example     In this case you don t use pull to merge fully realized branch  you use it to keep up with other work   You don t want to have ephemeral and unimportant fact when you happen to do a sync saved and stored in repository  saved for the future   Note that usefulness of feature branches and of having multiple branches in single repository came only later  with more widespread usage of VCS with good merging support  and with trying various merge-based workflows   That is why for example Mercurial originally supported only one branch per repository  plus anonymous tips for tracking remote branches   as seen in older revisions of  Mercurial  The Definitive Guide      Second  when following best practices of using feature branches  namely that feature branches should all start from stable version  usually from last release   to be able to cherry-pick and select which features to include by selecting which feature branches to merge  you are usually not in fast-forward situation    which makes this issue moot   You need to worry about creating a true merge and not fast-forward when merging a very first branch  assuming that you don t put single-commit changes directly on  master    all other later merges are of course in non fast-forward situation   HTH

User · Answer

Fast-forward merging makes sense for short-lived branches  but in a more complex history  non-fast-forward merging may make the history easier to understand  and make it easier to revert a group of commits   Warning  Non-fast-forwarding has potential side effects as well  Please review https   sandofsky com blog git-workflow html  avoid the  no-ff  with its  checkpoint commits  that break bisect or blame  and carefully consider whether it should be your default approach for master     From nvie com  Vincent Driessen  post  A successful Git branching model       Incorporating a finished feature on develop      Finished features may be merged into the develop branch to add them to the upcoming release      git checkout develop Switched to branch  develop    git merge --no-ff myfeature Updating ea1b82a  05e9557  Summary of changes    git branch -d myfeature Deleted branch myfeature  was 05e9557     git push origin develop      The --no-ff flag causes the merge to always create a new commit object  even if the merge could be performed with a fast-forward  This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature    Jakub Narebski also mentions the config merge ff      By default  Git does not create an extra merge commit when merging a commit that is a descendant of the current commit  Instead  the tip of the current branch is fast-forwarded    When set to false  this variable tells Git to create an extra merge commit in such a case  equivalent to giving the --no-ff option from the command line     When set to  only   only such fast-forward merges are allowed  equivalent to giving the --ff-only option from the command line       The fast-forward is the default because    short-lived branches are very easy to create and use in Git short-lived branches often isolate many commits that can be reorganized freely within that branch those commits are actually part of the main branch  once reorganized  the main branch is fast-forwarded to include them    But if you anticipate an iterative workflow on one topic feature branch  i e   I merge  then I go back to this feature branch and add some more commits   then it is useful to include only the merge in the main branch  rather than all the intermediate commits of the feature branch   In this case  you can end up setting this kind of config file    branch  master     This is the list of cmdline options that should be added to git-merge    when I merge commits into the master branch     The option --no-commit instructs git not to commit the merge   by default  This allows me to do some final adjustment to the commit log   message before it gets commited  I often use this to add extra info to   the merge message or rewrite my local branch names in the commit message   to branch names that are more understandable to the casual reader of the git log     Option --no-ff instructs git to always record a merge commit  even if   the branch being merged into can be fast-forwarded  This is often the   case when you create a short-lived topic branch which tracks master  do   some changes on the topic branch and then merge the changes into the   master which remained unchanged while you were doing your work on the   topic branch  In this case the master branch can be fast-forwarded  that   is the tip of the master branch can be updated to point to the tip of   the topic branch  and this is what git does by default  With --no-ff   option set  git creates a real merge commit which records the fact that   another branch was merged  I find this easier to understand and read in   the log   mergeoptions   --no-commit --no-ff     The OP adds in the comments      I see some sense in fast-forward for  short-lived  branches  but making it the default action means that git assumes you    often have  short-lived  branches  Reasonable    Jefromi answers      I think the lifetime of branches varies greatly from user to user  Among experienced users  though  there s probably a tendency to have far more short-lived branches        To me  a short-lived branch is one that I create in order to make a certain operation easier  rebasing  likely  or quick patching and testing   and then immediately delete once I m done    That means it likely should be absorbed into the topic branch it forked from  and the topic branch will be merged as one branch  No one needs to know what I did internally in order to create the series of commits implementing that given feature     More generally  I add      it really depends on your development workflow           if it is linear  one branch makes sense      If you need to isolate features and work on them for a long period of time and repeatedly merge them  several branches make sense           See  When should you branch     Actually  when you consider the Mercurial branch model  it is at its core one branch per repository  even though you can create anonymous heads  bookmarks and even named branches  See  Git and Mercurial - Compare and Contrast       Mercurial  by default  uses anonymous lightweight codelines  which in its terminology are called  heads     Git uses lightweight named branches  with injective mapping to map names of branches in remote repository to names of remote-tracking branches    Git  forces  you to name branches  well  with the exception of a single unnamed branch  which is a situation called a  detached HEAD    but I think this works better with branch-heavy workflows such as topic branch workflow  meaning multiple branches in a single repository paradigm

[git] Why does git perform fast-forward merges by default?

Examples related to git

Examples related to git-branch

Examples related to git-merge

Examples related to fast-forward