git rebase and git push: non-fast forward, why use?

Question

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 rebas

Answer 1

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.

Answer 2

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  -> ffffdd   -> 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  -> ffffdd   -> 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..mirror is set.

---

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.