My recent projects have involved a fair amount of disposable code. I'll write a component for an A/B test, and then it needs to be ripped out after the experiment closes.
Git has simplified this process beautifully!
I could manually handle the files, deleting line by line myself. But git makes it so that I can run a few commands in the CLI to revert everything.
Here's my workflow for it:
I've been guilty of mega commits that look something like this:
git commit -m "render revenue data to pie chart AND Connect ID to Dashboard AND move tiers to constants file AND ..."
I've recently made the switch to breaking out any instance where I would want to put an "and" in my explanation of the change into it's own commit. So now my commits will look more like this:
$ git commit -m "render revenue data to pie chart" $ git commit -m "Connect ID to Dashboard" $ git commit -m "Move tiers to constants file"
There are loads of benefits to this. To anyone reviewing my code, it's far easier to follow the story told by my commits. Isolating a breaking change is much easier.
The best, though, is that it's WAY easier to isolate a commit or few that needs to be thrown out later.
The word comes back from marketing: The first A/B test was a success, but the second needs taking out.
If a single commit needs changing, it's as easy as this:
$ git revert 9425e670e9425e66d61c8201...
git revert will then create a commit with the inverse of those changes.
Usually, I need to do this with multiple files. The workflow isn't too different:
$ git revert --no-commit 820154... $ git revert --no-commit 425e66... $ git revert --no-commit 9425e6... $ git commit -m "the commit message for all of them"``
Push and merge from there!