Can someone please provide a simple example of what would cause a Git push to a central repo to fail because a fast forward could not occur? What would the local repo vs the central repo's state need to look like in order for this to occur? Really having trouble visualizing this...
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.
If you do a commit in one project and then accidentally push this commit, with bypassing code review, to another project, this will fail with the error message 'non-fast forward'. To fix the problem you should check the push specification and verify that you are pushing the commit to the correct project.
A fast-forward merge can occur when there is a linear path from the current branch tip to the target branch. Instead of “actually” merging the branches, all Git has to do to integrate the histories is move (i.e., “fast forward”) the current branch tip up to the target branch tip.
[Solved] Fatal: Not possible to fast-forward, aborting git. 315,662 Solution 1. Your branch is no longer directly based off of the branch you're trying to merge it into - e.g. another commit was added to the destination branch that isn't in your branch. Thus, you can't fast-forward into it (because fast ...
I assume you're seeing this problem:
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '/Users/mayoff/t/test/central'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
Here's how the “non-fast-forward updates were rejected” problem happens.
Let's say Alice and Bob are working on a project. They each have a repository, and there's a central repository they both push to and pull from. Initially, the three repositories look like this:
Now Alice and Bob both do some work. Each commits a different change to their local repository:
Next, Alice pushes her change to the central repo:
Next, Bob tries to push. The central repo's master branch points at commit 3. Bob's push tries to update it to point at commit 4. Since commit 4 doesn't have commit 3 as an ancestor, a merge is required, but git push
doesn't do real merges. It only does “fast-forwards”, where the new master has the old master as an ancestor. So Bob gets the error because he's trying to push something that requires a real merge, not a fast-forward.
To push successfully, Bob has to first fetch the new commit from the central repo:
and he has to merge his changes (commit #4) with Alice's changes (commit #3), creating a new commit that has both commits as ancestors:
The fetch and merge can be done in two commands (git fetch
followed by git merge
) or in one command (git pull
).
Now Bob can push successfully, because the central repo sees that the new master has the old master as an ancestor.
Notice that now Alice is missing Bob's commits. If she makes more commits to her repo and tries to push before pulling from the central repo, she'll get the non-fast-forward error, and she'll have to fetch and merge to fix it, just like Bob did.
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