Fundamentals 10 min read

Four Ways to Roll Back Code in Git: Revert, Reset, Rebase + Revert, and File Operations

After encountering a problematic jar introduced in version A, the author explores four Git-based rollback strategies—simple revert, hard reset with forced push, combining interactive rebase with a revert commit, and a file‑level copy‑checkout method—detailing their commands, pitfalls, and suitability for different scenarios.

Top Architect
Top Architect
Top Architect
Four Ways to Roll Back Code in Git: Revert, Reset, Rebase + Revert, and File Operations

The author describes a real‑world scenario where a performance‑critical jar introduced in version A caused issues, and subsequent releases (B, C) built on that version made a direct fix impossible without rolling back.

Revert

Initially the git revert <commit_id> command was considered, which creates a new commit that undoes the changes of the specified commit. However, the commit history was long and included many merge commits, making a series of manual revert operations error‑prone.

Reset

Using git reset --hard <commit_id> moves the HEAD pointer to an earlier commit, discarding later commits. The author attempted a hard reset on the master branch followed by a forced push:

master> git reset --hard commit_id
master> git push --force origin master

This approach failed because the master branch was protected in GitLab, and force‑pushing is risky in a team environment.

Rebase + Revert

The author then tried an interactive rebase to squash multiple commits into one, then revert that single commit. The workflow is:

Create a new branch F and identify the target commit N .

Run git rebase -i N to open the interactive editor, which shows commits like:

pick 6fa5869 commit1
pick 0b84ee7 commit2
pick 986c6c8 commit3
pick 91a0dcc commit4

Change the first pick to keep the oldest commit and replace subsequent pick with squash to merge them into a single commit.

After saving, edit the commit message, creating a new combined commit (e.g., commit5 ).

Merge the updated master into branch F to keep history consistent.

Finally, revert the combined commit on F to roll back all changes at once.

This method preserves history while achieving a clean rollback, though it is complex and should not be used on heavily collaborative branches.

File‑Level Operation

The simplest approach involved copying the project files:

Create a branch F identical to master .

Copy the repository folder to a temporary bak directory.

In bak , checkout the target commit N ( git checkout N ) to restore the files to that state.

Copy all files (except the .git directory) back into the original working directory.

Stage and commit the changes, completing the rollback without altering the commit graph.

This technique leverages Git's file‑level change detection and avoids complex history rewrites.

Conclusion

The author summarizes the four rollback methods, recommending revert for simple cases, reset --hard + force‑push when branch protection is not an issue, rebase + revert for a formal, history‑preserving solution, and the file‑operation method for the quickest, least elegant fix.

gitrebaseversion controlResetrevertcode-rollback
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.