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

Naveen Niraula — Tue, 13 Aug 2024 11:35:10 +0000

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.

DEV Community: Naveen Niraula

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