Basically, we encounter issues or bugs after we’ve committed our staged files before we push to repository. This experience is actually what most developers encounter almost all the time. Here I’ll show you how to undo the commit you’ve already done.

There are few ways you can achieve this;

Using git reset to undo a commit

The most common way to undo the committed files in your project is GIT RESET. RESET in this case is a form of cutting-off a specific commit that has the issues or bugs that you’re trying to get rid of. This can either remove a commit or undo the commit(s)that are no longer needed in the branch you are working on.

To utilize git reset, you must indicate the mode and the commit to which you wish to reset the branch. This is structured as follows:

$ git reset <mode> <commit id>

For the <mode> parameter, you have three flag options to choose from:

• --soft: This option allows you to reset to the specified commit while preserving the changes made in any subsequent commits. These changes will remain in your working directory and will be staged, ready to be committed again.

• --mixed: This is the default option that is applied when no other flag is specified. It resets the branch to the specified commit without altering the working directory, meaning that no files will be changed. However, the changes from subsequent commits will not be staged for commit. As a result, if you run git status, you will see all modified files listed in red, indicating that they are uncommitted and waiting to be staged.

• --hard: This flag performs a more drastic reset by changing both the staged snapshot and the working directory. It effectively removes all changes made after the specified commit, making it as if those subsequent commits never occurred. This means that any modifications will be lost, so use this option with caution.

The <commit> refers to the specific commit you want to revert to or reference. This is the commit that will serve as the new point of reference for your branch after performing the reset.

Using HEAD to undo a commit

$ git reset --hard HEAD~2

Using HEAD~2 will reset the current branch to the state it was in two commits ago, effectively removing all changes made in the last two commits from the working repository.

Pay much attention while undoing commits, especially for project that you contribute alongside other contributors

While the methods mentioned above may seem straightforward for undoing commits in a local repository, they can pose significant challenges when dealing with a remote repository, especially in collaborative environments. Altering commit history can disrupt the development workflow and lead to merge conflicts. The impact varies based on the method used:

• git reset: This command rewrites commit history, resulting in a divergence between your local and remote repositories. If other developers rely on the commits you have undone, it can lead to conflicts. Therefore, git reset is generally discouraged for remote repositories unless you are working on a personal development branch.

• git checkout: Similar to git reset, checking out a previous commit can also overwrite commit history for the entire repository. To mitigate this, you should create a new branch and resolve any merge conflicts when merging back into the main branch.

• git revert: This is the safest method for undoing commits, as it does not alter the commit history. Instead, it generates a new commit that negates the changes from a previous commit while preserving the original history. This allows other contributors to see that a commit was reverted and adjust their work accordingly.

If you choose to use git reset or git checkout to overwrite commits, you can use git push --force to update the remote branch with your local changes. However, this will overwrite any commits made after your last pull, potentially causing conflicts with changes made by other contributors. Therefore, clear communication and careful coordination with your team are essential when making such changes.