Reverting Commits in GitHub
26 Aug 2022 / 9 minutes to read
In my previous posts “GIT in 10 minutes” and Collaboration in GitHub, I have covered the basics of Git setup, a few workflow commands to get started using Git (version control system), and collaborative work, including operations with forks and pull requests. As promised, I will go into more detail about working with Git repositories. Herein I will focus on reverting your changes. Sometimes it’s good to step back and think about something different, right?
The Setup and Usual Workflow
I assume here the following setup:
- We work on a GitHub project with other team members working together on an “upstream” repository.
- We have forked this upstream repository and named our fork “origin.”
- We have a local copy of the origin repository (which we sync regularly with the upstream repository)
- This local copy of the origin repository (forked one) is changed with the next code contributions.
- We commit our local changes to the origin forked repository.
- In the forked repository, we create a Pull Request to the upstream repository.
The workflow can be described with the following example.
Cloning your forked repo locally
git clone <tocken>@github.com/<user/<repo>
git remote add upstream https://githubcom/<upstream_user>/<repo>
Working on your branch
git checkout master
git checkout -b your_branch_name
git fetch upstream
git add .
git commit -m' message'
# use -u for your first push
git push -u origin your_branch_name
Possibly, we revert our changes
We might reconsider the changes at this step and try to revert the commit.
Next, we will go to your GitHub forked repository and click the “Compare & Review” green button beside the branch button. Or, on your fork page, press the “Pull Request” button.
We might want to do the changes after PR
At this stage, we cannot just revert commit so quickly. We will need to proceed with a new PR.
It’s important to mention that when working with the remote repository, pulling the most recent changes from the master is essential. Before that, ensure that the upstream remote is set up (with git remote -v).
git pull upstream master
GitHub cases to Revert Changes
Sometimes we do not want to keep the changes that are already committed. Let’s consider the following cases of when and how we revert or disregard these changes.
There are two main ways to revert changes:
- git reset wipes out all the commits starting from the commit we want to preserve;
- git revert saves the history and is a safe way to roll back changes.
GitHub Docs “Reverting a commit” state that reverting a commit is a commit, and it is good practice reverting commits “order from newest to oldest.” Use “git log” to check the commit history and hashes of commits.
This output will include the hash strings you can use to revert a commit. The identifier string is located to the right of the word “commit.”
Author: Elena Daehnhardt email@example.com
Date: Mon Jul 11 13:28:22 2022 +0200
Author: Elena Daehnhardt firstname.lastname@example.org
Date: Mon Jul 11 13:27:52 2022 +0200
+forks update, fetch upstream
A hash code identifies each commit and can be used to manage or see the related commit. With git checkout, we can analyze the commit with the defined hash.
git checkout [hash]
With git revert, we revert to the previous commit with the defined hash code.
git revert [hash]
Git Reset can be used to set a repository back to a specific commit.
git reset [hash]
Interestingly, we can also undo the reset of a commit when we know the commit hash of the reset.
It is essential to mention that we should avoid changing the commit history when working on remote repositories, especially when collaborating with others. When the commit was not yet uploaded into a remote server, we can reset to a previous commit before any changes are made using the following options.
Option 1. cleans up all your changes which are lost. This option will altogether remove any changes from the local repository.
git reset --hard [hash]
To update the remote repository after the hard reset, you can do a force push. Herein “origin” is the name of remote, and “main” is its branch name.
git push -f origin main
Option 2. resets to the commit, and your changes are preserved with stashes (first saved, then hard reset, and finally with pop).
git reset --hard [hash]
git stash pop
Option 3. resets the commit history but preserves your files.
git reset --soft [hash]
Option 4. default option unstaging the changes. This option will reset back to the commit with the defined hash number.
git reset --mixed [hash]
Option 5. resetting to the latest commit just before the HEAD.
git reset --mixed HEAD~
Option 6. When things go totally wrong, we can use the hard reset option.
git fetch origin
git checkout main
git reset --hard origin/main
git clean -d --force
Reverting Pushed Changes to Remote
We must prefer revert operations wherein we want to revert changes already pushed to the remote repository. We want to keep the history for other persons working on the repository.
To modify the history of your commits, use ‘git rebase’ with caution. It is possible to edit, delete, reorder, or squash commits with the Git rebase. This command lets you work interactively with the latest five commits in your current branch.
git rebase --interactive HEAD~5
In this post, I have covered fixing commit mistakes in Git. We have observed that reverting changes is a safer option than resetting. We have learned how to check the commit history and get commit hashes. Also, I did some stash changes when we wanted to keep them while doing the reset. Git rebase is another option to interactively cherry pick, join, reorder and delete commits. In my next post, I am going into more detail about GitHub merge conflicts.
Did you like this post? Please let me know if you have any comments or suggestions.Git posts that might be interesting for you
Elena, a PhD in Computer Science, simplifies AI concepts and helps you use machine learning.