Komodor is a Kubernetes management platform that empowers everyone from Platform engineers to Developers to stop firefighting, simplify operations and proactively improve the health of their workloads and infrastructure.
Proactively detect & remediate issues in your clusters & workloads.
Easily operate & manage K8s clusters at scale.
Reduce costs without compromising on performance.
Empower developers with self-service K8s troubleshooting.
Simplify and accelerate K8s migration for everyone.
Fix things fast with AI-powered root cause analysis.
Explore our K8s guides, e-books and webinars.
Learn about K8s trends & best practices from our experts.
Listen to K8s adoption stories from seasoned industry veterans.
The missing UI for Helm – a simplified way of working with Helm.
Visualize Crossplane resources and speed up troubleshooting.
Validate, clean & secure your K8s YAMLs.
Navigate the community-driven K8s ecosystem map.
Kubernetes 101: A comprehensive guide
Expert tips for debugging Kubernetes
Tools and best practices
Kubernetes monitoring best practices
Understand Kubernetes & Container exit codes in simple terms
Exploring the building blocks of Kubernetes
Cost factors, challenges and solutions
Kubectl commands at your fingertips
Understanding K8s versions & getting the latest version
Rancher overview, tutorial and alternatives
Kubernetes management tools: Lens vs alternatives
Troubleshooting and fixing 5xx server errors
Solving common Git errors and issues
Who we are, and our promise for the future of K8s.
Have a question for us? Write us.
Come aboard the K8s ship – we’re hiring!
Hear’s what they’re saying about Komodor in the news.
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.
git revert
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.
Let’s examine the difference between three related Git commands: revert, checkout, and reset.
revert
checkout
reset
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 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.
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.
Itiel Shwartz
Co-Founder & CTO
In my experience, here are tips that can help you better handle Git revert in GitOps and Kubernetes:
Tagging releases ensures you can easily revert to specific versions.
Integrate rollback procedures into your CI/CD pipelines for seamless reverts.
Keep detailed commit messages and documentation for easier reversion.
Gradually deploy changes to minimize the impact of potential rollbacks.
Feature flags allow you to toggle features on and off without code changes.
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:
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:
Related content: Read our guide to fatal: not a git repository
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:
If you are interested in checking out Komodor, use this link to sign up for a Free Trial.
Share:
How useful was this post?
Click on a star to rate it!
Average rating 5 / 5. Vote count: 9
No votes so far! Be the first to rate this post.
and start using Komodor in seconds!