I was working on a feature branch B that I had branched out from master a month ago. As other new features came in, the master branch kept getting updated.
This is how master branch looks like right now:
1 -> 2 -> 3 -> 4 -> 5 -> 6 ->7
When I had first branched out, it looked like this:
1 -> 2 -> 3
This is how my feature branch (B) looks like right now:
x -> y -> z
Now that I am ready to push my new feature to master, I was advised to first rebase from master, and then create a PR.
While doing git rebase, my branch encountered a merge conflict with a couple of files. I thought I'll just keep the incoming changes and the rebase will proceed normally. However, me resolving the conflicts converted the entire "REBASE MASTER" step to a sort of "MERGE MASTER". AKA: It applied the commits that had already been merged into master into my feature branch, not something I initially intended to do with git rebase.
This is how my feature branch looks like right now:
x -> 4 -> 5 -> 6 -> y -> 7 -> z
This is what I wanted to achieve (but didn't):
1 -> 2 -> 3 -> 4 -> 5 -> 6 ->7 -> x -> y -> z
How do I go back? This has already been pushed to the remote branch, so I can't simply delete my local branch and fetch from origin again.
One way I can think of is to branch out from master again, and create a feature branch C. Then, cherry-pick commits from B to C. Once I am sure C is a complete copy of B (and only contains the commits I want), I can delete B. Am I missing something? Or is there a better/faster way?
( First of all, just in case, abort any rebase still in progress with git rebase --abort )
Are you the only one to work on this feature branch? (I guess so, I'll assume it for the following)
Has the PR been accepted/merged into master yet?
If not, then it is very much an undoable situation. (This may be what Lux hinted at in comments)
First, find the commit hash you need to restore (z in your example). For that you can check your branch's reflog (or maybe just pick it from your recent commands output if available).
Then restore your local branch B to the old reference (before the rebase) and push it again to the remote (with --force, since git will complain that this is not a linear history).
git branch -f B <commit_hash_of_z>
git push -f origin B
Now you can redo your rebase and try to figure out where it went sideways last time.