Deploying Without a Commit: A Practical Guide to Using Git Revert Safely

Deploying Without a Commit: A Practical Guide to Using Git Revert Safely
Photo by Dongsh / Unsplash

In every development cycle, there are moments where you realize that one commit should not go into production yet. Maybe it introduces a half-finished feature, a bug, or something that needs business approval. The problem is, this commit is already merged into your main branch alongside other valuable changes.

How do you deploy everything except that one commit? The safest and most common answer is: use git revert.


What git revert Really Does

When you run:

git revert <commit-hash>

Git doesn’t remove the commit from history. Instead, it creates a new commit that applies the reverse diff of the targeted commit. The history stays intact, but the net effect on your codebase is as if that commit never happened.

Example:

A -- B -- C -- D   (main)

If you revert commit C, you get:

A -- B -- C -- D -- E

Where E is a new commit that undoes the changes from C.

This approach is different from git reset or git rebase, which rewrite history. git revert is non-destructive and safe for branches that are already shared with a team or remote repository.


Deploying Without a Commit

Let’s say you want to deploy the project without commit 9a2e6f69b8. Here’s a practical step-by-step workflow:

  1. Build and deploy from this branch
    Your deployment now contains everything on main, except the effect of the reverted commit.
  2. After deployment
    You have options:
    • If you later decide that you actually want the commit back, you can either:

Cherry-pick the original commit:

git cherry-pick 9a2e6f69b8

Revert the revert:

git revert <revert-commit-hash>

If you only needed this revert temporarily, just delete the branch:

git checkout main
git branch -D deploy-without-9a2e6f69b8

Your main remains untouched.

Revert the unwanted commit

git revert 9a2e6f69b8

This will create a new commit undoing the changes.

Create a new branch for deployment

git checkout main
git pull origin main
git checkout -b deploy-without-9a2e6f69b8

When to Use Git Revert vs. Other Methods

  • Use git revert when working on shared branches (main, develop) where history must remain untouched.
  • Use git reset or interactive git rebase only in local/private branches that no one else is using. These rewrite history and can cause problems if others already pulled the branch.

Additional Considerations

  1. CI/CD pipelines: If you have automated deployment pipelines, consider pushing the temporary branch (deploy-without-xyz) and pointing your pipeline at that branch. This prevents accidental deployment from main.
  2. Temporary vs. permanent exclusion: If the commit is permanently bad, revert it directly in main. If it’s only temporarily excluded, keep the revert isolated in a deployment branch.
  3. Testing after revert: Always rebuild and run tests locally after a revert. Sometimes, removing one commit can cause subtle issues if later commits depend on it.

Team communication: Make sure your teammates know why a commit was reverted. It’s often helpful to write a descriptive commit message like:

Revert “Add booking type selection and validation to WDWBookingForm” — excluded from release due to pending QA.

Merge commits: If the commit you want to skip is a merge commit, you need to specify which parent to keep. Example:

git revert -m 1 <merge-commit-hash>

-m 1 tells Git to keep the mainline parent branch.


Best Practice Workflow

  • Never deploy straight from main if you’re unsure.
  • Create a deployment branch, revert the unwanted commits, and deploy from there.
  • Keep main clean, so the whole team sees the full history as it happened.
  • Use cherry-pick or revert-revert later to restore any excluded changes.

Finally

git revert is one of those underrated commands that saves you from messy history rewrites. By understanding how it works and when to use it, you can confidently deploy without a specific commit while keeping your team’s workflow smooth and history transparent.

Key takeaway: Revert creates, reset destroys. If you want safety and traceability, always choose revert for shared branches.

Support Us

Share to Friends