Git: can't get branch commited after rebase

Question

I use Eclipse with EGit. I use a remote repository and I'm the only one working on it

I have a git repository that at some point looked something like this

A-B-C-D-E (Master)
     \
      C1-C2-C3 (branch: New_Design)

I then rebased my New_Design branch with Master to bring it into line with E

I understand this to mean it then should look like this

A-B-C-D-E (Master)
         \
          C1-C2-C3 (branch: New_Design)

When I subsequently added more changes to New_Design and committed all seemed to work.

A-B-C-D-E (Master)
         \
          C1-C2-C3-C4-C5-C6 (branch: New_Design)

But when I checked the remote repository, none of the commits were registered. The last commit that actually arrived was the post rebase commit.

When I go to the command line (EGit sometimes seems to swallow certain errors), I see this

To https://repo@bitbucket.org/project/project-web.git
! [rejected]        New_Design -> New_Design (non-fast-forward)
error: failed to push some refs to    'https://repo@bitbucket.org/project/project-web.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.

I tried that and executed

git pull -origin New_Design

as a result of this my project was overwritten with the old version from the repo. I saw all sorts of merge conflict with the default option Eclipse kept offering me was to accept the "old" version. Fortunately, I had made a local backup of the directory structure before this action and I basically overwrote it with the pre git pull disaster.

So, now I want to know what is the best way forward to get my stuff in the remote repository?

Answer 1

When you rebase commits that have already been pushed to a remote repository, you need to specify the force flag when you push your newly rebased branch up to the remote.

git push origin New_Design -f 

Why this happens

Your remote branch looks like:

A - B - C - C1 - C2 - C3

Following the rebase, your local branch looks like:

A - B - C - D - E - C1' - C2' - C3' - C4 - C5 - C6

To git, this looks like you've removed the commits C1, C2, and C3. In reality, the same (or very similar, unless you manually resolved conflicts) set of changes is contained in C1', C2', and C3', so you won't lose work in this case. Since git can't know for sure, it makes you verify that you really want to do this by requiring the -f flag.

Force pushing can result in lost work on the remote branch in a variety of situations:

• If you have other people working on the remote repository and their changes aren't reflected in your local branch. Git is suggesting git pull to remedy this situation.
• If you've rewritten history on your local branch and removed or changed commits.

Since you're working alone, you're safe to do a force push if you're happy with your local branch.