Consequences of for-Git-ting to merge the master into feature branch!
Naveen Niraula
Posted on August 13, 2024
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.
Posted on August 13, 2024
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.