Git Beyond the Basics: Workflows That Save Hours Every Week

The Basic Command

This opens an editor showing your last 5 commits, oldest first:

Each line starts with a command. Change pick to one of these:

• squash (or s) — Merge this commit into the one above it, combine the messages
• fixup (or f) — Same as squash, but discard this commit's message
• reword (or r) — Keep the commit but change its message
• drop (or d) — Delete this commit entirely
• edit (or e) — Pause the rebase at this commit so you can amend it

A Real Cleanup Session

Here's what I actually do. That messy history above becomes:

Save and close. Now you have three clean commits instead of five. The typo fix gets folded into the auth commit. The rate limit bug fix gets folded into the rate limit commit. Your PR reviewer sees a clean, logical progression.

Reordering Commits

You can literally rearrange the lines. If the test commit should come before the rate limiting commit, just move the line:

Git will replay your commits in this new order. If there are conflicts, it'll pause and let you resolve them.

The Autosquash Shortcut

If you know a commit is a fix for a previous one, mark it at commit time:

This creates a commit with the message fixup! Add user authentication endpoint. Then when you rebase:

Git automatically reorders the fixup commits right below their targets and marks them as fixup. You just save and close. No manual editing.

I use this constantly. It's the fastest way to iterate on a branch while keeping the final history clean.

The Golden Rule

Never rebase commits that have been pushed to a shared branch. If other people have based work on those commits, rewriting history will cause real problems. Rebase your own feature branches before merging. Never rebase main.

If you've already pushed your feature branch and need to rebase:

The --force-with-lease flag is safer than --force. It refuses to push if someone else has pushed to the same branch since your last fetch. It won't prevent all problems, but it catches the most common one.

Cherry-Pick: Surgical Commit Transfers

Cherry-pick takes a specific commit from one branch and applies it to another. Not a merge. Not a rebase. Just one commit, cleanly applied.

When I Actually Use This

The most common scenario: I fixed a bug on my feature branch, but the fix also needs to go to main or a release branch right now. I don't want to merge my entire feature branch. I want just that one fix.

Done. The fix is on main as a new commit with the same changes.

Cherry-Pick Without Committing

Sometimes you want to apply the changes but not commit them yet. Maybe you want to combine several cherry-picks into one commit, or modify the changes slightly:

The changes are staged but not committed. You can modify them, add more changes, then commit when ready.

Range Cherry-Pick

Need multiple consecutive commits? Use range syntax:

This cherry-picks everything after a1b2c3d up to and including f6g7h8i. Note that a1b2c3d itself is excluded. If you want to include it:

Handling Conflicts

Cherry-pick conflicts work like merge conflicts. When one happens:

Or if you change your mind:

One thing to watch: cherry-picked commits create new commit hashes. If you later merge the original branch, Git is usually smart enough to handle the duplication. But if you cherry-pick aggressively between branches that will eventually merge, you might see unexpected conflicts. Use it surgically, not as a merge strategy.

Git Bisect: Binary Search for Bugs

Something broke. You know it worked two weeks ago. There have been 200 commits since then. Which one broke it?

You could check each commit manually. Or you could use git bisect, which uses binary search to find the exact breaking commit in log2(n) steps. For 200 commits, that's about 7-8 checks instead of 200.

The Manual Way

Git checks out a commit halfway between good and bad. Test it. Then:

Git narrows the range by half each time. After 7-8 steps, it tells you:

Now you know exactly which commit introduced the bug. When you're done:

This takes you back to where you started.

The Automated Way (This Is the Real Power)

If you have a test that can detect the bug, you can automate the entire thing:

Git will automatically check out commits, run the test, and mark them as good or bad based on the exit code. Zero means good, non-zero means bad. Walk away, come back, and it tells you the exact commit.

You can use any script:

Where test-regression.sh is:

Exit code 125 is special — it tells bisect to skip that commit (useful if a commit doesn't compile). This is one of those features that seems niche until you need it, and then it saves you an entire afternoon.

A Real Bisect Session

Here's what it looks like in practice:

Seven steps to find a needle in a haystack of 200 commits.

Git Worktrees: Multiple Branches, Zero Stashing

This is the most underused Git feature. I'm convinced most developers don't know it exists.

The problem: you're deep in a feature branch. Files are changed everywhere. Then someone says "can you look at this production bug real quick?" You have three options:

1. Stash everything, switch branches, fix, switch back, pop stash. Hope nothing goes wrong.
2. Commit your half-done work with a "wip" message. Ugly but functional.
3. Clone the repo again into a different directory.

Or option 4: worktrees.

What a Worktree Is

A worktree is a second (or third, or fourth) working directory linked to the same repository. Each worktree has its own checked-out branch, its own working files, its own index. But they share the same .git data, so you're not duplicating the entire repo.

Adding a Worktree

This creates a new directory ../hotfix-session with main checked out. Your current directory stays exactly as it was. Nothing stashed, nothing committed, nothing disrupted.

Creating a New Branch in a Worktree

This creates the worktree AND creates a new branch hotfix/nav-crash based on main.

Managing Worktrees

Why This Is Better Than Stashing

Stashing is fine for quick context switches. But worktrees are better for anything that takes more than five minutes:

• Your IDE stays open on your feature branch. No reindexing, no losing your scroll position.
• You can run tests in both directories simultaneously.
• No risk of stash conflicts or forgetting what you stashed.
• You can have a long-running dev server in one worktree and a clean build in another.

I typically keep two or three worktrees active: my main feature branch, a main worktree for quick checks, and sometimes a review worktree where I check out someone else's PR.

The One Catch

You can't have the same branch checked out in two worktrees. That's by design — it prevents you from making conflicting changes to the same branch in two places. If you try, Git will refuse.

Reflog: The Undo Button for Everything

You did a hard reset and lost commits. You deleted a branch. You rebased and something went horribly wrong. You think your work is gone.

It's not. Git almost never actually deletes anything. The reflog is your safety net.

What the Reflog Is

Every time HEAD moves — every commit, checkout, rebase, reset, merge — Git records it in the reflog. It's a log of everywhere your HEAD has been, in order.

Output:

Every entry has an index (HEAD@{0}, HEAD@{1}, etc.) and a description of what happened.

Recovering After a Hard Reset

You accidentally ran git reset --hard HEAD~3 and lost three commits. They're right there in the reflog:

All three commits are back. Crisis averted.

Recovering a Deleted Branch

You deleted a branch that had unmerged work:

The commits still exist. Find them:

The branch is back, with all its commits.

Recovering After a Bad Rebase

You rebased and everything went wrong. Conflicts everywhere, wrong commits, chaos:

You're back to exactly where you were before the rebase started. As if it never happened.

The 30-Day Safety Net

By default, Git keeps reflog entries for 30 days (90 days for reachable commits). After that, they can be garbage collected. So you have a month to realize you made a mistake. In practice, this is more than enough.

You can check the expiry:

If you're paranoid, increase it:

A Personal Rule

Before any destructive operation — hard reset, force push, branch deletion — I run git log --oneline -10 first. I mentally note the current HEAD. It takes two seconds and has saved me more than once from a panic I didn't need to have.

Stash Properly: It's Not Just git stash

Most people use stash like this:

That works, but it's the equivalent of throwing everything into a box labeled "stuff." When you have three stashes, you have no idea which is which.

Name Your Stashes

Now when you list stashes:

You can see exactly what each stash contains.

Include Untracked Files

By default, git stash only stashes tracked files. New files you haven't added yet are left behind:

I use --include-untracked almost every time. Leaving new files behind when you switch branches causes confusion.

Partial Stashing

This is the one most people don't know about. You can stash specific files:

Or use patch mode to stash specific hunks within files:

Git will go through each change interactively and ask if you want to stash it. y for yes, n for no, s to split the hunk into smaller pieces.

Applying vs Popping

I use apply when I'm not sure if the stash will apply cleanly. If there's a conflict, the stash is preserved. With pop, if there's a conflict, the stash stays in the list anyway (many people don't know this), but I prefer the explicit intent of apply.

Viewing Stash Contents

Creating a Branch from a Stash

If your stash has grown into something more substantial:

This creates a new branch from the commit where you originally stashed, applies the stash, and drops it. Clean.

Branching Strategies: Which One Actually Works

There are three mainstream branching strategies. Each has a context where it shines and contexts where it causes pain.

Gitflow

The classic. main, develop, feature/*, release/*, hotfix/*. Created by Vincent Driessen in 2010.

When it works: Mobile apps, desktop software, anything with named versioned releases and multiple versions supported simultaneously. If you ship v2.1 and v3.0 and need to patch both, Gitflow handles that.

When it doesn't: Web applications with continuous deployment. If you deploy to production 5 times a day, the ceremony of release branches and develop branches is pure overhead. Most web teams that adopt Gitflow end up with a develop branch that's perpetually broken and release branches that nobody understands.

GitHub Flow

Simple. You have main. You create feature branches. You open PRs. You merge to main. You deploy main.

When it works: Small to medium teams shipping web apps. Continuous deployment. If main is always deployed, this is all you need.

When it doesn't: When you need to maintain multiple release versions, or when you have a long QA cycle before deployment. GitHub Flow assumes main goes to production quickly.

Trunk-Based Development

Everyone commits to main (the "trunk") directly or via very short-lived branches (less than a day). No long-running feature branches.

When it works: High-performing teams with good CI/CD, comprehensive test suites, and feature flags. Google, Meta, and most large tech companies use trunk-based development. It forces small, incremental changes and eliminates merge hell.

When it doesn't: Teams without good test coverage or CI. If merging to trunk means deploying untested code, you'll break production constantly. You also need feature flags for anything that takes more than a day to build:

My Recommendation

For most web development teams: start with GitHub Flow. It's simple, it works, and it doesn't require tooling beyond what GitHub/GitLab already provides.

If your team grows past 15-20 engineers and you're deploying multiple times a day, look at trunk-based development with feature flags. The investment in feature flag infrastructure pays for itself in reduced merge conflicts and faster iteration.

If you're shipping versioned software (mobile apps, CLI tools, libraries): Gitflow or a simplified version of it. You actually need those release branches.

Don't pick a strategy because a blog post said it's the best. Pick the one that matches how you actually ship.

Git Hooks: Automate the Things You Keep Forgetting

Git hooks are scripts that run automatically at specific points in the Git workflow. They're local to your machine (not pushed to the remote), which means you need a way to share them with your team.

The Hooks That Actually Matter

pre-commit — Runs before every commit. Use it for linting and formatting:

commit-msg — Validates the commit message format. Perfect for enforcing conventional commits:

pre-push — Runs before pushing. Use it for tests:

Husky vs Native Hooks

Native hooks live in .git/hooks/. The problem: the .git directory isn't tracked by Git, so you can't share hooks through the repo. Everyone has to set them up manually.

Husky solves this. It stores hook configurations in the repo and sets up .git/hooks automatically on npm install:

This creates a .husky/ directory. Add hooks as files:

Combined with lint-staged, you get fast, targeted pre-commit checks:

This runs ESLint and Prettier only on the files you're actually committing. Not the entire codebase. Fast.

When to Skip Hooks

Sometimes you need to commit without hooks running. Emergency hotfixes, work-in-progress commits on your own branch:

Use this sparingly. If you find yourself skipping hooks regularly, your hooks are probably too slow or too strict.

Aliases That Save Time

My .gitconfig has evolved over years. These are the aliases that survived — the ones I actually use daily, not the ones I added because they looked clever.

Pretty Log

The default git log is verbose. This gives you a clean, colorful, graph-based view:

Usage:

I run this 20 times a day. It's the fastest way to understand the state of your repository.

Undo Last Commit

Keep the changes, just undo the commit:

Usage:

I use this when I commit too early, forget a file, or want to restructure the changes.

Unstage Everything

Usage:

List All Aliases

Because you'll forget what you set up:

More Aliases I Use

The up alias is particularly good. pull --rebase keeps your history linear instead of creating merge commits for every pull. --autostash automatically stashes and restores your changes if you have dirty files. It's what pull should have been by default.

The cleanup alias deletes local branches that have been merged to main. After a while, you accumulate dozens of stale branches. Run this weekly.

The Commands I Use Daily

These aren't aliases or advanced features. They're just commands I run constantly that many developers don't seem to know about.

The Ultimate Log Command

This shows every branch, every merge, the entire topology of your repo in a compact view. It's the first thing I run when I pull changes. It answers "what's happening in this repo right now?"

Diff Staged Changes

This shows what's about to be committed. Not what's changed in your working directory — what's actually staged. I always run this before committing. Always. It catches accidental inclusions, debug statements, console.logs that shouldn't be there.

Show a Specific Commit

Shows the full diff of a single commit. Useful when reviewing history, understanding what a commit actually changed.

That last one is incredibly useful. You can view any file at any point in history without checking out that commit.

Blame with Line Ranges

Shows who last modified lines 42-60. More useful than blaming the entire file, which is usually overwhelming.

The -w flag is important. Without it, blame will attribute lines to whoever last reformatted the file, which is rarely the person you're looking for.

Find a String Across All History

-S (the "pickaxe") finds commits where the number of occurrences of a string changed. -G finds commits where the diff matches a regex. Both are powerful for archeology — figuring out when something was introduced or removed.

Show What Changed Between Two Points

Two dots vs three dots matters. Two dots shows the difference between the tips of both branches. Three dots shows what changed on the right side since it diverged from the left side. Three dots is usually what you want when reviewing a feature branch.

Clean Up Untracked Files

Always run with -n first. git clean -fdx will delete your node_modules, .env, build artifacts — everything not tracked by Git. Useful for a truly fresh start, but destructive.

Restore a Single File from Another Branch

Or from a specific commit:

This is cleaner than the old git checkout main -- path/to/file syntax, and it doesn't affect HEAD.

Putting It All Together: A Real Workflow

Here's what a typical day looks like with these tools:

Each of these commands takes seconds. Together, they save hours. Not hypothetical hours — real hours, every week, that I'd otherwise spend untangling Git messes, manually searching for bugs, or losing work to context switches.

Git is a tool that rewards depth. The basics get you through the day. But the commands in this post are what separate "I use Git" from "Git actually makes me faster." Learn them incrementally. Pick one new technique this week and use it until it's muscle memory. Then pick another.

Your future self, staring at a production bug at 11 PM, will thank you for knowing git bisect.