Git Reset Options
You use git reset options to move your current branch pointer to a different commit. The three main modes control how Git updates your staging area and working directory. Teams often run these commands on local machines to clean up commits before pushing. If branch roles are too broad, a bad reset and push can wipe shared history. How git reset options work in your workflow Git tracks changes across three distinct local areas on your machine. The HEAD pointer marks the latest commit on your a
Git Commit Signing (GPG, SSH): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use git reset options to move your current branch pointer to a different commit. The three main modes control how Git updates your staging area and working directory. Teams often run these commands on local machines to clean up commits before pushing. If branch roles are too broad, a bad reset and push can wipe shared history.
How git reset options work in your workflow
Git tracks changes across three distinct local areas on your machine. The HEAD pointer marks the latest commit on your active branch. The index holds staged files that are ready for your next commit. The working tree holds the normal files you edit on your disk.
Soft mode moves the branch pointer back to an older target commit. It leaves both your staging index and your working tree untouched. All changes from the undone commits wait in the staging area for a new commit. Developers pick this mode to squash several small commits into one clean entry.
Mixed mode is the standard behavior when you do not pick a specific mode. It moves the branch pointer and clears the staging area to match that commit. Your working files stay safe on disk, but you must stage them again. This helps when you staged the wrong files and want to group them again.
Hard mode is the most destructive choice among the three main modes. It resets the branch pointer, the staging index, and the working tree all at once. Any uncommitted local work in tracked files disappears from your active directory right away. You should only run hard mode when you want to throw away local changes.
When to use reset versus revert
Reset rewrites commit history by moving the branch tip backward in time. This works well on local branches that nobody else has pulled yet. If you reset a shared branch, your local history clashes with the remote repo. You then have to force push, which breaks the branch for other team members.
Git Commit Signing (GPG, SSH): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Revert is the safer choice for public branches that the whole team shares. Instead of erasing old commits, revert creates a brand new commit at the tip. That new commit holds the exact opposite changes of the bad commit. Everyone can pull the update without fixing broken history on their own laptops.
What native repo permissions solve and leave open
Source control hosts let admins set up protected branch rules and role checks. These rules stop developers from force pushing rewritten history to the main branch. Repo permissions also decide who can log in, read code, or merge pull requests.
Still, static repo roles only check who logs in to the remote git host. They do not govern commands that engineers run on live servers or production databases. When developers log in to a server to fix code, broad shell roles allow risky commands. Native git settings cannot inspect live terminal commands or mask sensitive data like emails in outputs.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Can I recover commits after a hard reset?
Yes, Git keeps a local reference log of where your branch pointers used to point. You can read this local log to find the old commit hash and reset back to it. Still, uncommitted changes to working files are not saved in that log.
Does git reset delete untracked files?
No, even a hard reset only changes files that Git already tracks in the repo. New files that you never staged stay in your working folder until you run a clean command.
Which git reset mode is the default?
Mixed mode runs by default when you give a target commit without naming a mode. It moves your branch pointer and unstages your changes while keeping your working files intact on disk.