Git Undo: 13 Ways to Undo Mistakes in Git

Last Updated on December 11, 2024

In the words of American motivational writer William Arthur Ward “to make mistakes is human; to stumble is commonplace; to be able to laugh at yourself is maturity”. Not all mistakes in life are easy to recover from, but the main goal of technology development is to make the world less tangled.

Troubles could appear due to human error or hardware malfunction, so you should be prepared to deal with them in the most efficient way. To meet your needs we created a list of 13 handy tips to undo mistakes in Git in an effortless way. So, read them and stay up to date.

#1 Discarding local changes

Sometimes not everything is going according to plan. Let’s suppose you have a rough day at work and accidentally has saved changes with some mistakes. There’s nothing to worry about! If you are wondering “how do I discard changes in my working copy”, you haven’t committed changes yet and want to go back to the previous state of that file, use the following git checkout command:

git checkout -- <filename>

The changes you’ve made to the file will be replaced with the most recent version previously known to Git in the commit history. Make sure you really want to do it, because after that command changes are gone for good. Either way, it is a very useful tool to know.

#2 Undo committed changes

Git revert. Similar case to the previous one, but you already committed changes and only now see that something is wrong. Do not panic, there are other git commands, just type:

git revert <commit>

The above command is used to reverse the effects from the last git commit in the commit history. It’s safe to use because it creates an opposite commit and does not override Git history. 

#3 Reset local changes

In this case, you made commits locally and did not push changes yet. Now you see that not everything seems to be OK, so you want to undo a couple of commits to the last good version. 

git reset <wanted SHA version>

Git reset command simply rewinds the repository’s history to the chosen SHA version, so commits made after it is no longer applied. They are gone, but the contents are still on the disk.

#4 Change the most recent commit message

If you made a typo in the last git commit message and you don’t want to feel embarrassed about it, there’s a quick fix. Nobody needs to know, just use this command:

git commit --amend

After that, your last commit message will be updated and replaced.

#5 Switch a commit to a different branch

Branch names are usually pretty similar, so it is not unusual to get them twisted. If you made a git commit to the wrong one and want to apply it to the correct one, here is a useful command: 

git cherry-pick <commit>

You can select a commit from one branch and apply it to another using cherry-pick. Make sure you’re on the branch you want to apply the specific commit to before starting the process. Remember to delete the commit from the branch you applied it to by mistake.

#6 Restore a deleted branch

Mixing branch names could also resolve in deleting the wrong one. So, when that happens you are safe and prepared by having this command in your repertoire:

git checkout -b <branch> <sha>

Check one of our older articles to learn more about how restoring deleted branch in Bitbucket go.  

#7 Stop tracking a tracked file

You mistakenly added application.log to the repository, and now Git indicates that there are unstaged changes in application.log every time you run the application. How can you tell git to “undo” tracking changes in this file if you placed *.log in the.gitignore file but it’s still there?

git rm --cached application.log

While.gitignore stops Git from monitoring changes to files or even discovering the existence of files it hasn’t previously monitored, once a file has been added and committed, Git will continue to notice changes to that file.

#8 Reviewing old commits

Any version control system is designed to store “safe” copies of a project so that you never have to worry about damaging your code base irrevocably. You may examine and revisit any commit in a project’s history once you’ve built up a history of commits. The git log command is one of the greatest tools for examining the history of a Git repository.

git log --oneline

By default, git log only shows commits for the branch that is presently chosen, so to say previous commit.

#9 The staging index

To add updates to the staging index, use the git add command. Git reset is mostly used to revert changes to the staging index. Any pending modifications from the staging index will be moved back into the working directory with a —mixed git reset.

#10 Restoring a deleted file (before commit)

It’s quite unusual to lose your files on Git after committing your work. To completely lose a file on Git, you must delete your whole local repository and have no backup on the remote server.

What if you erased a file without saving it and then realized you’d made a mistake? Simply type the following command:

git checkout HEAD <filename>

How to restore deleted files in a git repository? The answer to this question you will also find in one of our previews texts. 

#11 Restoring a deleted file (after commit)

This solution is for when you accidentally deleted a file, committed the deletion, and then realized you needed it. You’ll need to reboot your computer to restore this file. This git reset will put you back in the state you were in before you committed. Before running the command, keep in mind that the ‘Hard’ directive on the code will overwrite any modifications made to the file after the commit. This approach assumes that you have not uploaded your file to a remote site.

et --hard HEAD~1

#12 Deleting old commits

There exists a safe way of deleting a commit in the middle of the history: using the git revert command. It adds a new commit, which undoes everything the middle commit has changed.

git revert <sha1-commit-hash>

#13 Backup all your DevOps tools and data

To be sure that more costly mistakes made by outside providers and human error are reversible, use the GitProtect backup solution for GitHub, Bitbucket, GitLab, and Jira.

A reliable backup plan suited for your company’s or/and personal need could save you time and loads of stress. If your organization relies on GitHub tools, then GitHub backup by GitProtect is really helpful while you are dealing with:

• HEAD overwrite, branch deletion, old repository deletion, hardware failure, and other human or technical issues.
• Service providers delete data by accident.
• Ransomware assaults have wiped out all the content of repositories.
• And many other cases.

Summary 

Unfortunately, we all know that we cannot avoid mistakes. Trial and error are curial in the development process of the product and engineering career. No matter how great programmers we are, we’ll slip up sometimes. The main question, therefore, is not if we make mistakes, but rather how well we can deal with them and fix the problems we are facing. Fortunately, Git offers a series of methods for undoing and recovering from both minor and major errors. And if you are dealing with some catastrophic events, the reliable backup and first true Disaster Recovery available within GitProtect DevOps backup are going to be your best chance to resolve a crisis within minutes. Gather knowledge from your (and others’) mistakes without the consequences of them dragging you down using this tutorial. 

[FREE TRIAL] Ensure compliant DevOps backup and recovery with a 14-day trial 🚀
[CUSTOM DEMO] Let’s talk about how backup & DR software for DevOps can help you mitigate the risks

Frequently Asked Questions

How do I undo everything in Git?

To undo all changes in your repository and return it to the stage of your last commit, the most common command is:

git reset --hard HEAD

It discards any changes in both your working directory and staging area, resetting everything to match the most recent commit (HEAD). It’s important to note that this action is destructive. It removes all uncommitted changes permanently.

Another option for undoing changes, but in a more targeted way (e.g., just unstaging files) is:

git reset HEAD <file>

The command only resets the file(s) in the staging area but keeps local changes in the working directory.

How can I undo all changes since the last commit?

If you want to undo all changes made since the last commit, you can use:

git reset --hard HEAD

This command resets the working directory and staging area to their state at (the time of) your last comment. The procedure is irreversible. It’s crucial to have a backup before executing.

An additional option may be:

git reset --soft HEAD

It will reset the HEAD to the previous commit, but the changes will remain in your working directory. However, if you plan to reset the HEAD to the last commit and remove the changes from your staging area but keep them in your working directory, use the:

git reset --mixed HEAD

When you aim to reset the working directory and leave the staging area alone (e.g., you want to unstage files but keep the local modifications), insert:

git checkout .

This method restores all files in the working directory to their last committed state without altering the staged state.

What is the difference between Git revert and Git restore?

The git revert command creates a new commit that undoes the changes introduced by a previous commit. Unlike reset, revert is non-destructive. It doesn’t erase history but leaves a record of the changes, essentially “reversing” their effects.

The revert is commonly utilized when working with others. It maintains the project’s commit history and avoids force-pushing to shared branches.

For example, if you want to undo commit xyz, you would use:

git revert xyz

That creates a new commit that undoes the changes while keeping the commit history intact.

In the case of git restore (introduced in Git 2.23), you can restore files to a previous state from either the index (staging area) or a specific commit.

It helps discard local changes in the working directory or roll back files to an earlier state. The restore command does not create new commits or change history.

As an example, let’s restore a file to its last committed state:

git restore <file>

In this case, the command only restores a file in the working directory or the staging area to the last committed state. 

What is Git reset hard?

It’s a command used to reset the commit history, staging area, and working directory to a specific commit. If no commit is specified, it defaults to HEAD. It means the last commit on your current branch.

It permanently deletes any changes made after the specified commit, including staged and unstaged changes.

git reset --hard HEAD

The command resets everything to the last commit, discarding all local modifications and staged files. You can also use it to reset the branch pointer to an earlier commit by specifying a commit hash:

git reset --hard <commit-hash>

However, this approach removes all commits after the specified one, effectively alternating your branch’s history.

Which Git command do you use to resolve conflicting changes?

Conflicting changes arise when Git cannot automatically merge two branches. After resolving the issue manually or using a tool, you ought to stage the changes and commit them to complete the merge process.

When conflicts occur – typically during a git merge or git rebase – Git marks the conflict sections in the affected files. To resolve the problem, you need to:

• manually resolve the conflicts by editing the conflicting files, removing the conflict markers, and choosing the correct version
  
• stage the resolved files with:

git add <file>

• complete the merge:

git commit

If you want to use an external tool to help with resolving conflicts, utilize:

git mergetool

You’ll launch a graphical or terminal-based merge tool to resolve conflicts interactively.