Consequences of for-Git-ting to merge the master into feature branch!

First off, pardon my not so punny title.

Second, let's start by clarifying this isn't a guide or a how to. It's just how I unf*cked my situation (that I created) just before a release.

I understand this might not be the best possible way. But let's just assume it is for my situation (any inputs are welcome, for my future F ups.

Context:

• My PR got reviewed and was ready to be shipped.
• Next, I see changes in master ( main, whatever ); saw conflicts in my branch (didn't merge it, OOOPS 0!)
• Changed files in my branch; commit -> pushed (OOOPS 1!)
• Merge master (conflicts in the same files and lines that I pushed, resolved it without thinking what the changes were on master, OOOPS 2!)

(In the above stage I assumed that master would adjust and separate to my changes from itself, OOOPS 3!)

• PR got updated, but now as you guessed it was in abnormal state where master's changes were overwritten by mine)

Enter: Panic mode

After 1 hour of discussion of what should be done, I decided to soft reset it ~2 commits.

UNF*CKING Process

First, I reverted the commits that caused the issue using git reset --soft HEAD~2. Great, now what ?

Tried to git push current state; git rejected caused well I effed up.

I did what a normal person (in a mental asylum) would do.

git push --force (TADA), everything's good.

It worked because I was the only PERSON working on that branch. I do not recommend the --force in any situation but well I don't really know any alternative.

Now, the wizards on dev.to please enlighten me if that was the correct approach. Or it should've been something else.