0

I realize this might be a common problem, but so far I was not able to find a good solution via google/so search.

I have the following git branch setup:

$ git branch -a
* my_feature
  main
  remotes/origin/HEAD -> origin/main
  remotes/origin/colleagues_feature
  remotes/origin/my_feature
  remotes/origin/main

With the PR of my_feature pretty much done, I wanted to rebase it on main (where a colleages feature PR was merged in the meanwhile) and then finally implement some needed additions to let my colleages feature work together with mine.

I guess what I should have done was:

 1. Commit my changes
 2. git checkout main
 3. git pull
 4. git checkout my_feature
 5. git rebase main
 6. git push

But what I did was:

 1. Commit my changes
 2. git push 
 3. git rebase main (with main being up to date with remote/origin)
 4. git push

The last step now fails due to merge conflicts, git status prints the following message:

$ git status
On branch my_feature
Your branch and 'origin/my_feature' have diverged,
and have 17 and 5 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean

After rebasing my local branch looks as expected, everything as I want/need it. I understand why there are now merge conflicts with the remote branch, but in my mind I should just have to rebase it as well.

Question is how to do this correctly?

Roland Deschain
  • 2,211
  • 19
  • 50
  • 1
    There are no conflicts there.... it just means that on the remote main branch there are commits (that you did not know of because you did not fetch) past the one that you used to rebase.... so if you _now_ follow the original recipe (skipping the 1st step as you have no changes to commit, right?), you should be fine. – eftshift0 Dec 13 '22 at 10:15
  • @eftshift0 hmm...the weird thing however is that if I checkout main and pull from origin, I get the message, that everything is up to date...This shouldn't be the case, if there are "locally unknown" commits on main, right? – Roland Deschain Dec 13 '22 at 10:30
  • 4
    Oh, forget about what I said first... it's not the upstream the problem. The message is expected because you are _rebasing_.... so you have to force-push your feature branch into the remote. – eftshift0 Dec 13 '22 at 10:34
  • @eftshift0 Thanks that did the trick :) I read something similar before, but chickened out due to some comments concerning losing file history with forced pushes. Am I correct that the steps above ("what I should have done") would be the right way to go about rebasing in the first place? – Roland Deschain Dec 13 '22 at 10:53
  • 1
    It is correct.... the only thing is that the push to close will need to be a forced one. I hold personal grudges about keeping a local copy of a branch like `main` (it is not necessary, you can interact with it using the remote one, but using the local branch is very popular so it's not like I will tell you not to use them as the problem is not related). – eftshift0 Dec 13 '22 at 11:02
  • 1
    My 2c: both workflows are equally valid. If you rebase a feature branch that's yours to develop and eventually PR, you're perfectly allowed to rebase it and force push it. Force pushing is bad for stuff others depend on, but not for a feature branch that you fundamentally own. – joanis Dec 14 '22 at 00:18

0 Answers0