🦥How to Uncommit Your Crimes

Hello friends!

Welcome to another issue of Sloth Bytes. I hope you’re having a great week.

Claude can be your analyst, editor, and strategist.

But most professionals are using it to fix grammar.

These 1,000+ Claude prompts take it from grammar tool to your most powerful AI work assistant.

Sign up for Superhuman AI and get:

Claim your free prompts

Find, reach, and close your perfect deals — without juggling five tools or hiring more reps.

Apollo gives you everything you need to build real pipeline, fast. From inbound to outbound, first touch to close.

All in Apollo.

Sign up for free

Git is great because it remembers every change you make.

But it’s also terrible because it remembers every change you make.

Some code changes are better left forgotten.

Eventually, you’ll make one change so diabolical that you have to undo it.

So you search “how to undo something in Git,” and Git gives you three commands that sound like they do the same thing:

That is not very helpful. So what’s the difference?

Well, Git has an official comparison, but its documentation isn’t the friendliest, so here’s the simple version:

The rule you should remember is:

That rule handles most Git emergencies, but let’s go through the details before someone runs --hard and ruins everything.

Before choosing an undo command, you need to know where your mistake currently lives.

Git tracks your work in three main places:

Think of it like writing an email:

Unfortunately, Git does not include one universal “undo” button.

Instead, it gives you three different undo commands.

Use git restore when your mistake is still inside a file and has not become a commit.

Let’s say you changed app.js, added 40 lines of code, and somehow made the app worse.

Welcome to the club.

To discard those unstaged changes, you would run:

This replaces your working copy of the tracked file app.js with Git’s stored version.

Warning: Those uncommitted changes are removed. Git’s documentation warns that restoring a modified file can permanently discard local work.

So before running this command, ask yourself:

Can I fix this, or do I truly want to discard it?

Alright, so maybe your code changes were actually good.

You entered a flow state and started writing the greatest code known to mankind.

Now you’re ready to commit everything:

…and immediately realize you didn’t just stage your code.

You also staged your .env file.

Great.

Now what? How do you remove one file from the staging area without deleting all the beautiful code you just wrote?

Luckily, you read Sloth Bytes and already know exactly what to run:

This unstages the file without deleting your changes.

Your .env file leaves the staging area, but everything inside it stays untouched on your computer.

You should probably add it to a .gitignore file too, unless you enjoy accidentally leaking API keys.

Now let’s say you already committed your mistake and you haven’t pushed it yet.

The good news is that this is still easy to undo, and only you can see your terrible crime.

Since you committed it, your history currently looks like this:

Commit C is your latest commit. Y’know the terrible one.

To undo it and move your branch back one commit, you can use:

After you run the command, your history will look like this:

Commit C is no longer part of the branch’s visible history.

Like it never happened.

However, what happens to the code depends on which reset mode you use:

There’s a few more reset options, but these are the most common ones.

This removes the latest commit from the branch but leaves all of its changes in the staging area.

Use this when:

Basically, the commit disappears, but all the ingredients remain neatly arranged on the counter.

This is the default --mixed reset.

It removes the commit and keeps the code changes, but those changes return to your working directory as unstaged edits.

Use this when you want to reorganize the changes, edit them further, or split one giant commit into several smaller ones.

This moves your branch backward and updates both the staging area and working directory to match.

In plain English: The commit disappears, and so does the code.

--hard can overwrite local files and permanently destroy uncommitted changes. It is one of the few Git operations that can genuinely delete work rather than hiding it somewhere.

I recommend creating an emergency backup branch before using it:

Then run the reset.

Creating that branch takes two seconds and can save you from spending the next two hours trying to find the deleted work.

A commit removed from the branch may still be recoverable through Git’s reflog.

However, uncommitted changes overwritten by a hard reset may be permanently lost. Do not treat the reflog as a substitute for checking what a destructive command will do.

Use reset for commits that have not been shared with other people.

Reset changes the branch’s history. If teammates already pulled the commit, rewriting that history can turn your minor mistake into everyone’s minor mistake.

What happens when the bad commit is already on GitHub and all your teammates can see your crime?

Do not immediately reset the branch and force-push it.

Funny enough, that technically does work in some situations, but it rewrites shared history.

Anyone who already downloaded the original commits may now have a different timeline from yours.

Instead of resetting, you would revert the commit with:

Or, to revert a specific commit:

Unlike reset, revert does not delete the original commit.

Instead, it creates a new commit that reverses the changes introduced by the old one.

Before:

After reverting C:

Commit C contains the mistake.

Commit D reverses it.

The history remains intact, which means your crime is still there, but at least your teammates can pull the new commit without Git experiencing an identity crisis.

Use it when:

git revert is usually the safest option for undoing public history.

Here is the whole article compressed into one table:

The easiest way to choose is to ask two questions:

If no, you probably need git restore.

Maybe your code is fine, but your commit message says:

Well, that’s embarrassing.

We can’t have typos around here, that’s too human.

Luckily, you don’t need to reset the entire commit.

Instead, you can amend the commit:

Amending replaces the most recent commit with a new one, so it is best used before that commit has been pushed or shared.

If you already pushed it, well… your choices are accepting the typo or doing a hard reset and force-pushing.

You’d be surprised how many people would rewrite history over one typo.

Anyways, that’s all from me!

If version control still feels confusing, read my Understanding Version Control issue next.

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all Thursday or Friday.

Hopefully…

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.