History is a graph of immutable commit objects and movable references. Rebase and cherry-pick create new commits by applying changes in a new context. They are useful for preparing an unpublished topic for review or transferring a narrowly scoped fix. They do not move an existing commit object to a different parent without changing its identity.
Merge versus replay
Merging divergent main into a topic preserves both original histories and normally adds a merge commit. Rebasing the topic onto main reconstructs its selected changes with main as the new base. Parent information is part of a commit object, so even equivalent file changes normally produce different commit IDs after replay. Keep a reference to the previous tip when you need an easy comparison or recovery point.
git log --all --graph --decorate --oneline
git rebase main
git cherry-pick fix-patch
git log --all --graph --decorate --onelineThis lab deliberately uses an unpublished feature, avoiding an uncoordinated rewrite of shared history. In normal team work, first ask who depends on the old commits and what review policy expects. Rebasing a branch that others have based work on creates a coordination problem even when the new tree is correct.
Copy only the intended change
Cherry-pick applies a selected commit's change to the current branch and records a new commit. It does not mean "merge that entire source branch." The picked commit may depend on earlier changes, so inspect the patch and tests. A fix that compiles on its original branch may rely on an API not present in the destination. Copying the change can also mean future merges must recognize equivalent changes with different identities.
If replay pauses, resolve the files, stage the resolution and use git rebase --continue or git cherry-pick --continue for the active operation. The corresponding --abort cancels that operation. Skipping a replayed commit deliberately drops its patch from this series; it is not the general solution for a difficult conflict. During rebase, ours is the new upstream plus commits already replayed, while theirs is the commit being replayed.
Review the resulting series
Interactive rebase outside these noninteractive labs can reword, reorder, combine or remove commits. git commit --amend replaces the current commit with a new one, even when you intend only a message correction. Treat both as rewriting. In a review, verify the final diff and the per-commit explanation; a neat graph does not establish correctness.
The task checks both content and ancestry: main must be an ancestor of the feature, only two topic commits may remain, and the original fix commit must not itself become an ancestor through a merge. Run sample lets you inspect that structure before submitting. Fixed fixtures also vary contents so that hard-coding a file value cannot substitute for replaying the intended change.