Git Revert: Rolling Back in GitOps and Kubernetes

What is Git Revert?

The git revert command is similar to an undo operation, but unlike a regular undo, it does not completely reverse the original operation. The revert command relates to a specific commit. It does not remove a commit from version history—instead, it creates a new commit with inverse content, reverting the project to the previous state before the commit.

Using revert in Git ensures that you do not lose a record of a reverted commit. The version history will show the original commit, and subsequently, the revert operation, which canceled out that commit. This is important for consistent revision history and reliable collaboration.

Revert can be used for fixing bugs or issues that result from a specific commit. If you identify that a bug originated from a commit, you can revert that commit and essentially bring the application back to its original state, which should be bug-free.

In Kubernetes, a Git revert command is a way to roll back the application to a previous state. When using GitOps to manage your Kubernetes development, Git revert is a way to roll back while retaining complete version history in source control for all team members.

This is part of a series of articles about Git Errors.

Difference Between Git Revert, Git Checkout and Git Reset

Let’s examine the difference between three related Git commands: revert, checkout, and reset.

Git Checkout vs. Git Revert

While Git revert creates a commit that is the inverse of a previous commit, Git checkout pulls content from a Git repository and adds it to a specific user’s work tree. The checkout command can also change the branch a specific user is working on. However, it has no effect on version history.

Use git checkout when: you changed a file but did not commit it yet, and want to start from a fresh copy of the file drawn from the repository.

Git Reset vs. Git Revert

Git reset changes the Git index, also known as the staging area, or it can change the commit that functions as a branch head. If this command changes the commit referenced by a head branch, it can change version history. The difference between reset and revert is that while reset completely changes an index or branch, revert only reverses the impact of a specific commit.

Use git reset when: you made a commit, but want to go back to a previous version of the repository where that commit never happened.

Git Revert Example

The following example shows a case in which Git revert is needed—a file is committed to a Git repository and then committed again with an unwanted change.

$ git add example.txt
$ git commit -m "good commit"
[master (root-commit) 2e5674f] initial commit
1 file changed, 1 insertion(+)
create mode 100644 example.txt
$ echo "unwanted change" > example.txt
$ git commit -am "bad commit"
[master e13948a] bad commit
1 file changed, 1 insertion(+), 1 deletion(-)

The following line reverts the commit:

$ git revert HEAD
[master d1b8387] Revert "bad commit"
1 file changed, 1 insertion(+), 1 deletion(-)

The log now shows three changes:

d1b8387 Revert "bad commit"
e13948a bad commit
2e5674f good commit

At the end of the process, the file system will show no unauthorized changes to the file.

Git Reset vs. Git Revert

Git reset changes the Git index, also known as the staging area, or it can change the commit that functions as a branch head. If this command changes the commit referenced by a head branch, it can change version history. The difference between reset and revert is that while reset completely changes an index or branch, revert only reverses the impact of a specific commit.

Use git reset when: you made a commit, but want to go back to a previous version of the repository where that commit never happened.

Git Revert Example

The following example shows a case in which Git revert is needed—a file is committed to a Git repository and then committed again with an unwanted change.

$ git add example.txt
$ git commit -m "good commit"
[master (root-commit) 2e5674f] initial commit
1 file changed, 1 insertion(+)
create mode 100644 example.txt
$ echo "unwanted change" > example.txt
$ git commit -am "bad commit"
[master e13948a] bad commit
1 file changed, 1 insertion(+), 1 deletion(-)

The following line reverts the commit:

$ git revert HEAD
[master d1b8387] Revert "bad commit"
1 file changed, 1 insertion(+), 1 deletion(-)

The log now shows three changes:

d1b8387 Revert "bad commit"
e13948a bad commit
2e5674f good commit

At the end of the process, the file system will show no unauthorized changes to the file.

Tips from the expert

Itiel Shwartz

Co-Founder & CTO

Itiel is the CTO and co-founder of Komodor. He’s a big believer in dev empowerment and moving fast, has worked at eBay, Forter and Rookout (as the founding engineer). Itiel is a backend and infra developer turned “DevOps”, an avid public speaker that loves talking about things such as cloud infrastructure, Kubernetes, Python, observability, and R&D culture.

In my experience, here are tips that can help you better handle Git revert in GitOps and Kubernetes:

Use Git tags for version control

Tagging releases ensures you can easily revert to specific versions.

Automate rollback with CI/CD

Integrate rollback procedures into your CI/CD pipelines for seamless reverts.

Document changes thoroughly

Keep detailed commit messages and documentation for easier reversion.

Implement canary deployments

Gradually deploy changes to minimize the impact of potential rollbacks.

Use feature flags

Feature flags allow you to toggle features on and off without code changes.

GitOps, Kubernetes, and Git Revert

GitOps is a method used to manage Kubernetes clusters and deliver applications more efficiently. It uses Git as the only trusted source of declarative infrastructure and applications for Kubernetes clusters.

GitOps typically uses a software agent to alert when there are differences between the Git repository and what is actually running on the cluster. If there is a difference, Kubernetes controllers perform an update or rollback to adapt the cluster to the desired state reflected by the Git repository.

GitOps lets developers use one set of tools to manage Kubernetes and other technologies, such as serverless functions or standalone compute instances. It also enables consistent deployment, operations, and monitoring using familiar processes based on existing CI/CD pipelines.

There are two important things to consider with regard to git revert in a GitOps setting:

• Git reverts indicate that something went wrong with a deployment – they provide valuable information on what went wrong and what a team did to fix it. This can facilitate change management.
• Git reverts can have unexpected consequences – when someone reverts a change, the rest of the codebase may have changed, and this could cause a chain reaction in other, dependent modules. When using GitOps, git revert should be used carefully, and new bugs or issues in an application can often be traced back to a git revert operation.

Using Git Revert to Roll Back to Previous Application State

In GitOps, the declarative system state of a Kubernetes cluster is stored in version control and is the only source of truth that drives changes to the cluster. This makes rollbacks trivial—all you need to do to roll back a Kubernetes application is a Git revert operation.

There are several advantages to rolling back using Git revert:

• Because Git has strong security controls, you can use an SSH key to prove that both commits and revert operations were authorized by the appropriate members of the team.
• Users can make changes to cluster state without requiring credentials to cluster administration. This creates a complete separation between the development of declarative configuration and the actual management of the cluster.
• Software agents make the application self-healing, not just in the sense that a failed pod is restarted, but in the sense of recovering from configuration errors, human errors, and a wide range of other conditions.

Related content: Read our guide to fatal: not a git repository

Troubleshooting Kubernetes Application Rollback with Komodor

Git revert indicates that something was wrong with a Kubernetes application and it was rolled back. However, discovering what was wrong, and the possible chain reactions caused by a Git revert, can be stressful, ineffective and time-consuming. Some best practices can help minimize the chances of things breaking down, but eventually something will go wrong—simply because it can.

This is the reason why we created Komodor, a tool that helps dev and ops teams stop wasting their precious time looking for needles in (hay)stacks every time things go wrong.

Acting as a single source of truth (SSOT) for all of your k8s troubleshooting needs, Komodor offers:

• Change intelligence: Every issue is a result of a change. Within seconds we can help you understand exactly who did what and when.
• In-depth visibility: A complete activity timeline, showing all code and config changes, deployments, alerts, code diffs, pod logs and etc. All within one pane of glass with easy drill-down options.
• Insights into service dependencies: An easy way to understand cross-service changes and visualize their ripple effects across your entire system.
• Seamless notifications: Direct integration with your existing communication channels (e.g., Slack) so you’ll have all the information you need, when you need it.

If you are interested in checking out Komodor, use this link to sign up for a Free Trial.