I have many short-lived branches in my workflow and I would like them to be separated. So, I plan to use git config --add merge.ff false
. However, when I am doing a pull (which I understand is fetch+merge) - then I want a fast-forward behavior, to avoid unnecessary extra commit here.
Is this a good thing to do? Is this possible?
In the event that you require a merge commit during a fast forward merge for record keeping purposes you can execute git merge with the --no-ff option. This command merges the specified branch into the current branch, but always generates a merge commit (even if it was a fast-forward merge).
Fast-forward merges literally move your main branch's tip forward to the end of your feature branch. This keeps all commits created in your feature branch sequential while integrating it neatly back into your main branch.
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.
Note: Git 2.0 (Q2 2014) will introduce with commit b814da8 a config push.ff
:
pull.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).
Initial answer (October 2012)
Try a:
git pull --ff
It should take precedence on your merge config setting.
It will pass the --ff
option to the underlying merge within the git pull command.
Beware of the --no-ff
option though, as mentioned in "Understanding the Git Workflow"
With enough flags you can force Git to act the way you think it should instead of the way it wants to. But that’s like using a screwdriver like a hammer; it gets the job done, but it’s done poorly, takes longer, and damages the screwdriver.
Consider how a common Git workflow falls apart.
Create a branch off Master,
do work,
and merge it back into Master when you’re done
Most of the time this behaves as you expect because Master changed since you branched. Then one day you merge a feature branch into Master, but Master hasn’t diverged. Instead of creating a merge commit, Git points Master to the latest commit on the feature branch, or “fast forwards.” (Diagram)
Unfortunately, your feature branch contained checkpoint commits, frequent commits that back up your work but captures the code in an unstable state. Now these commits are indistinguishable from Master’s stable commits. You could easily roll back into a disaster.
So you add a new rule: “When you merge in your feature branch, use
–no-ff
to force a new commit.” This gets the job done, and you move on.Then one day you discover a critical bug in production, and you need to track down when it was introduced. You run
bisect
but keep landing on checkpoint commits. You give up and investigate by hand.You narrow the bug to a single file. You run
blame
to see how it changed in the last 48 hours. You know it’s impossible, butblame
reports the file hasn’t been touched in weeks.
It turns outblame
reports changes for the time of the initial commit, not when merged. Your first checkpoint commit modified this file weeks ago, but the change was merged in today.The
no-ff
band-aid, broken bisect, and blame mysteries are all symptoms that you’re using a screwdriver as a hammer.
For more, see:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With