Move recent Git commits to a new branch

Create a new branch at the current tip before moving the original branch back. A branch is a ref to a commit, so creating the new ref preserves the commits even after the old branch points elsewhere.

Move two unpublished commits from main

This example assumes you are on main, the two commits are its latest linear commits, and you have saved all uncommitted work:

git switch main
git status --short
git log --oneline -5
git branch feature/login
git reset --hard HEAD~2
git switch feature/login

Inspect the status and log before running the reset. HEAD~2 follows the first-parent chain twice; in a history with merges, counting visible log lines is not a reliable way to choose the boundary. Use a reviewed commit ID if the graph is more complicated.

The new branch retains the original commit IDs. main no longer reaches those commits through its tip, although other refs may still reach them.

Preserve uncommitted changes

reset --hard replaces the index and tracked working-tree content and can remove untracked paths that obstruct writing tracked paths. Save work first, including untracked files when necessary. git reset --keep TARGET rejects certain overwriting changes and can be useful, but it is not a substitute for checking what you need to preserve.

If main has already been shared

Keep the feature ref, then use a corrective revert on shared main rather than rewriting its history. Test the reversal and publish it through the team's review process.

The original commits remain ancestors of main after a revert. Later merging the old feature ref alone will not restore the reverted work. Reintroduce it with a reviewed revert of the revert or with new corrective changes based on the current mainline.

An agreed rewrite of a personal remote branch may use --force-with-lease. A lease cannot establish that nobody has based unpublished work on the old commits, so check collaboration policy separately.

Move changes to an existing branch

Switch to the intended destination and cherry-pick the selected commits in dependency order. Inspect and test the result before changing the original branch. Cherry-pick normally creates new commit IDs; if the source branch is shared, remove the unwanted effect with revert rather than a forced reset.

Recover from a wrong boundary

Use git reflog to locate the former tip and create a recovery branch there before doing more destructive work. A reflog is a local recovery aid with finite retention, not permanent storage. Keeping the feature or backup ref is the more dependable way to preserve the commits while you reorganize them.

See git-branch, git-reset, and git-revert.