Take the 2-minute tour ×

Coming from mercurial, I'm using 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. While merging the feature I realized that git uses fast-forward, i.e. 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 the default approach of git (fast-forward merging) my history would result in one giant master branch. Nobody knows that I used a separate branch for every feature, because in the end I only have that giant master branch. Doesn't that look unprofessional?

Due to this reasoning I don't want fast-forward merging as the default behaviour of git and can't see a good reason why it is the default. Maybe there are reasons, but what's so striking about it, that it has to be the default action?

share|improve this question
Note: see also sandofsky.com/blog/git-workflow.html, and avoid the 'no-ff' with its "checkpoint commits" that break bisect or blame. –  VonC Aug 1 '11 at 21:42
do u regret using git on a one man project? –  HaveAGuess Oct 19 '11 at 0:11
Absolutely not! In my work folder I have 7 one-man projects where I use git. Let me rephrase that: I started many projects since I asked this question and all of them are versioned via git. As far as I know, only git and mercurial support local versioning, which is essential to me since I got used to it. It's easy to set it up and you always have the whole history with you. In group projects its even better, since you can commit without interfering anyone with your work-in-progress code. In addition I use github to share some of my projects (e.g. micro-optparse) where git is an requirement. –  Florian Pilz Oct 20 '11 at 17:39
@Cawas true, -no-ff is rarely a good idea, but can still help keep an feature-internal history while recording only one commit on the main branch. That makes sense for long feature history, when you merge from time to time its progression on the main branch. –  VonC May 16 '12 at 21:22
By the way, to your question of "Doesn't that [a linear branch history] look unprofessional?". There's nothing unprofessional about using a source code system with it's defaults. This isn't about professionalism. This is about determining which philosophy of branching you subscribe you. For example, @VonC linked to sandofsky's article where he champions using fast forward as a superior approach. Not right or wrong, just different philosophies for different contexts. –  Marplesoft Jan 4 '13 at 16:08
show 8 more comments

2 Answers

up vote 456 down vote accepted

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.

alt text
(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


Jakub Narębski also mentions the config merge.ff:

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.

share|improve this answer
Wow that was fast. ;) I know about the --no-ff option, but only find out about fast-forward after I screwed up my feature. I see some sense in fast-forward for short living branches, but making it the default action means, that git assumes you most often have such short living branches. Reasonable? –  Florian Pilz May 17 '10 at 15:35
@Florian: I believe this is a reasonable view of the process. I have added an example of a config which will setup the way you want to manage merge to master. –  VonC May 17 '10 at 15:42
Thanks, the config file should help to avoid such gotchas. :) Only applied this configuration locally with "git config branch.master.mergeoptions '--no-ff'" –  Florian Pilz May 17 '10 at 15:48
@BehrangSaeedzadeh: rebasing is an other topic (that hasn't been mentioned onced in this page): as long as you haven't push your feature branch to a public repo, you can rebase it on top of master as many times as you want. See stackoverflow.com/questions/5250817/… –  VonC Oct 28 '11 at 4:03
@BehrangSaeedzadeh: a rebase by itself won't make an history linear. It is how you integrate the changes of your feature branch back into master that makes said history linear or not. A simple fast-foward merge will make it linear. Which makes sense if you have cleaned the history of that feature branch before the fast-forward merge, leaving only significant commits, as mentioned in stackoverflow.com/questions/7425541/…. –  VonC Oct 28 '11 at 5:43
show 17 more comments

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.


share|improve this answer
Very interesting. +1 –  VonC May 31 '13 at 14:22
Regarding feature branches from stable releases: What if a feature I'm developing for the next release depends on the changes for another feature that I've already developed and merged into master? Surely that means I have to create this second feature branch from master? –  dOxxx May 31 '13 at 15:08
@dOxxx: Yes, there are exceptions, like e.g. where one branch builds on the other (either directly, or after merging previous into master). –  Jakub Narębski May 31 '13 at 15:50
add comment

Your Answer


