2つのコミットを1つにマージしようとしているので、「リベースによるコミットの圧縮」git readyより。
私は走った
git rebase --interactive HEAD~2
結果のエディタで、pickに変更しsquashて保存して終了しましたが、リベースがエラーで失敗します。
以前のコミットなしでは「squash」できません
作業ツリーがこの状態に達したため、回復に問題が生じています。
コマンドはgit rebase --interactive HEAD~2次のように失敗します:
インタラクティブなリベースはすでに開始されています
そしてgit rebase --continue失敗する
以前のコミットなしでは「squash」できません
ベストアンサー1
まとめ
エラーメッセージ
以前のコミットなしでは「squash」できません
おそらく「下方への圧縮」を試みたことを意味しています。Gitは常に、新しいコミットを古いコミットに圧縮するか、対話型リベース ToDo リストで表示される「上方」、つまり前の行のコミットに圧縮します。ToDo リストの最初の行のコマンドを に変更すると、squash最初のコミットを圧縮する対象がないため、常にこのエラーが発生します。
解決策
まずは出発点に戻って
$ git rebase --abort
あなたの経歴は
$ git log --pretty=oneline
a931ac7c808e2471b22b5bd20f0cad046b1c5d0d c
b76d157d507e819d7511132bdb5a80dd421d854f b
df239176e1a2ffac927d8b496ea00d5488481db5 a
つまり、最初のコミットは a で、次に b、最後に c です。c をコミットした後、b と c を一緒に圧縮することにしました。
（注： を実行すると、git log出力がページャーにパイプされます。lessほとんどのプラットフォームではデフォルトで になります。ページャーを終了してコマンド プロンプトに戻るには、qキーを押します。
実行するgit rebase --interactive HEAD~2と、
pick b76d157 b
pick a931ac7 c
# Rebase df23917..a931ac7 onto df23917
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
(この ToDo リストは、 の出力と比較して逆の順序になっていることに注意してくださいgit log。)
bをpickに変更するとsquash、あなたが見たエラーが発生しますが、代わりに、todoリストを に変更してcをbに押し込む（新しいコミットを古いコミットに押し込む、つまり「上向きに押し込む」）と、
pick b76d157 b
squash a931ac7 c
エディタを保存して終了すると、内容が保存された別のエディタが表示されます。
# This is a combination of 2 commits.
# The first commit's message is:
b
# This is the 2nd commit message:
c
保存して終了すると、編集したファイルの内容が新しい結合コミットのコミット メッセージになります。
$ git log --pretty=oneline
18fd73d3ce748f2a58d1b566c03dd9dafe0b6b4f b and c
df239176e1a2ffac927d8b496ea00d5488481db5 a
歴史の書き換えに関する注意
対話型リベースは履歴を書き換えます。古い履歴を含むリモートにプッシュしようとすると、早送りではないため失敗します。
リベースしたブランチが、自分で作業しているトピック ブランチまたは機能ブランチである場合は、大きな問題はありません。別のリポジトリにプッシュするには--forceオプションが必要になります。または、リモート リポジトリの権限に応じて、最初に古いブランチを削除してから、リベースしたバージョンをプッシュすることもできます。作業を破壊する可能性のあるコマンドの例は、この回答の範囲外です。
パスワードやその他の機密情報を漏らすなどの正当な理由なく、他の人と共同作業しているブランチで既に公開されている履歴を書き換えることは、共同作業者に作業を強制することになり、非社会的であり、他の開発者を困らせることになります。git rebaseドキュメントの「アップストリームリベースからの回復」セクションさらに強調して説明します。
他の人が作業のベースにしたブランチをリベース (またはその他の形式の書き換え) するのは、良い考えではありません。下流にいる人は誰でも、自分の履歴を手動で修正しなければならなくなります。このセクションでは、下流の視点から修正方法を説明します。ただし、本当の修正方法は、そもそも上流のリベースを避けることです。 …