Redo a Reverted git merge-CodePudding

I have a branch called dev and a topic branch off of it called feature-1. After testing, I want to merge feature-1 into dev. But first, changes were made to dev while I was working on feature-1, so I thought to merge them:

git checkout feature-1
git merge dev

Worked fine, but then without realizing it, I accidentally deleted the new files, and un-did the deletion of files that happened in dev. I figured, "whatever, I'll commit and merge again later."

git add new-files
git rm old-files
git commit -m "broke merge"

But then I was unable to re-merge:

git merge dev
>>>>> Already up to date

But...there are differences in the files between these branches! If I merge feature-1 into dev, won't it play those deletion commits on top of dev?

I tried reverting the merge:

git revert -m 1 *merge-hash*

But git still thinks one is the parent of the other, or something. Merging again still fails "already up to date".

After this I also tried rebasing dev onto feature-1, but I still don't see the changes from dev, and by this point, I'm lost.

I don't care that dev is still considered a parent of feature-1, or whatever. I just want to replay dev's commits on top of feature-1 and resolve any conflicts. How can I do this?

EDIT: I tried reverting my revert on a suggestion from Linus I read here

git revert *revert-hash*

Now I see all the changes from dev (I THINK). It's not obvious from the git log which commits happened in what order now.

EDIT 2: Then I ran git status and found

On branch feature-1 Your branch and 'origin/feature-1' have diverged, and have 5 and 3 different commits each, respectively. (use "git pull" to merge the remote branch into yours)

So I ran git pull, resolved merge conflicts....and I've lost the changes from dev again, of course because I pushed that bad merge earlier. Maybe this was due to the rebase?

CodePudding user response：

When this happens to me, many times the easiest solution is to create a new branch from dev, and git cherry-pick your changes from feature-1, one commit at the time. That way you end up with exactly the commits you want, instead of trying to fix a broken history that will look ugly anyway.

Another solution is to rebase against the branch you want, and clean it up of commits

In feature-1 branch run rebase dev -i. Then remove the commits you don't want by replacing pick with d.

The rebase option is better when you know what the issue with the history is. The cherry-pick one is better when you don't know what's going on, and is generally more time consuming but easier.

A middle-of-the-road solution is to rebase, merge commits you know are good, and then cherry-pick them onto another, clean branch. I rarely ever do this.

If you solve the issue locally using rebase -i, git wont let you push since you've modified the history. You can solve it by force push so origin matches your local: git push --force-with-lease. Push force is required whenever you rebase -i since you're changing the history.