Git Reset Modes
You use git reset modes to move your current branch pointer back to an earlier commit. The three main modes control whether your staged changes and local files stay or get deleted. Most teams run these commands on local branches to clean up messy history before pushing code. Still, broad branch permissions let engineers force push reset history and overwrite shared work by mistake. How git reset modes change the three trees Git tracks your code across three separate areas on your machine. The
Git Commit Signing (GPG, SSH): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use git reset modes to move your current branch pointer back to an earlier commit. The three main modes control whether your staged changes and local files stay or get deleted. Most teams run these commands on local branches to clean up messy history before pushing code. Still, broad branch permissions let engineers force push reset history and overwrite shared work by mistake.
How git reset modes change the three trees
Git tracks your code across three separate areas on your machine. The first area is the commit history, which holds your saved snapshots. The second area is the staging index, which holds files ready for the next commit. The third area is your working folder, where you edit files on your disk.
Each mode stops at a different tree when you move the branch pointer back. Soft mode moves only the branch pointer back to the target commit. It leaves both your staging index and your working folder untouched. All changes from the undone commits wait in your staging index as ready changes. Teams use soft mode to squash several small commits into one clean commit.
Mixed mode is the standard behavior when you do not pick a mode. It moves the branch pointer back and also clears the staging index to match that commit. Your working folder keeps all the file edits on disk as unstaged changes. Engineers use mixed mode when they staged the wrong files and want to re-select their changes.
Hard mode goes all the way across all three areas. It moves the branch pointer, resets the staging index, and overwrites your working folder. Any tracked file edits since the target commit vanish from your working folder right away.
Choosing the right mode for daily team workflows
Your choice of mode depends on what you plan to do with the leftover changes. If you like the code edits and just want a new commit message, pick soft mode. If you want to break one big commit into smaller pieces, pick mixed mode. Mixed mode lets you stage a few files at a time and make separate commits.
Git Commit Signing (GPG, SSH): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Save hard mode for times when an experiment fails and you want a clean slate. Before you run a hard reset, check your working folder for any unsaved local files. Untracked files usually stay on disk, but tracked files lose all uncommitted edits right away.
What branch rules solve and the operational gap they leave
Source control platforms let admins set up protected branches to block force pushes on main branches. This setup stops an engineer from running a local reset and wiping out shared remote history. It also enforces code review rules before anyone merges changes into production branches.
Still, repo role settings only check who can push code to a git server. They do not govern what commands engineers run when they log in to live servers or databases. Many teams use git ops workflows where a branch reset triggers automated scripts against production systems. Once an engineer or runner starts a live session, static role checks step aside. Native repo rules cannot inspect individual database statements or shell commands while they run. Teams still need a way to check live commands and mask fields like emails or card numbers.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can you get back commits lost after a hard reset?
Yes, you can often recover lost commits if you already committed them on your local machine. Git keeps a local reference log of where your branch pointer stood over the last few weeks. You can look up the old commit hash in that log and move your branch back. Still, any uncommitted edits in your working folder vanish for good during a hard reset.
How does a git reset differ from a git revert?
A reset moves your branch pointer backward and rewrites the existing commit history on your branch. A revert keeps the old history intact and adds a brand new commit that undoes earlier changes. You should use revert on shared team branches so you do not break history for other engineers.
Which mode runs when you do not specify one?
Git runs mixed mode by default whenever you leave out the mode option. It moves the branch pointer back and unstages your changes, while keeping your file edits safe on disk.