Replaying a change creates new history objects

First, build a mental model

Rebase replays a line of work onto another base. Cherry-pick applies a selected commit's change to the current line. The new commits can carry similar patches while having different identities and dependency context.

1. A commit's identity includes its tree, parents and metadata. Changing the parent context normally creates a new commit ID.
2. Rebase is useful for an intentionally controlled development branch; shared history requires coordination because other people may depend on the original IDs.
3. Cherry-pick selects a change rather than merging the whole branch, but the selected change may depend on earlier work.
4. Conflicts must be resolved in the context of the operation; rebase --continue and cherry-pick --continue resume different workflows.
5. A force-with-lease check is not permission to rewrite shared history. Respect protected branches, collaboration agreements and explicit publication authority.

# On a disposable or deliberately controlled unpublished feature branch:
git status
git switch feature/labels
git rebase main
# Inspect any replayed result and run relevant checks.

# A separate alternative for one reviewed, self-contained change:
# git switch target-branch
# git cherry-pick REVIEWED_COMMIT
# REVIEWED_COMMIT is a placeholder, not a supplied real commit ID.

1. Original context

   The feature commits were created relative to their old parents.

2. Replay

   Rebase applies their changes after the selected new base.

3. New candidate

   The resulting commits have new identities and need integration verification in the new context.