Is there a difference between git rebase and git merge --ff-only

Yes, --ff-only will always fail where a plain git merge would fail, and might fail where a plain git merge would succeed. That's the point - if you're trying to keep a linear history, and the merge can't be done that way, you want it to fail.

An option that adds failure cases to a command isn't useless; it's a way of validating a precondition, so if the current state of the system isn't what you expect, you don't make the problem worse.

Yes, there is a difference. git merge --ff-only will abort if it cannot fast forward, and takes a commit (normally a branch) to merge in. It will only create a merge commit if it can't fast forward (i.e. will never do so with --ff-only).

git rebase rewrites history on the current branch, or can be used to rebase an existing branch onto an existing branch. In that instance it won't create a merge commit because it's rebasing, rather than merging.

Note that git rebase has a different job than git merge (with or without --ff-only). What rebase does is to take existing commits and copy them. Suppose, for instance, that you're on branch1 and have made two commits A and B:

...-o--o--A--B   <-- HEAD=branch1
        \
         o--C    <-- branch2

and you decide that you'd rather have those two commits be on branch2 instead. You can:

• get a list of changes you made in A (diff A against its parent)
• get a list of changes you made in B (diff B against A)
• switch to branch2
• make the same changes you made in A and commit them, copying your commit message from A; let's call this commit A'
• and then make the same changes you made in B and commit them, copying your commit message from B; let's call this B'.

There's a git command that does this diff-and-then-copy-and-commit for you: git cherry-pick. So:

git checkout branch2      # switch HEAD to branch2 (commit C)
git cherry-pick branch1^  # this copies A to A'
git cherry-pick branch1   # and this copies B to B'

Now you have this:

...-o--o--A--B         <-- branch1
        \
         o--C--A'-B'   <-- HEAD=branch2

Now you can switch back to branch1 and delete your original A and B, using git reset (I'll use --hard here, it's more convenient that way as it cleans up the work-tree too):

git checkout branch1
git reset --hard HEAD~2

This removes the original A and B,¹ so now you have:

...-o--o               <-- HEAD=branch1
        \
         o--C--A'-B'   <-- branch2

Now you just need to re-check-out branch2 to continue working there.

This is what git rebase does: it "moves" commits (though not by actually moving them, because it can't: in git, a commit can never be changed, so even just changing the parent-ID requires copying it to new and slightly different commit).

In other words, while git cherry-pick is an automated diff-and-redo of one commit, git rebase is an automated process of redoing multiple commits, plus, at the end, moving labels around to "forget" or hide-away the originals.

The above illustrates moving commits from one local branch branch1 to another local branch branch2, but git uses the exact same process to move commits when you have a remote-tracking branch that acquires some new commits when you do a git fetch (including the fetch that is the first step of git pull). You might start by working on branch feature, that has an upstream of origin/feature, and make a couple of commits of your own:

...-o        <-- origin/feature
     \
      A--B   <-- HEAD=feature

But then you decide you should see what has happened upstream, so you run git fetch,² and, aha, someone upstream wrote a commit C:

...-o--C     <-- origin/feature
     \
      A--B   <-- HEAD=feature

At this point you can simply rebase your feature's A and B onto C, giving:

...-o--C     <-- origin/feature
        \
         A'-B'  <-- HEAD=feature

These are copies of your original A and B, with the originals being thrown away (but see footnote 1) after the copies are complete.

---

Sometimes there's nothing to rebase, i.e., no work that you yourself did. That is, the graph before the fetch look like this:

...-o      <-- origin/feature
           `-- HEAD=feature

If you then git fetch and commit C comes in, though, you're left with your feature branch pointing to the old commit, while origin/feature has moved forward:

...-o--C   <-- origin/feature
     `---- <-- HEAD=feature

This is where git merge --ff-only comes in: if you ask to merge your current branch feature with origin/feature, git sees that it's possible to just slide the arrow forward, as it were, so that feature points directly to commit C. No actual merge is required.

If you had your own commits A and B, though, and you asked to merge those with C, git would do a real merge, making a new merge commit M:

...-o--C        <-- origin/feature
     \   `-_
      A--B--M   <-- feature

Here, --ff-only will stop and give you an error. Rebase, on the other hand, can copy A and B to A' and B' and then hide away the original A and B.

So, in short (ok, too late :-) ), they simply do different things. Sometimes the result is the same, and sometimes it's not. If it's OK to copy A and B, you can use git rebase; but if there's some good reason not to copy them, you can use git merge, perhaps with --ff-only, to merge-or-fail as appropriate.

---

¹Git actually keeps the originals for some time—normally a month in this case—but it hides them away. The easiest way to find them is with git's "reflogs", which keep a history of where each branch pointed, and where HEAD pointed, before each change that updated the branch and/or HEAD.

Eventually the reflog history entries expire, at which point these commits become eligible for garbage collection.

²Or, again, you can use git pull, which is a convenience script that starts by running git fetch. Once the fetch is done, the convenience script runs either git merge or git rebase, depending on how you configure and run it.