Advanced Git Commands You Probably Haven’t Heard Of

This article covers a set of powerful Git commands that go beyond the everyday add, commit, and push—commands that help you rewrite history, debug stubborn bugs, and manage complex workflows. You’ll learn what each command does, when to use it, and see concrete examples you can try immediately.

Why These Commands Matter

Most developers live in a small corner of Git: commit, branch, merge, push, pull. But Git is a content-addressable filesystem with a rich command set designed for non-linear workflows. The commands below solve real problems: recovering lost work, splitting a messy commit, finding the exact change that broke a test, or syncing a fork without a tangled history. They are not parlor tricks—they are the tools that turn Git from a backup system into a precision instrument.

git reflog: Your Safety Net for Lost Commits

When you run git reset --hard or git rebase and realize you just destroyed work, git reflog is your lifeline. The reflog records every movement of your branch pointers (HEAD and branch tips) in your local repository. It is a local, per-user log that tracks where your HEAD has been, even if you deleted a branch or reset it.

To see it, run:

git reflog

You’ll see a list like:

e5a4f2c HEAD@{0}: reset: moving to HEAD~2
9b3d6f1 HEAD@{1}: commit: Fix typo in docs
...

If you accidentally reset too far, find the commit hash you want (e.g., 9b3d6f1) and run:

git reset --hard 9b3d6f1

Key insight: The reflog is local—it is not pushed to remotes. It expires after 90 days by default, but you can configure it with gc.reflogExpire. This is the first command to try when you think you’ve lost commits.

git bisect: Binary Search for Bugs

When a bug appears and you know it worked in some past commit, git bisect uses binary search to find the exact commit that introduced it. Instead of manually checking dozens of commits, Git does it for you.

Start the bisect: git bisect start
Mark a known good commit: git bisect good <commit>
Mark a known bad commit (usually HEAD): git bisect bad

Git checks out a middle commit. You test it, then mark it good or bad. Git narrows down the range until it finds the first bad commit. You can automate this with git bisect run <script> that exits 0 for good and non-zero for bad.

Common mistake: Forgetting to run git bisect reset after you finish, which leaves your repo in a detached HEAD state.

git stash: Beyond the Basics

You probably know git stash to save uncommitted changes. But it has less-known flags:

git stash push -m "message" – add a description to identify the stash.
git stash push --keep-index – stash only unstaged changes, leaving staged ones intact.
git stash push -u – include untracked files.
git stash branch <branchname> – create a new branch from the stash, applying changes there. This is useful if you stashed changes that conflict with your current branch.

To list stashes: git stash list. To apply a specific stash: git stash apply stash@{2}. To drop it: git stash drop stash@{2}.

git cherry-pick: Selectively Apply Commits

Instead of merging a whole branch, you can pick specific commits and apply them to your current branch. This is invaluable when you have a hotfix commit on a release branch and you want it on main without bringing over other changes.

git cherry-pick <commit-hash>

You can cherry-pick a range: git cherry-pick A..B (all commits after A up to and including B). If conflicts arise, resolve them, then git cherry-pick --continue. To abort: git cherry-pick --abort.

Caution: Cherry-picking creates duplicate commits with new hashes. If you later merge the original branch, you may get conflicts. Use it sparingly and document why.

git rebase –onto: Move Commits Like a Pro

Standard git rebase replays your commits onto a new base. But --onto lets you move a subset of commits to a completely different base. For example, you have a feature branch feature that accidentally branched off an old main. You want to rebase only the last 3 commits onto the latest main:

git rebase --onto main feature~3 feature

This takes commits from feature~3 (exclusive) to feature (inclusive) and replays them onto main. This is also how you move commits from one branch to another without cherry-picking each one.

git clean: Remove Untracked Files

git clean deletes untracked files and directories. It’s dangerous, so always do a dry run first:

git clean -n   # shows what would be removed

To actually remove: git clean -f (files) and git clean -fd (files and directories). Add -x to also remove ignored files (e.g., build artifacts). This is useful to reset your workspace to a pristine state, but double-check that you don’t need any of those files.

git worktree: Multiple Working Trees

Sometimes you need to work on two branches simultaneously without stashing or cloning. git worktree allows you to have multiple working directories linked to the same repository.

git worktree add ../path-to-new-dir -b new-branch

This creates a new directory with a checkout of new-branch. You can switch between branches in each directory independently. To list: git worktree list. To remove: git worktree remove ../path.

Use case: Fixing a bug on a release branch while developing new features on main, without context switching.

Frequently Asked Questions

What is the difference between git revert and git reset?

git revert creates a new commit that undoes a previous commit, preserving history. git reset moves the branch pointer backward, effectively deleting commits from the current branch. Use revert for shared branches, reset for local, unpublished changes.

How do I undo a git merge?

If the merge hasn’t been pushed, use git reset --hard ORIG_HEAD (ORIG_HEAD points to the commit before the merge). If it has been pushed, use git revert -m 1 <merge-commit> to revert the merge while keeping the branch history.

What does git reflog expire mean?

Reflog entries are automatically deleted after 90 days (configurable). After expiry, you cannot recover those commits via reflog. To keep entries longer, set gc.reflogExpire to a larger value.

Can git bisect be used on a branch that is not linear?

Yes, but it works best on a linear history. If you have merges, bisect may skip some commits. You can use git bisect skip for commits that cannot be tested (e.g., due to build failures).

Is it safe to use git clean -fd?

It’s safe only if you are sure you don’t need any untracked files. Always run git clean -n first to preview. Consider committing or stashing untracked files you want to keep.

Conclusion

These advanced commands—reflog, bisect, stash options, cherry-pick, rebase –onto, clean, and worktree—give you precise control over your Git repository. They are not everyday commands, but when you need them, they are indispensable. Practice them on a test repository to build confidence, and always double-check destructive commands with dry-run flags or reflog backups.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →