Git Commit Resetting, Checking Out & Reverting

6 min readAug 10, 2023

Git Commit Resetting, Checking Out & Reverting.

Actually, I thought to write this blog When I made a mistake while doing my project in GitLab.When it comes to talking about my mistake, I forgot to stash my last changes, and I committed them without getting pulled from the current working branch. So I thought I would write this blog and share my experience and knowledge with you all.

What is Git commit?

The “commit” command is used to save your changes to the local repository.

Since we have finished our work, we are ready to move on stage to commit for our repo. Adding commits keeps track of our progress and changes as we work. Git considers each commit change point or "save point". It is a point in the project you can go back to if you find a bug, or want to make a change. When we do, we should always include a message.

By adding clear messages to each commit, it is easy for yourself (and others) to see what has changed and when.

What is git checkout?

In Git, the term checkout is used for the act of switching between different versions of a target entity. The git checkout command is used to switch between branches in a repository. Be careful with your staged files and commits when switching between branches.

The git checkout command operates on three different entities which are files, commits, and branches. Sometimes this command can be dangerous because there is no undo option available.

It checks the branches and updates the files in the working directory to match the version already available in that branch, and it forwards the updates to Git to save all new commits in that branch.

Operations on Git Checkout

We can perform many operations by git checkout commands like the switch to a specific branch, creating a new branch, checkout a remote branch, and more. The git branch and git checkout commands can be integrated.

What is Git Resetting?

The term reset stands for undoing changes. The git reset command is used to reset the changes. The git reset command has three core forms of invocation. These forms are as follows.

Soft
Mixed
Hard

If we say in terms of Git, then Git is a tool that resets the current state of HEAD to a specified state. It is a sophisticated and versatile tool for undoing changes. It acts as a time machine for Git. You can jump up and forth between the various commits. Each of these reset variations affects specific trees that git uses to handle your file in its content.

Additionally, git reset can operate on whole commit objects or at an individual file level. Each of these reset variations affects specific trees that git uses to handle your file and its contents.

Git Reset to Commit

Sometimes we need to reset a particular commit; Git allows us to do so. We can reset to a particular commit. To reset it, the git reset command can be used with any option supported by the reset command. It will take the default behavior of a particular command and reset the given commit. The syntax for resetting the commit is given below:

$ git reset <option> <commit-sha>

These options can be

— soft
— mixed
— Hard

What is Git Reverting

In Git, the term revert is used to revert some changes. The git revert command is used to apply the revert operation. It is an undo-type command. However, it is not a traditional undo alternative. It does not delete any data in this process; instead, it will create a new change with the opposite effect and thereby undo the specified commit. Generally, git revert is a commit.

It can be useful for tracking bugs in the project. If you want to remove something from history then git revert is the wrong choice.

Moreover, we can say that git revert records some new changes that are just opposite to previously made commits. To undo the changes, run the below command:

$ git revert

How to revert a Git commit

The net effect of the git revert the command is similar to reset, but its approach is different. Where the reset command moves the branch pointer back in the chain (typically) to "undo" changes, the revert the command adds a new commit at the end of the chain to "cancel" changes. The effect is most easily seen by looking at Figure 1 again. If we add a line to a file in each commit in the chain, one way to get back to the version with only two lines is to reset to that commit, i.e., git reset HEAD~1.

Another way to end up with the two-line version is to add a new commit that has the third line removed — effectively canceling out that change. This can be done with a git revert command, such as:

$ git revert HEAD

Revert or reset?

Why would you choose to do revert over a reset operation? If you have already pushed your chain of commits to the remote repository (where others may have pulled your code and started working with it), a revert is a nicer way to cancel out changes for them. This is because the Git workflow works well for picking up additional commits at the end of a branch, but it can be challenging if a set of commits is no longer seen in the chain when someone resets the branch pointer back.

This brings us to one of the fundamental rules when working with Git in this manner: Making these kinds of changes in your local repository to code you haven’t pushed yet is fine. But avoid making changes that rewrite history if the commits have already been pushed to the remote repository and others may be working with them.

In short, if you roll back, undo, or rewrite the history of a committed chain that others are working with, your colleagues may have a lot more work when they try to merge in changes based on the original chain they pulled. If you must make changes against code that have already been pushed and are being used by others, consider communicating before you make the changes and give people the chance to merge their changes first. Then they can pull a fresh copy after the infringing operation without needing to merge.

You may have noticed that the original chain of commits was still there after we did the reset. We moved the pointer and reset the code back to a previous commit, but it did not delete any commits. This means that, as long as we know the original commit we were pointing to, we can “restore” back to the previous point by simply resetting back to the original head of the branch:

git reset <sha1 of commit>

A similar thing happens in most other operations we do in Git when commits are replaced. New commits are created, and the appropriate pointer is moved to the new chain. But the old chain of commits still exists.

References

Follow me on GitHub: Madhusha Prasad