This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job. You're in the git category.
Last Updated: 2024-12-03
I had finished the rewrite_tutor
branch, a complicated change that required a
careful deploy, and merged it into master
, even though I was finishing the day
and had no intention of deploying it until tomorrow.
As luck would have it, that evening I noticed I was getting 1000's of exceptions
for unrelated causes. But I could not put a hotfix on master, because that would
necessitate a deploy of this new rewrite_tutor
tutor code, which I didn't want
to deal with right now.
I got around by reverting the merge (and choosing to keep a particular side of
the master - the one I was merging into) $ git revert -m 1 sha1
Only merge a risky major feature into master just before you deploy. Otherwise you rob yourself of the ability to do hot-fixes.
The generalization of this is trivial but important for juniors to know:
Always work on feature branches. In a separate incident I had some
half-finished code on development
and a colleague deployed it, as was his
right, and of course this unfinished code caused bugs. I should have had this
unfinished code in a feature branch until it was ready.