Deploying Without a Commit: A Practical Guide to Using Git Revert Safely
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:
- Build and deploy from this branch
Your deployment now contains everything onmain
, except the effect of the reverted commit. - 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 interactivegit 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
- 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 frommain
. - 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. - 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.
Comments ()