The 3 Bash Aliases That Saved Me 10 Hours Last Week

I added three aliases to my .bashrc last Tuesday. By Friday, my shell history said I had saved ten hours. I checked the math twice. It held up.

None of these are clever. They are the kind of aliases a senior engineer has had for years and I only got around to writing because I finally hit the wall of friction that made them obvious. If you already have equivalents, stop reading. If you do not, this might be the cheapest ten hours of your year.

Alias one: the git undo

A wrapper around the most dangerous git command in the world: git reset --hard. I have a habit of destroying my working tree, then realizing I needed what I just threw away. The classic fix is git reflog, find the SHA, git reset --hard — three steps and a context switch.

alias gun="git reset --hard \$(git reflog | head -1 | awk '{print \$1}')"

What this does: git reflog | head -1 gives me the most recent SHA I had checked out, which is almost always the safe state I want to go back to. awk '{print $1}' extracts the SHA. git reset --hard jumps there. I call it gun because it is the opposite of a save. It is a rewind. I use it at least twice a day, mostly to undo a botched rebase, a bad interactive add, or a git pull --rebase that did not go the way I planned.

If gun feels too cute, name it git-undo and call it as a function instead. The shape is what matters: one command, takes you to the last known good state, no flags, no prompts, no confirmation. The whole point of an alias is to remove the three seconds of friction that, multiplied by twice a day, add up to a real hour per week.

Alias two: the pyenv reset

Python environments are the silent tax of every full-stack project. I keep three pyenv versions, a handful of old venvs, and a global pip list incompatible with everything. The first time I tried installing a package on a fresh checkout last week, I got the familiar “version X needs version Y, and the C headers are wrong” cascade.

The fix is always to nuke the venv and start over. But rm -rf .venv && python3.11 -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt is not something I want to retype five times a week.

alias pyreset="rm -rf .venv && python3.11 -m venv .venv && source .venv/bin/activate && pip install --upgrade pip && pip install -r requirements.txt"

Note the --upgrade pip step. Skipping it is the difference between a clean install and a clean install followed by a deprecation warning followed by a half-broken lockfile. The alias does not auto-detect the Python version — I have it pinned to 3.11 because that is what my projects use. Change one digit for 3.12. The principle is the same: pin the interpreter, blow away the venv, recreate, install, done.

The win is not the time the script saves. The win is that I no longer hesitate to nuke a broken venv. Friction at the start of “start over” is what keeps people debugging a corrupt environment for an hour instead of rebuilding in 30 seconds. Aliases are the answer to hesitation.

Alias three: the dev server

The third alias is the only one I will write about at length, because it is the one that taught me the lesson. The lesson is: aliases are not just for rare commands. The best aliases are for the command you type twenty times a day.

Here is my dev server alias. I have four or five of these, one per project, but the structure is the same:

alias devup="docker compose up -d && sleep 2 && tail -f logs/dev.log"

That is it. docker compose up -d starts the stack detached. The sleep 2 gives the database container a beat to be ready before the application container panics about a missing connection. tail -f logs/dev.log is the part I was typing manually forty times a day.

The alias is not faster than the three commands it replaces. Each takes a fraction of a second to type. The win is that I no longer think about them.

The dev server comes up the same way every time, in the same order, with the same sleep in the middle, regardless of whether I am tired, distracted, or in a hurry. Starting my dev environment is now a single thing, not a sequence of things.

That is the insight I want to share. I thought aliases were about saving keystrokes. They are not. Aliases are about removing decisions. Every time you collapse a sequence into one name, you remove a small decision point from your day. The cost is not the typing. The cost is the moment of context switch — the second where you have to remember whether the compose file is docker-compose.yml or compose.yaml, whether the database container comes up first, whether tail -f should be against the host log or the container log.

When I started counting, I was making maybe 30 of these little decision points per day. Most were sub-second, none longer than a deep breath. But added up, they were a real tax. The dev server alias alone removed four per day. By the end of the week, I was starting my work with a single command. I had forgotten what the multi-step version felt like.

How to add these to your own setup

Open your shell history and look at commands you typed more than ten times this week. Most are probably candidates. Sort by frequency, pick the top three, write an alias for each. Put them in your .bashrc or .zshrc, source the file, and force yourself to use them for a week.

You will save a few seconds per use. A few minutes per day. A few hours per month. The compounding is real.

The deeper lesson: the shell is an interface, and interfaces are not free. Every command you type without an alias is a place where your brain has to look up the right incantation. The fewer of those you have, the more of your brain is available for the actual problem you are solving.

I did not save ten hours because the commands got shorter. I saved ten hours because my brain stopped carrying the incantations.