Undoing Changes: Reverting Commits and Resetting Branches

Even with the best planning, sometimes you'll want to undo changes you've made. Git provides powerful tools to rewind your project's history. It's crucial to understand that undoing changes, especially in a shared repository, has implications. We'll cover two primary ways to do this: reverting commits and resetting branches.

Reverting Commits: Creating a New History

When you revert a commit, Git doesn't actually delete the old commit. Instead, it creates a new commit that undoes the changes introduced by a previous commit. This is a safe way to undo changes because it preserves the history of what happened, making it easier to track why a change was undone. It's generally the preferred method for undoing changes that have already been pushed to a shared remote repository.

To revert a commit, you'll use the git revert command followed by the commit hash of the commit you want to undo.

Let's say you want to revert the commit with the hash a1b2c3d4. You would run:

Git will then open your default text editor to allow you to write a commit message for this new revert commit. The default message will explain which commit is being reverted. After saving and closing the editor, the revert commit will be created.

Resetting Branches: Rewriting History

Resetting branches is a more forceful way to undo changes. Instead of creating a new commit, git reset moves your branch pointer to a different commit, effectively discarding commits that came after it. This rewrites history, and therefore, it should be used with extreme caution, especially on branches that have been pushed to a shared remote repository. Doing so can cause significant problems for collaborators.

There are three main modes for git reset:

git reset --soft

This moves the branch pointer to the specified commit, but keeps all the changes from the discarded commits in your staging area. This is useful if you want to re-commit the changes differently.

The HEAD~1 refers to the commit immediately before the current HEAD (your current commit). This command would move your branch back one commit, and the changes from the last commit would be staged.

git reset --mixed (Default)

This moves the branch pointer and unstages all changes from the discarded commits. The changes will remain in your working directory, but they won't be staged for the next commit.

This is the default behavior if you omit the mode. It moves the branch back one commit, and the changes from that commit are now unstaged.

git reset --hard

This is the most destructive mode. It moves the branch pointer and discards all changes in both the staging area and your working directory from the discarded commits. Use this only when you are absolutely sure you want to permanently lose those changes.

This command would move your branch back one commit and completely erase all traces of the last commit's changes from your working directory and staging area.

Visualizing the Difference

Let's illustrate the difference between reverting and resetting with a simple history. Imagine your commit history looks like this:

graph TD;
    A[Commit A] --> B[Commit B];
    B --> C[Commit C];
    C --> D[Commit D];

If you git revert D, you'll get a new commit that undoes D, resulting in:

graph TD;
    A[Commit A] --> B[Commit B];
    B --> C[Commit C];
    C --> D[Commit D];
    D --> E[Revert of D];

The history is preserved, and the state is as if D never happened (though D is still recorded).

If you git reset --hard C, your history will become:

graph TD;
    A[Commit A] --> B[Commit B];
    B --> C[Commit C];
    subgraph After Reset
    C
    end

Commits D and any subsequent commits are gone. This rewrites history and should be avoided on shared branches.

When to Use Which

• Use git revert: When you need to undo changes that have already been pushed to a shared repository. It's safe, preserves history, and avoids confusing collaborators.

• Use git reset: Primarily on your local, unpushed branches when you want to discard recent work and are confident that those changes are not needed by anyone else. Be very careful with git reset --hard as it can lead to data loss.

Always communicate with your team before performing operations that rewrite history on shared branches.