Rollback in Development: What It Is, Methods and How It Works

What Is Rollback in Development

Rollback is an operation that returns a system to a previous stable state. In the context of development, this can mean undoing a commit in Git, rolling back a database transaction, or reverting to a previous version of an application on the server. The term comes from English “rollback” and is firmly established in the vocabulary of developers across all platforms.

The need for a rollback arises when a new change breaks functionality, causes errors, or fails quality checks. In a well-organized development process, a rollback is not a sign of failure but a standard procedure built into the workflow. The faster a team can roll back a problematic change, the lower the impact of the bug on users.

Different tools offer different rollback mechanisms: Git provides a choice between safe revert and destructive reset, databases support transactional rollback, and CI/CD systems can switch traffic between versions. The choice of approach depends on the context and requirements for preserving change history.

Git Revert vs Git Reset: What’s the Difference

Git revert is a safe rollback method that creates a new commit undoing previous changes. The history remains linear, and all old commits are preserved. This is the only correct choice for reverting in a shared branch that multiple developers work on. Git revert does not delete history — it adds the fact of rollback as a new change.

Git reset moves the current branch pointer to a specified commit, discarding all subsequent changes. Depending on the flag — soft, mixed, or hard — reset handles the working directory and index differently. Hard mode completely removes changes from history, making it dangerous for shared branches and suitable only for local work.

When to Use Revert

Revert is used in shared branches: main, develop, release. It preserves history and allows other developers to understand that a change was undone. After revert, you can safely run git pull — the system will not produce conflicts related to rewritten history. In team work, revert is the default standard.

# Undo last commit by creating a new commit
git revert HEAD

# Undo a specific commit by hash
git revert a1b2c3d

When to Use Reset

Reset is appropriate in a local branch where you have not yet published changes. If you were experimenting and want to completely clean the history — reset hard will do it. In a local branch, you can use reset mixed to undo commits but keep changes in the working directory for re-committing.

# Undo last commit, keep changes in working directory
git reset HEAD~1

# Full undo — changes are permanently removed
git reset --hard HEAD~2

Rollback in Databases: Transactions and ACID

Transaction rollback is an operation that undoes all changes made within the current transaction and returns the database to the state at the start of the transaction. This guarantees atomicity — one of the four ACID principles (Atomicity, Consistency, Isolation, Durability). If an error occurs at any stage of the transaction, a rollback is executed and the data returns to its original state.

The rollback mechanism is implemented through the Write-Ahead Log (WAL). Before modifying a data page, the DBMS writes the old and new values to the log. During rollback, the system reads the log and restores the original values for all modified pages. This ensures that even in the event of a power failure, the transaction can be correctly undone.

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint: Partial Rollback

In long transactions, it is convenient to use savepoints — intermediate save points to which you can roll back without completing the entire transaction. This allows you to handle errors within a complex operation without losing progress on other parts. Savepoints are supported by most relational DBMS: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

Rollback in Deployment: Strategies and Tools

Deployment rollback is reverting a running application to a previous version after an unsuccessful deployment. This is a critical capability for production environments: recovery time (MTTR) directly affects SLA and user experience. Modern platforms offer several rollback strategies depending on architecture and availability requirements.

Blue-Green Deployment

Blue-green is a strategy where two identical environments run simultaneously: blue (current version) and green (new version). Traffic switches to green after a successful deployment. If the new version works incorrectly, the traffic switch returns to blue. Rollback is performed instantly, without re-deployment — just change the routing.

Canary Release with Automatic Rollback

Canary deployment directs a small portion of traffic to the new version and monitors metrics: error rate, response time, percentage of successful requests. If metrics deteriorate, the system automatically rolls back the canary and directs all traffic to the stable version. Kubernetes and service meshes (Istio, Linkerd) support this strategy out of the box.

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Practical Rollback Examples in Development

Let’s examine three typical scenarios where a developer needs to roll back changes. Each scenario requires its own approach — from a simple terminal command to a multi-step procedure involving CI/CD.

Scenario 1: Accidental Commit to Main

You accidentally pushed a commit with a bug to main. Your task is to roll back the changes without losing history for the team. Use git revert to create a reverting commit and then git push. All team members will see the rollback and can continue working without conflicts. This is the safest and most transparent method.

git checkout main
git pull origin main
git revert HEAD
git push origin main

Scenario 2: Failed Database Migration

A database migration failed, and some data is corrupted. Use transactional rollback in the migration script and restore from backup for already applied changes. In a well-designed system, each migration is wrapped in a transaction — on error, the DBMS automatically performs a rollback.

Scenario 3: Deployment with Critical Bug

After deploying a new version, you discover that authorization is not working. If you use blue-green, rollback is switching the router back. If rolling update — the kubectl rollout undo command will return the previous version. Ideally, the rollback process should be automated and take no more than a minute.