0

I am working on my own branch, b. I rebased it to one of the more current branches "dev_x" which everyone is working on and pushed it to the origin. All good. Now I have done a week's work and want to push my branch b updates to the origin as I am traveling and my laptop could get stolen.

The problem is I get the error "Updates were rejected because the tip of your current branch is behind". I looked in the bitbucket commit history, and no one has committed to my branch. Obviously, "dev_x" branch has moved on, but that should not stop me from pushing. I could do a git pull, but there is nothing to pull as no one except me has touched branch b?

git status says: On branch b Your branch and 'origin/b' have diverged, and have 196 and 1 different commits each, respectively. (use "git pull" to merge the remote branch into yours)

This seems to be saying that someone has committed one thing to my branch, but a) I would like to see what it is before pulling it, and b) according to bitbucket, no one has committed to this branch.

I decided to bite the bullet a do "git pull".

It now says there are 30 merge conflicts - it's showing every file I have worked on in the last week and committed locally to my branch.

Help! How do I undo what pull has done, and how do I rescue my work (e.g. pushing to a different branch).

Lin Du
  • 88,126
  • 95
  • 281
  • 483
John Little
  • 10,707
  • 19
  • 86
  • 158
  • 1
    Rebasing creates a divergence. You'll need to delete the remote and then push, or force it. – isherwood Apr 25 '19 at 20:30
  • 3
    After a `git rebase` you will *always* have to `git push --force`. Use `git merge --abort` to escape your current situation and then force-push your changes. – user229044 Apr 25 '19 at 20:30
  • thanks @meagar you saved my life. "git merge --abort" got be back to pre-pull. – John Little Apr 25 '19 at 20:35
  • @isherwood it sounds like rebase is bad if I have to delete the origin branch each time (or force). Perhaps I should have just merged in stead of rebase. I read rebase was better for history. – John Little Apr 25 '19 at 20:37
  • Yes indeed. I stopped using rebase about five minutes after I started, history be damned. :D There are usually other options. – isherwood Apr 25 '19 at 20:47
  • 2
    Rebase isn't *bad* but neither is it *good*. It's more chaotic neutral, perhaps :-) ... more seriously, the complaint you get is because you're competing with someone else to determine which commits to remember. The "someone" that you're competing with is *you*, when you told the other Git: *remember these commits*. Now you're telling it *enh, forget **those** commits, use the shiny new replacements instead.* – torek Apr 25 '19 at 21:26
  • Rebasing isn't something to avoid so long as you understand it. Use `-i` and be aware of the commits you're moving around and it's really straight forward. – user229044 Apr 25 '19 at 23:55

0 Answers0