Git Revert and Reset

Understand how to revert (undo) changes made in commits using 'git revert'. Learn the different types of reset (soft, mixed, hard) and their effects using 'git reset'.


Advanced Git Reset Techniques (Optional)

This section explores more advanced uses of git reset, going beyond the basic scenarios covered earlier. These techniques offer greater control over your Git history but require careful consideration to avoid data loss or disrupting collaboration.

Resetting to Specific Points in the Past

While git reset HEAD~N moves the branch pointer a relative number of commits, you can also reset to a specific commit using its SHA hash.

Resetting to a Specific Commit (Hard Reset)

This will discard all changes made after the specified commit. Use with extreme caution, as this can lead to permanent data loss if not properly backed up.

git reset --hard <commit-hash>

Replace <commit-hash> with the actual SHA hash of the commit you want to revert to. You can find the commit hash using git log.

Resetting to a Specific Commit (Soft Reset)

This will move the branch pointer to the specified commit, but keep the changes made afterwards in the staging area.

git reset --soft <commit-hash>

This is useful if you want to undo commits but keep the changes for further modification or reorganization.

Resetting to a Specific Commit (Mixed Reset)

This will move the branch pointer to the specified commit, and unstage the changes made after the commit. The changes will remain in your working directory.

git reset --mixed <commit-hash>

This is the default behaviour of git reset. Equivalent to git reset <commit-hash>.

Handling Remote Branches After a Reset

Resetting a branch that has already been pushed to a remote repository can cause problems, especially if others are collaborating on the same branch.

The Danger of Rewriting History on a Shared Branch

If you rewrite history (e.g., using git reset --hard) and then try to push the modified branch to a remote, Git will likely reject the push. This is because the remote repository has a different version of the branch history.

Force Pushing (Use with Caution)

To force the push and overwrite the remote branch's history, you can use the --force option. This is strongly discouraged in most collaborative scenarios as it can lead to confusion and data loss for other developers.

git push --force origin <branch-name>

Alternatives to Force Pushing:

  • Revert: Use git revert to create new commits that undo the changes introduced by the commits you want to remove. This is a safer approach as it doesn't rewrite history and is easily shared with others.
  • Create a New Branch: Create a new branch from the point where you want to start over, and abandon the old branch. This isolates your changes and avoids disrupting other developers.
  • Coordinate with Your Team: If force pushing is absolutely necessary, communicate with your team beforehand and ensure they understand the implications and take appropriate precautions (e.g., backing up their work).

Example Scenario

Imagine you've made several commits to a feature branch but realize you've gone down the wrong path. You want to revert to a commit before you started making those changes. Here's how you might use git reset (combined with other Git commands) to address this:

  1. Identify the target commit: Use git log to find the SHA hash of the commit you want to revert to.
  2. Perform a soft reset:git reset --soft <commit-hash>. This will move the branch pointer back but keep your changes staged.
  3. Unstage and stash (optional): If you want to clean up your working directory, use git reset (without any options) to unstage the changes, and then use git stash to save them for later use.
  4. Restart development: Now you can start making changes from the earlier point in history.

Conclusion

git reset is a powerful tool, but its advanced uses require careful consideration and a solid understanding of Git's internal workings. Always back up your work and communicate with your team before making any potentially disruptive changes to shared branches. Prioritize safer alternatives like git revert and creating new branches whenever possible.