git rebase and git push: non-fast forward, why use?
GitMergeRebaseGit Problem Overview
I have a branch that should be available to other contributors and that should constantly stay up to date with the master.
Unfortunately, every time I do 'git rebase' and then try to push, it results in 'non-fast forward' message and abortion of pushing. The only way to push here is to use --force. Does that mean I should use 'git merge' instead of rebasing if my branch went public and others are working on it?
Git Solutions
Solution 1 - Git
A few notes on how git works (non technical):
When you rebase, git takes the commits in question, and "recommits" them on top of a clean history. This is to prevent the history from showing:
Description: tree -> mywork -> merge -> mywork -> merge -> mywork -> merge
Commit SHA1: aaaa -> bbbb -> cccc -> dddd -> eeee -> ffff -> gggg
After a rebase, it may look like this (or similar):
Description: tree -> rebase
Commit SHA1: aaaa -> hhhh
The issue is that the new commit you are attempting to push out there is NOT a descendant of the commit on the tip of the branch you are pushing to.
Now, you know that the same info is in the commits, but git is being responsible by not just overwriting those commits out there (bbbb-gggg in the example above).
Shared Repo Model
If you are using a shared repository, then things like this can get mighty confusing. Let me explain why. Say another developer pulled down the branch, and they have commits aaaa -> gggg in their branch. Then they make a commit iiii
In the meanwhile, you rebased and forced a push, causing the tree to look like this:
Description: tree -> rebase
Commit SHA1: aaaa -> hhhh
When the other developer tries to push, he gets a "non-fast forward" message. When he does a merge, then both histories are RELINKED together, and you end up with a mess
Something like this (messy):
Description: tree -> rebase -> mywork -> merge -> mywork -> merge -> mywork -> merge -> devwork -> merge
Commit SHA1: aaaa -> hhhh -> bbbb -> cccc -> dddd -> eeee -> ffff -> gggg -> iiii -> jjjj
IN other words, if others are pulling AND pushing, it's better that you stick with git merge, or AVOID PUSHING until after the rebase (and only rebase your work).
Publicly Visible Repository Model
Perhaps you are using a different (more gittish) model where you just want people to be able to pull from your repo. In this case, git push --force isn't too bad, because then they can deal with keeping up with it. They can rebase their changes to be on top of your changes before giving their patches to you. It prevents your repo from getting all messed up.
However, there may be a better way for you. git push --mirror
From http://www.kernel.org/pub/software/scm/git/docs/git-push.html
> Instead of naming each ref to push, specifies that all refs under
> $GIT_DIR/refs/ (which includes but is
> not limited to refs/heads/,
> refs/remotes/, and refs/tags/) be
> mirrored to the remote repository.
> Newly created local refs will be
> pushed to the remote end, locally
> updated refs will be force updated on
> the remote end, and deleted refs will
> be removed from the remote end. This
> is the default if the configuration
> option remote.
One of the great things about git is that it is very flexible and allows for many different kind of workflows. But it's real strength lies in the fact that it is a distributed model, so I believe that the most ROI can be reaped by using it that way.
Solution 2 - Git
No, rebase is perfectly legal with public repositories and may even be desirable to keep the history fluent. Just keep in mind that you must not use rebase to rewrite the history of remotely published commits. That is, rebase can only be applied to your own, local, commits that you have never published. You use rebase to place your commits on top of them when fetch and then, perhaps, adjust them there. Another reason that you may receive such message is that the branch you pushing was updated and you need to synchronize -- fetch and rebase your commits on top of what you have fetched.