以前のほとんどの答えは危険なほど間違っています！
こんなことしないで：
git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch
次回git rebase（またはgit pull --rebase）を実行すると、これらの3つのコミットはnewbranch！（以下の説明を参照）
代わりにこれを行います：
git reset --keep HEAD~3
git checkout -t -b newbranch
git cherry-pick ..HEAD@{2}
- 最初に、最新の3つのコミットを破棄します（
--keepに似--hardていますが、コミットされていない変更を破棄するよりも失敗するため、より安全です）。
- その後、分岐し
newbranchます。
- 次に、これらの3つのコミットをに戻します
newbranch。彼らはもはや、分岐によって参照しているので、それはそれはgitの使用しないREFLOGを：HEAD@{2}それはコミットされたHEAD2つの操作前に参照するために使用される、すなわち前に我々 1.チェックアウトしないnewbranchと2を使用git reset3つのコミットを破棄します。
警告：reflogはデフォルトで有効になっていますが、手動で無効にした場合（「裸」のgitリポジトリを使用するなど）、実行後に3つのコミットを取得することはできませんgit reset --keep HEAD~3。
reflogに依存しない別の方法は次のとおりです。
# newbranch will omit the 3 most recent commits.
git checkout -b newbranch HEAD~3
git branch --set-upstream-to=oldbranch
# Cherry-picks the extra commits from oldbranch.
git cherry-pick ..oldbranch
# Discards the 3 most recent commits from oldbranch.
git branch --force oldbranch oldbranch~3
（必要に応じて@{-1}、以前にチェックアウトしたブランチ-の代わりに書き込むことができますoldbranch）。
技術説明
git rebase最初の例の後で3つのコミットを破棄するのはなぜですか？これgit rebaseは、引数を指定しないと--fork-pointデフォルトでオプションが有効になるためです。このオプションでは、ローカルreflogを使用して、強制的にプッシュされる上流ブランチに対してロバストになるように試みます。
コミットM1、M2、M3が含まれている場合にorigin / masterを分岐し、次に3つのコミットを自分で作成したとします。
M1--M2--M3 <-- origin/master
\
T1--T2--T3 <-- topic
しかし、誰かが起点/マスターを強制的にプッシュすることで履歴を書き換え、M2を削除します。
M1--M3' <-- origin/master
\
M2--M3--T1--T2--T3 <-- topic
ローカルのreflogを使用するgit rebaseと、origin / masterブランチの初期の化身から分岐したことがわかります。したがって、M2とM3のコミットは、実際にはトピックブランチの一部ではありません。したがって、M2は上流のブランチから削除されたため、トピックブランチがリベースされると、トピックブランチでM2が不要になると合理的に想定しています。
M1--M3' <-- origin/master
\
T1'--T2'--T3' <-- topic (rebased)
この動作は理にかなっており、通常、リベースするときに行うのが適切です。
したがって、次のコマンドが失敗する理由：
git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch
これは、reflogを間違った状態のままにするためです。Git newbranchは、3つのコミットを含むリビジョンでアップストリームブランチから分岐したと見なします。次に、reset --hardアップストリームの履歴を書き換えてコミットを削除します。次回実行するgit rebaseと、アップストリームから削除された他のコミットと同様に、コミットが破棄されます。
ただし、この特定のケースでは、これらの3つのコミットをトピックブランチの一部と見なす必要があります。そのためには、3つのコミットを含まない以前のリビジョンでアップストリームを分岐する必要があります。これが私の提案する解決策です。したがって、どちらもreflogを正しい状態のままにします。
詳細について--fork-pointは、git rebaseおよびgit merge-baseのドキュメントの定義をご覧ください。