3758

gitリベースを簡単に元に戻す方法を知っている人はいますか？

頭に浮かぶ唯一の方法は、手動でそれを行うことです。

  • git checkoutは、両方のブランチの親をコミットします
  • 次に、そこから一時ブランチを作成します
  • チェリーピックすべてのコミットを手作業で
  • リベースしたブランチを手動で作成したブランチに置き換えます

私の現在の状況では、両方のブランチからのコミットを簡単に見つけることができるので、これはうまくいくでしょう（1つは私のもので、もう1つは私の同僚のものでした）。

しかし、私のアプローチは、最適ではなく、エラーが発生しやすいと思います（たとえば、自分のブランチを2つ使用してリベースしたとしましょう）。

何か案は？

明確化：私は、コミットの束が再生されたリベースについて話している。1つだけではありません。

4

19 に答える 19

5164

最も簡単な方法は、 reflogでリベースが開始される直前のブランチのヘッド コミットを見つけることです ...

git reflog

現在のブランチをそれにリセットします（オプションでリセットする前に絶対に確実であることについての通常の警告があり--hardます）。

古いコミットがHEAD@{2}ref ログにあったとします。

git reset --hard HEAD@{2}

Windows では、参照を引用する必要がある場合があります。

git reset --hard "HEAD@{2}"

git log HEAD@{2}( Windows: )を実行するだけで、候補の古い頭の履歴を確認できますgit log "HEAD@{2}"。

git reflog branchname@{1}ブランチごとの reflog を無効にしていない場合は、最終的なヘッドに再アタッチする前に、リベースがブランチ ヘッドをデタッチするので、簡単に実行できるはずです。最近確認していないので、再確認します。

デフォルトでは、裸でないリポジトリに対してすべての reflog がアクティブ化されます。

[core]
    logAllRefUpdates = true
于 2008-09-25T19:56:28.343 に答える
1741

実際、リベースは開始点を保存するORIG_HEADため、通常は次のように簡単です。

git reset --hard ORIG_HEAD

ただし、reset、rebaseおよびすべては元のポインターをmerge保存するため、元に戻そうとしているリベース以降にこれらのコマンドのいずれかを実行した場合は、reflog を使用する必要があります。HEADORIG_HEAD

于 2009-03-28T13:24:50.743 に答える
450

チャールズの答えはうまくいきますが、これをしたいかもしれません：

git rebase --abort

の後にクリーンアップしresetます。

そうしないと、「<code>Interactive rebase already started」というメッセージが表示される場合があります。

于 2009-07-27T18:21:54.227 に答える
107

もちろん、ブランチを古いヒントのダングリング コミット オブジェクトにリセットするのが最善の解決策です。しかし、これらのコミットを失った場合 (たとえば、その間にリポジトリをガベージ コレクションしたか、これが新しいクローンであるなど)、いつでもブランチを再度リベースできます。これの鍵は--ontoスイッチです。

想像上 と呼ばれるトピック ブランチがあり、 の先端がコミットされたときに分岐しtopicたとします。ブランチにいる間のある時点で、あなたは. ここで、これを元に戻したいと考えています。方法は次のとおりです。mastermaster0deadbeeftopicgit rebase master

git rebase --onto 0deadbeef master topic

topicこれは、オンになっていないすべてのコミットを取得しmaster、上でそれらをリプレイします0deadbeef。

を使用すると、履歴をほとんど任意の形--ontoに再配置できます。

楽しむ。:-)

于 2008-09-26T02:08:44.970 に答える
95

ブランチをリモート リポジトリ(通常はオリジン) にプッシュし、(マージなしで) リベースに成功した場合 ( 「リベースが進行中でありません」と表示されます)、次のコマンドを使用してブランチgit rebase --abortを簡単にリセットできます。

git reset --hard origin/{branchName}

例：

$ ~/work/projects/{ProjectName} $ git status
On branch {branchName}
Your branch is ahead of 'origin/{branchName}' by 135 commits.
  (use "git push" to publish your local commits)

nothing to commit, working directory clean

$ ~/work/projects/{ProjectName} $ git reset --hard origin/{branchName}
HEAD is now at 6df5719 "Commit message".

$ ~/work/projects/{ProjectName} $ git status
On branch {branchName}
Your branch is up-to-date with 'origin/{branchName}.

nothing to commit, working directory clean
于 2015-09-28T12:43:48.797 に答える
75

重要な操作を行う前に、実際にブランチにバックアップ タグを付けます (ほとんどのリベースは簡単ですが、複雑に見える場合はそうします)。

その後、復元は簡単git reset --hard BACKUPです。

于 2009-05-12T20:57:24.453 に答える
48 
git reset --hard origin/{branchName}

リベースによって行われたすべてのローカル変更をリセットする正しいソリューションです。

于 2019-05-06T08:04:45.020 に答える
29

使用reflogしてもうまくいきませんでした。

私にとってうまくいったのは、ここで説明したのと似ていました。リベースされたブランチにちなんで名付けられた .git/logs/refs のファイルを開き、次のような「rebase finsihed」を含む行を見つけます。

5fce6b51 88552c8f Kris Leech <me@example.com> 1329744625 +0000  rebase finished: refs/heads/integrate onto 9e460878

行にリストされている 2 番目のコミットをチェックアウトします。

git checkout 88552c8f

これに失われた変更が含まれていることを確認したら、分岐して安堵のため息をつきました。

git log
git checkout -b lost_changes
于 2012-02-20T13:59:06.350 に答える
16

複数のコミットの場合、コミットはそのコミットに至るまでのすべての履歴を参照することに注意してください。したがって、チャールズの回答では、「古いコミット」を「古いコミットの最新」と読んでください。そのコミットにリセットすると、そのコミットまでのすべての履歴が再び表示されます。これはあなたが望むことをするはずです。

于 2008-09-25T21:36:50.693 に答える
14

リモート ブランチに対してリベースに成功し、それができないgit rebase --abort場合でも、いくつかのトリックを実行して作業を保存し、プッシュを強制しないようにすることができます。誤ってリベースされた現在のブランチが呼び出されyour-branch、追跡しているとしますorigin/your-branch

  • git branch -m your-branch-rebased# 現在のブランチの名前を変更
  • git checkout origin/your-branch# オリジンが知っている最新の状態にチェックアウト
  • git checkout -b your-branch
  • から欠落しているコミットをチェックgit log your-branch-rebased、比較git log your-branch、および定義するyour-branch
  • git cherry-pick COMMIT_HASHのコミットごとにyour-branch-rebased
  • 変更をプッシュします。2 つのローカル ブランチが関連付けられているremote/your-branchため、プッシュのみを行う必要があることに注意してください。your-branch
于 2016-06-23T09:23:45.167 に答える
11

@Allan と @Zearin の解決策に従って、単純にコメントできたらいいのにと思いますが、評判が十分ではないため、次のコマンドを使用しました。

実行する代わりに( -igit rebase -i --abortに 注意してください)、単純に( -iなしで) 実行する必要がありました。git rebase --abort

と の両方-iを--abort同時に使用すると、Git は使用法/オプションのリストを表示します。

したがって、このソリューションの以前と現在のブランチのステータスは次のとおりです。

matbhz@myPc /my/project/environment (branch-123|REBASE-i)
$ git rebase --abort

matbhz@myPc /my/project/environment (branch-123)
$
于 2015-03-11T21:26:47.550 に答える
-5

git rebase --abortコミットされていないファイルがある場合など、git rebase 内で何かを台無しにすると、それらは失われ、git reflog役に立ちません。これは私に起こったことであり、ここで既成概念にとらわれずに考える必要があります。私のように幸運で、IntelliJ Webstorm を使用right-click->local historyしている場合は、バージョン管理ソフトウェアでどんな間違いを犯したとしても、ファイル/フォルダーを以前の状態に戻すことができます。別のフェイルセーフを実行することは常に良いことです。

于 2016-03-09T09:19:08.793 に答える