Introduction

Moving changes from one Git commit to another is really about rewriting history in a controlled way. The right technique depends on whether the commits are local or already pushed and whether you want to move the whole commit, only part of it, or just copy the changes elsewhere.

Pick The Right Tool For The Situation

There is no single command for "move changes." In practice, you usually use one of these:

• 'git commit --amend when the target is the most recent commit'
• interactive rebase when the target is an older local commit
• 'git cherry-pick when you want to copy a commit to another branch'
• 'git reset plus selective staging when you need to split or relocate only part of a commit'

The safest rule is simple: if the history is already shared with other people, avoid rewriting it unless everyone agrees.

Move Changes Into The Most Recent Commit

If you just committed and realize some extra edits belong in that commit, stage them and amend:

git add src/app.py
git commit --amend

Git opens the previous commit message so you can keep it or edit it. This is the cleanest option when the destination is HEAD.

If you do not want to edit the message:

git add src/app.py
git commit --amend --no-edit

That updates the commit content while preserving the existing message.

Move Changes From One Older Commit To Another Local Commit

If the change is buried in an older local commit, interactive rebase is usually the best tool.

Suppose your last three commits look like this:

C3  fix docs
C2  add feature
C1  refactor helpers

Now imagine part of C2 actually belongs in C1. Start a rebase:

git rebase -i HEAD~3

Change the todo list so Git stops at the commit you want to edit:

pick <hash-of-c1> refactor helpers
edit <hash-of-c2> add feature
pick <hash-of-c3> fix docs

When Git stops on C2, uncommit it but keep the changes in your working tree:

git reset HEAD^

Now selectively stage only the changes that still belong in C2:

git add -p
git commit -m "add feature"

The remaining changes can then be staged into the earlier commit during the rebase flow or applied after another edit stop. This is the standard way to split and relocate changes while preserving a clean story.

Copy A Commit To Another Branch

Sometimes "move" really means "apply the same change elsewhere." In that case, cherry-pick is easier than history rewriting.

git switch release
git cherry-pick abc1234

That takes commit abc1234 from another branch and replays its patch on the current branch.

If you want the changes without committing immediately:

git cherry-pick --no-commit abc1234

That is useful when you want to combine the patch with other edits before creating the new commit.

Move Only Part Of A Commit

A common real-world problem is that one commit contains unrelated changes. The clean fix is:

1. uncommit the mixed commit
2. stage pieces interactively
3. recommit them in the right places

Example:

1git reset HEAD^
2git add -p
3git commit -m "feature change"
4git add -p
5git commit -m "test cleanup"

git add -p is the key tool here because it lets you stage individual hunks rather than entire files.

This works best before the commit has been pushed. Once others depend on the old commit hash, rewriting it becomes much more expensive.

What To Do If The Commits Are Already Pushed

If the commits are public, be careful. Rewriting them with rebase and force-push can disrupt teammates or CI systems.

In a shared branch, the safer strategy is often:

• create a correcting commit
• use git cherry-pick onto the right branch
• revert the incorrect commit if needed

For example:

git revert abc1234
git cherry-pick abc1234

That is not always the prettiest history, but it is much safer for shared collaboration.

Common Pitfalls

The biggest mistake is rewriting published history without checking whether anyone else has based work on it. A clean local history is not worth breaking other clones.

Another mistake is using git reset --hard when you only meant to uncommit while keeping the file changes. For this task, plain git reset HEAD^ or git reset --soft is usually what you want.

People also try to move changes file by file when the real split should happen hunk by hunk. git add -p is often the difference between a messy workaround and a clean fix.

Finally, do not confuse "move" with "copy." cherry-pick copies a patch. It does not remove the original commit unless you explicitly revert or rewrite it.

Summary

• Use git commit --amend when the destination is the most recent commit.
• Use interactive rebase for moving or splitting changes across older local commits.
• Use git cherry-pick when you want the same change on another branch.
• Use git add -p to move only part of a commit cleanly.
• Avoid rewriting already-pushed history unless you understand the impact and coordinate it.