Undoing Changes with Git: Checkout and Revert

1. Undoing Before You Commit: Discarding Local Changes

Imagine you're working on a file, you've made some experimental changes, and you realize they're not going in the right direction. The changes are not yet staged (git add) or committed. You simply want to throw them away and go back to the version that's in the last commit. This is a very common scenario.

The command for this is git checkout. While we've used git checkout before to switch branches, it has another powerful function when used with a file path.

The syntax is:
git checkout -- <file_path>

The -- is important. It's a standard convention in command-line tools to separate command options from arguments (like file paths). It explicitly tells Git that what follows is a file path, not a branch name, preventing any ambiguity.

Let's see this in action.

Hands-on Practice

Let's try this yourself. In a practice repository:

1. Open a file that is already tracked by Git.
2. Add a few lines of text and save the file.
3. Run git status. You'll see the file listed under "Changes not staged for commit".
4. Now, discard those changes by running: git checkout -- <your_file_name>.
5. Run git status again. It should report that your working tree is clean. If you open the file, you'll see your recent changes are gone.

A Note on Modern Git: git restore

In recent versions of Git (2.23+), a new command, git restore, was introduced to make these actions more explicit. The git checkout command does many different things (switch branches, restore files), which can be confusing. git restore is designed specifically for undoing changes in the working directory.

To do the same thing we did above, you would use:
git restore <file_path>

While the learning outcome focuses on checkout—a command you must know as it's ubiquitous in older tutorials and codebases—it's good practice to start using git restore for this task. It's clearer and less prone to mistakes. The article "A Comprehensive Guide to Undoing Changes In Git" from Initial Commit provides a quick reference for this. It notes that you can discard all local changes with git restore . or unstage a file with git restore --staged <file>.

2. Undoing After You Commit: Safely Reversing Public Commits

Now for a more complex scenario. What if you've already committed your changes? And worse, what if you've already pushed them to a shared remote repository like GitHub?

You cannot simply delete the commit. That would rewrite the project's history. If a teammate has already pulled your changes and started building their own work on top of it, deleting the commit from the history would cause massive problems and conflicts for them. This is the cardinal rule of Git collaboration: do not rewrite public history.

So, how do you undo a bad commit that's already public? You revert it.

The git revert command is the safe, non-destructive way to undo a commit. It works by creating a brand new commit that does the exact opposite of the commit you want to undo.

• If the original commit added a line, the revert commit will remove that line.
• If the original commit removed a file, the revert commit will add that file back.

The original, problematic commit remains in the project history, but its effects are canceled out by the new revert commit. This keeps the history intact and transparent.

To use it, you need the hash of the commit you want to revert. You can find this using git log.

The syntax is:
git revert <commit_hash>

Let's watch a demonstration.

When you run git revert, Git will open your configured text editor to let you write a commit message for the new revert commit. The default message is usually sufficient (e.g., "Revert 'Add feature X'"). After you save and close the editor, the new commit is created.

Summary: checkout vs. revert

It's crucial to understand the difference between these two ways of undoing things. The Atlassian article you read earlier contains a handy table summarizing the use cases.

As a DevOps professional, knowing when to use a history-preserving command like revert versus a history-altering command (which you'll learn about next) is fundamental to maintaining a healthy and reliable version control workflow for your team.

Conclusion

In this lesson, you've learned two distinct but equally important methods for undoing work in Git.

Key Takeaways:

• To discard local, uncommitted changes in a file, use git checkout -- <file> (or the more modern git restore <file>). This reverts the file to its state at the last commit.
• To safely undo a commit that has been shared or published, use git revert <commit_hash>.
• git revert does not delete or change history; it creates a new commit that applies inverse changes, making it the standard and safe method for reversing changes on collaborative branches.

In our next lesson, we will explore a powerful, but more advanced, way to undo changes: git reset. Unlike revert, reset actually rewrites commit history, making it incredibly useful for cleaning up your local, un-pushed commits, but dangerous to use on shared branches. Understanding the difference between revert and reset is a key step toward Git mastery.