How Not to Git Merge
I don’t know who else has made this mistake, but I sure just did it, and it cost me an evening and left me with a headache.
The mistake was a hasty merge commit into the production branch of a Firebase app, without looking at the preview site, building public-facing assets that caused a white screen of death on the live test site.
Why did it happen? I think it was because I used a spread operator (...) in a JavaScript function without trans-piling, which caused an issue in the module export and led to a white screen of death in the browser.
I didn’t discover it until after I had already merged the commit into the main branch, at which point, the production assets had already been updated.
To rectify the horrifying mistake of publishing a broken site, I performed a git revert of the merge commit… Later on, I was missing the document state introduced by the 15 commits from the merged branch.
In GitHub, you can press a green button to perform git revert abc, where abc is the commit hash of your merge commit: the commit which tracks when you merged in all commits from your feature branch.
If you revert the merge commit, it will eliminate the document state introduced by all the commits on the incoming branch.
Get your commits back⌗
Instead of reverting the revert, you can choose to individually cherry-pick commits to reapply them.
This might be more useful for fewer commits. In my case, I had brought in 15 commits, so I decided to push / merge a fix then revert the revert.
Get the hash⌗
git log to view recent commits with their hashes.
Reapply individually⌗
git cherry-pick abc to reapply the original commit where abc is the commit hash.
Revert Revert⌗
Revert the revert of the hasty merge commit to get back the document states from those commits.
git revert abc where abc is the commit hash.
Never do this again⌗
- Always preview test builds before merging in changes; otherwise, why waste the resources?
- The build script can miss things, such as faulty module exports.
- See first point.