Git cherry-pick: how to move a commit to another branch without copying everything

Published on 2026-10-26 by frfrand

Move a specific fix between branches with Git cherry-pick

Git cherry-pick: how to move a commit to another branch without copying everything

You fixed a bug on a branch, but you also need it in production and you don't want to bring all the changes from that branch. That's where git cherry-pick comes in: it takes the effect of one or more commits and applies it to the current branch.

The idea is to use it to solve a real problem, not to memorize commands because they look good in a screenshot. Let's go with the essentials, a work example, and the mistakes you should avoid.

What Git cherry-pick does and when it's useful

It doesn't literally move the original commit object to the other branch: normally it creates a new commit with a different hash and equivalent changes. That's why it's useful for backports, not to replace an orderly merge strategy.

If you're learning, try it first in a test repository or environment. If you manage production, document the state before executing anything that alters files, history, or data. That allows you to understand what changed and recover if you make a mistake.

Example to copy and understand

git log --oneline -5
git switch main
git cherry-pick -x abc1234
# Si hay conflictos: resolver archivos, luego
git add .
git cherry-pick --continue
# Para abandonar la operación
git cherry-pick --abort

Don't copy the final command without checking the previous state. Branch names, host, user, or paths are examples; replace them with those from your project. Some commands modify files or make requests that can write data.

How I would use it step by step

  1. Step 1. Find the fix hash with git log --oneline.
  2. Step 2. Confirm you are on the target branch, ideally with passing tests.
  3. Step 3. Run git cherry-pick -x HASH if you want to record the origin in the message.
  4. Step 4. If there are conflicts, fix them, review the diff, and continue; do not accept both versions blindly.
  5. Step 5. Run tests and deploy only after verifying the behavior.

Stop after each step and check the result. If something fails, note the exact message before changing strategy. Jumping between five random solutions usually makes it harder to find the real cause.

A case that could happen to you working with clients

The desarrollo branch includes a panel redesign, but you fixed a reservation validation error. Instead of merging the incomplete redesign, you apply only the validation commit to the stable branch.

The goal is not for it to "work once," but for you to be able to explain how you repeat it without compromising another application. If there are client data or credentials, work with separate tests and minimal access.

The most common mistake I see

If the commit depends on other changes that do not exist in the target, cherry-pick may fail or compile with incorrect behavior. Always test dependencies and do not use it to copy dozens of related commits without reviewing them.

A simple rule: if you can't explain what the command will do to your code or server, check its official help first. This way you avoid confusing a quick fix with a new problem.

Where does ArduMaker come in?

When deploying from Git with ArduMaker, you can identify which commit is published. This makes it easier to fix an incident with a cherry-pick and keep production review separate from incomplete development.

For example, you can deploy from a Git repository to a VPS, associate an HTTPS domain, and manage services and databases from the same environment. The panel reduces repetitive infrastructure tasks, but does not replace Git, testing, or project permission review.

Quick questions before applying it

Does this change production? It depends on where you run the action. Test locally first, identify the affected commit or service, and prepare a recovery plan.

How do I check that it went well? Don't settle for the absence of error messages: check the status, run a functional test, and check the corresponding logs or history.

Is it worth automating it? If it is repeatable and has verifiable results, yes. But automation should fail clearly and not hide errors or credentials.

To expand

Summary: the useful tool is not the one with the most options, but the one that lets you understand what changed, verify it, and keep working without surprises.

  • Git
  • Tutorial
  • ArduMaker

Keep reading

All articles · VPS plans