- Git - Home
- Git - Version Control
- Git - Basic Concepts
- Git - Command Line
- Git - Installation
- Git - First Time Setup
- Git - Basic Commands
- Git - Getting Help
- Git - Tools
- Git - Cheat Sheet
- Git - Terminology
- Git - Life Cycle
- Git - Get a Repository
- Git - Adding New Files
- Git - Recording Changes
- Git - Viewing Commit History
- Git Branching
- Git - Branches in a Nutshell
- Git - Creating a New Branch
- Git - Switching Branches
- Git - Branching and Merging
- Git - Merge Conflicts
- Git - Managing Branches
- Git - Branching Workflows
- Git - Remote Branches
- Git - Tracking Branches
- Git - Rebasing
- Git - Rebase vs. Merge
- Git - Squash Commits
- Git Operations
- Git - Clone Operation
- Git - Tagging Operation
- Git - Aliases Operation
- Git - Commit Operation
- Git - Stash Operation
- Git - Move Operation
- Git - Rename Operation
- Git - Push Operation
- Git - Pull Operation
- Git - Fork Operation
- Git - Patch Operation
- Git - Diff Operation
- Git - Status Operation
- Git - Log Operation
- Git - Head Operation
- Git - Origin Master
- Git Undoing
- Git - Undoing Changes
- Git - Checkout
- Git - Revert
- Git - Reset
- Git - Restore Operation
- Git - Rm
- Git - Switch Operation
- Git - Cherry-pick
- Git - Amend
- Git on the Server
- Git - Local Protocol
- Git - Smart HTTP Protocol
- Git - Dumb HTTP Protocol
- Git - The SSH Protocol
- Git - The Git Protocol
- Git - Getting Git on a Server
- Git - Setting up the Server
- Git - Daemon
- Git - GitWeb
- Git - GitLab
- Git - Third Party Hosted Options
- Distributed Git
- Git - Distributed Workflows
- Git - Contributing to a Project
- Git - Maintaining a Project
- Customizing Git
- Git - Configuration
- Git - Hooks
- Git - Attributes
- Git - Init
- Git - Commit
Git Reset
In Git, the command git reset can be used to reset the current HEAD to a specified state.
This effectively resets the working directory and index to match a prior commit, or it switches the current branch pointer to the specified commit.
What it does?
1. Like reversing git add, this procedure effectively undoes changes that have been scheduled for commit.
2. Following a reset, we can use git restore to update the working tree from the index or use git restore --source=<tree-ish> to copy commit contents to the index and working tree simultaneously.
Syntax
git reset [-q] [<tree-ish>] [--] <pathspec> git reset [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]
The git reset [<tree-ish>] [--] <pathspec> - command resets the index entries for specified paths ( <pathspec>) to match their state at <tree-ish<, without affecting the working tree or the current branch.
git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>]
The git reset --patch or -p command allows interactive selection of hunks between the index and <tree-ish> (defaults to HEAD).
Certain modifications that have been staged for commit are essentially undone by reversing and applying certain hunks to the index.
This functionality allows selective modification or removal of changes in the staging area, similar to git add --patch.
git reset [<mode>] [<commit>]
The command git reset [<mode>] [<commit>] modifies the index and working tree according to <mode>, and resets the current branch head to <commit>.
The default value is --mixed if <mode> is not specified.
--soft - Leaves modifications as Changes to be committed and moves the branch head to <commit> without altering the working tree or index.
--mixed - Marks changes as unstaged and resets the index to <commit> while maintaining modifications in the working tree.
--hard - Deletes all modifications made after <commit> and resets the working tree and index to <commit>.
--merge - Git handles unmerged index items, resets the index, and updates the working tree files that differ between <commit> and HEAD.
--keep - Like --merge, but it stops if local modifications are made to files that are different between <commit> and HEAD.
--[no-]recurse-submodules - When the working tree is updated, it updates the working trees of the submodules to match the commit noted in the superproject.
With the help of these parameters, Git can be more flexible in how it handles modifications to the index, working tree, and submodules when it resets the repository's state to a particular commit.
Options
The following options can be used with the git reset command:
-q or --quiet
Git suppresses all output except error messages when the -q or --quiet option is used.
--refresh / --no-refresh
Git's --refresh option makes sure that following a mixed reset (git reset --mixed), the index is updated.
In order to ensure that the index reflects the modifications following a reset action, this feature is enabled by default.
On the other hand, following a mixed reset, --no-refresh prevents this automatic index refresh.
git reset --refresh
--pathspec-from-file=<file>
Git offers an option called --pathspec-from-file=<file> that lets us specify pathspec patterns from a file rather than straight from the command line.
It reads from standard input if <file> is -.
Pathspec elements can be quoted as indicated by the core.quotePath configuration variable and are separated in the file by LF or CR/LF.
For effective management of lengthy or intricate pathspec patterns, this option is helpful.
--pathspec-file-nul
Git's --pathspec-file-nul option changes how --pathspec-from-file behaves.
It is specified that NUL characters will be used to separate pathspec items in the file; all other characters, including newlines and quotes, will be treated literally.
- When pathspec patterns contain special or complex characters that must be kept exactly as they exist in the file, this option can be helpful.
git reset --pathspec-from-file=file-list.txt --pathspec-file-nul
--pathspec-from-file=file-list.txt − Tells Git to read the file paths from file-list.txt.
--pathspec-file-nul − Specifies that the file paths in file-list.txt are separated by null (\0) characters rather than the default newline (\n).
--
Git commands with -- indicate that any further arguments should be handled as file names or paths rather than options.
git rest -- <file>
It is commonly referred to as the separator option. It is not exclusive to git reset but is a general Git convention that tells Git to interpret everything after the -- as file paths.
--soft
It moves the HEAD to the specified commit but leaves the staging area and working directory unchanged.
Changes are still staged (index is unchanged).
Shows no changes in the working directory.
git reset --soft HEAD~1
--mixed
It moves the HEAD to the specified commit and also un-stages any changes that have been staged.
It is the default option.
The working directory remains unchanged.
The staging area is reset to the state of the specified commit.
git reset --mixed HEAD~1
--hard
It moves the HEAD to the specified commit, resets both the staging area and the working directory to match the specified commit.
All uncommitted changes are lost.
git reset --hard <commit>
Use git reset cautiously, especially with the --hard option, because it can lead to loss of changes.
--keep <commit>
It resets the index to the specified commit but keeps the local changes that can be applied cleanly to the working directory.
The reset will stop if there are conflicts with the local changes.
git reset --keep <commit>
--merge <commit>
It resets the index but preserves changes in the working directory that are different between the current HEAD and the specified commit.
In case of a failed merge, this option is used, which resets back to a clean slate.
git reset --merge HEAD~1
Hence, the command git reset can be applied to the working directory, the staging area (index), or the commit history, depending on the options you use.