Should I use git revert or git reset after pushing a commit?

Use git revert for commits that are already pushed to a shared branch. Revert creates a new commit that undoes the changes without rewriting history. git reset rewrites history and should only be used for local, unshared commits (or with explicit coordination and a force push).

Does git cherry-pick change the commit hash?

Yes. git cherry-pick replays the changes as a new commit on the target branch, so the new commit has a different hash (because it has a different parent). The code change is the same, but the commit identity is different.

Can I undo a git cherry-pick?

If the cherry-pick is still in progress, use git cherry-pick --abort. If it already created a commit, undo it by reverting that new commit (git revert ). Avoid resetting if the commit has been pushed.

How do I revert a merge commit?

Use git revert -m 1 . The -m flag chooses the mainline parent so Git knows which side of the merge to keep. Test the result because reverting merges can conflict or reintroduce changes unexpectedly.

Git Cherry-Pick vs Revert: Which Should You Use? (With Examples)

Published February 15, 2026 · 12 min read

git cherry-pick and git revert both create new commits, so they feel similar at first. But they solve completely different problems:

Cherry-pick is for copying a commit onto another branch (backports, hotfixes, selective changes).
Revert is for undoing a commit safely on a shared branch (without rewriting history).

⚙ Quick links: Revert a Merge Commit Guide · Git Cherry-Pick Complete Guide · Git Undo (Reset vs Revert) · Git Commands Cheat Sheet

Quick decision: cherry-pick vs revert (and when to use reset)
What git cherry-pick does (and why hashes change)
What git revert does (and why it’s safe to push)
Comparison table
Copy-paste workflows
Pitfalls & best practices
FAQ

1. Quick decision: cherry-pick vs revert (and when to use reset)

Use this table when you’re in the “what now?” moment.

Goal	Use	Why
Copy a fix from `main` to `release`	`git cherry-pick`	Replays a specific commit on another branch (backport).
Apply one commit from a feature branch (not the whole branch)	`git cherry-pick`	Selectively moves a change without merging everything.
Undo a bad commit that was already pushed	`git revert`	Creates an “anti-commit” and does not rewrite history.
Undo a merge commit (revert a PR)	`git revert -m 1`	Reverts the merge while keeping the mainline history.
Undo a local, unpushed commit	`git reset`	Rewrites local history; unsafe once pushed.

Rule of thumb: If other people (or CI) might have already pulled the commit, prefer git revert over git reset. Revert is “safe but verbose”; reset is “clean but dangerous.”

2. What git cherry-pick does (and why hashes change)

git cherry-pick takes the diff introduced by a commit and applies it on top of your current branch, creating a new commit.

# On the target branch:
git switch release/1.4

# Copy a single commit from main (creates a new commit on release/1.4)
git cherry-pick -x 1a2b3c4

The new commit has a different SHA because its parent commit is different. That’s normal and expected.

Tip: Use -x in team repos. It adds a line to the commit message pointing to the original commit, which makes audits and future debugging much easier.

If a cherry-pick hits conflicts, Git pauses and gives you three core commands:

# Resolve conflicts, then:
git add -A

# Continue / abort / skip
git cherry-pick --continue
git cherry-pick --abort
git cherry-pick --skip

If you want the full set of options (ranges, merge commits, --no-commit, etc.), see the complete cherry-pick guide.

3. What git revert does (and why it’s safe to push)

git revert creates a new commit that undoes the changes introduced by an earlier commit.

# Undo a specific commit (safe on shared branches)
git revert 1a2b3c4

# Push the revert like a normal commit
git push origin main

Unlike git reset, revert does not rewrite history. You can safely revert on main even after other people pulled the bad commit.

Reverting a merge commit needs extra care: use git revert -m 1 <merge_sha> (see workflow below). If you choose the wrong mainline, you can accidentally undo the wrong side of the merge.

4. Comparison table

Topic	`git cherry-pick`	`git revert`
Intent	Copy changes to another branch	Undo changes from an existing commit
History	Adds a new commit (duplicate changes, new SHA)	Adds a new commit (inverse diff, new SHA)
Safe on shared branches?	Usually yes (but can create duplicated history)	Yes (designed for shared branches)
Common use	Backport hotfixes, move one commit between branches	Undo a bad deploy / revert a PR / back out a change
Main risk	Lots of cherry-picks can make future merges confusing	Reverting merges can be tricky; conflicts can happen

5. Copy-paste workflows

Backport a fix from main to a release branch (cherry-pick)

This is the most common real-world cherry-pick use case.

# Make sure your refs are up to date
git fetch origin

# Start from the release branch
git switch release/1.4
git pull --ff-only

# Identify the fix commit on main
git log --oneline origin/main -20

# Apply it (use -x for traceability)
git cherry-pick -x 1a2b3c4

# Push release branch
git push origin release/1.4

Before shipping, review what you actually applied:

# Compare before/after
git show --stat

# Or diff against the release branch upstream
git diff origin/release/1.4...HEAD

Helpful references: git log guide and git diff guide.

Undo a bad commit on main (revert)

If the commit is already pushed, revert is the “don’t break your team” option.

# Find the bad commit
git log --oneline -20

# Create a revert commit
git revert 1a2b3c4

# Push normally
git push origin main

If you need a deeper undo playbook, see: Git Undo: Reset vs Revert.

Undo a cherry-pick

If the cherry-pick is still running (you’re in a conflict state), abort it:

git cherry-pick --abort

If the cherry-pick already created a commit, undo it with revert (safe even if pushed):

# Revert the new cherry-picked commit SHA
git revert <new_commit_sha>

Revert a merge commit (revert a PR)

To revert a merge, you must pick a mainline parent. In most repos, parent 1 is the branch you merged into (for example main).

# Revert a merge commit and keep the mainline (parent 1)
git revert -m 1 <merge_commit_sha>

Then push and let CI validate the result. For a deeper conflict playbook, see Git Merge Conflicts Guide.

Revert a revert (re-apply a change)

Sometimes you revert a feature to stabilize production, then later decide to bring it back. Instead of cherry-picking the original commit(s), you can often revert the revert:

# Re-apply the changes by reverting the revert commit
git revert <revert_commit_sha>

This keeps history explicit and makes it obvious what happened when someone audits the timeline.

6. Pitfalls & best practices

Don’t cherry-pick entire feature branches: if you need dozens of commits, prefer merge/rebase to preserve history.
Cherry-picks can confuse future merges: duplicated commits may show up as “already applied” or cause conflicts. Keep cherry-picks small and traceable (-x).
Reverts are reversible: reverting does not destroy history, and you can revert a revert to reintroduce the change.
Always inspect the commit before acting: use git show and git diff to confirm what will be undone/copied.
Prefer safety on shared branches: if it’s pushed, revert first; if it’s local, reset can be fine.

FAQ

Is git cherry-pick safe on main?

It can be safe, but it depends on your workflow. Cherry-pick does not rewrite history, but it creates duplicate commits (new SHAs). That duplication can make later merges more complex. For hotfixes and backports, cherry-pick is common; for full features, merging is usually cleaner.

Can I revert a cherry-picked commit?

Yes. Revert the new commit created by the cherry-pick (the commit on your current branch). If it was pushed, revert is the safe choice. If it was not pushed and you want a clean history, you can also reset.

Should I use revert or reset to undo a pushed commit?

Use git revert. Reset requires a force push and can break teammates’ clones and open pull requests. Revert is designed for shared branches.

Where do I find the right commit SHA?

Use git log --oneline to browse commits, git log -p to inspect diffs, and git show <sha> to confirm the exact changes. Our git log guide has practical recipes for finding commits by author, file, message, and date.