導入
コードを送信するときに誤って間違ったコードを送信してしまった場合はどうすればよいですか?
送信されたメッセージに誤って文字が抜けていましたか? 提出されたコードのスペルミスのある単語を変更するのを忘れているようですか? 何度か提出して少しごちゃごちゃになってしまったのですが、まとめられるでしょうか？master ブランチが更新されました。切り替えたときに異なる場合はどうすればよいですか? ? ? などなど、リセットとリベースデビュー~~人生は再開できませんが、コミットは再開できます。
シナリオ 1: 送信時にメッセージが間違って書かれた場合はどうすればよいですか?
投稿したとき、メッセージが画像のように「初めての投稿、初めての投稿」と書かれていたのですが、違和感があるので変更したいのですが、「初めての投稿、初めてのファイルの投稿」に変更したいと思います
。メッセージの変更を完了します。
最初の方法:amendコマンドを使用して直接変更します~。git commit --amend図に示すように、対話型の変更ウィンドウが開きます。
最初の行がエラー メッセージであることがわかります。直接変更します。そして保存するだけです。このウィンドウの操作は Linux のテキストエディタと同じですが、操作方法が分からない場合は、編集画面の英語状態でiキー (insert) を押して挿入モードに入ることができます。このモードでは、編集と挿入を実現できます。挿入モードに正しく入ると、左下隅に INSERT プロンプトが表示されます: 次に、
Enter を押して変更します。変更が完了したら、Esc最初にキーを押し、次にコロンを入力しますwq図に示すように、英語で「
変更が成功しました~」と入力してから接続しますgit -log。コマンドを使用して再度確認すると、図に示すように、変更が成功したことがわかります。
2 番目の方法:reset命令を使用して変更します。命令を使用してgit reset --soft 完了できますが、この命令は直接の変更ではありません。まず git の現在のステータスを確認します。命令を使用してステータスを表示しますgit status。
変更がないことがわかります。 ; 次に、a.txt に変更を加え、ステータスを確認します: showmodified
一時保存領域に追加して提出します 提出情報は「a.txtファイルを修正しました」となっています 修正内容は不明のようです では、提出情報を修正してみましょうコンテンツを追加します;
まず見てみましょう ステータスを見てください: 実行すると、git status
変化がないことがわかります。 ここでgit reset --soft HEAD~コマンドを実行します。実行後に何も起こらなかったようで、プロンプトも表示されません。もう一度ステータスを見てみましょうgit status
入力が確認でき、修正された状態に戻ります~~~ ~ これは修正された状態ではないでしょうか? 提出しなかったときの状態ではないですか？ 提出前に直接戻ったのはリセットコマンドのはずです。時間を遡ってみましょう。ログを見てみましょう。あのときは本当ですか？戻ってきました: 送信が 1 つだけであることがわかります。実際に時間が
戻っています ~ その後、間違ったことをやり直すことができます。あとは再送信するだけでよく、修正が実際に完了していることがわかります。
今は急いで幸せにならないでください~記憶が新しいうちに時間を戻すことができるこのコマンド: リセット、その機能、使用方法、および各パラメーターの違いについて学びましょう
リセットコマンドの詳しい説明
先ほどの操作の後、reset コマンドで時間を戻すことができることがわかりました。これは非常に便利です。間違ったコードを書いた場合、間違ったコードを送信した場合、間違ったメッセージを送信した場合に使用できます。
先ほど使用したコマンドは次のとおりです。git reset --soft HEAD~この -soft は何を意味しますか? Reset は本来リセットするという意味なので、どこをどのくらいリセットするかは –soft Later~ で決まります。 実は、以下のようにその後に他のパラメータを追加することもできます。
git resset --soft
git reset --mixed
gtt reset --hard
そうです、パラメータが 3 つあるので、1 つずつ見てみましょう。
git を使用するときのコード作成プロセスを思い出してください。更新されたブランチにコードを書き込み、書き込み後に一時ストレージ領域に追加し、ローカル ウェアハウスにコミットして、リモート ウェアハウスにプッシュします。一般的なプロセスは次のとおりです。 our
–soft 追加後およびコミット前にフォールバックします;
–mixed は追加前にフォールバックします; これはデフォルトのパラメータです~ つまり、追加しない場合、デフォルトはこの範囲です;
–難しいのは、コードを書く前に最初に戻ることです。これを行うと、書いたコードが破壊されてしまうので注意してください。
実験: 新しいファイル b.txt を作成し、それを一時記憶域に追加し、そこに文を書き込んでコミットします。
ログとステータスを確認します。以前の 2 つの送信が表示されます。ステータスは
新しいファイルです。 b.txt はきれいです。ステータスが追跡されていないことを確認しますgit add .。ファイルを追跡します。
緑色のファイル名と追跡ステータスが表示されます。今すぐ編集します。「こんにちは、私はハンサム ガイです」という単語を 1 行書きます。ステータスを確認し、再度追加します。一時ストレージ領域では、b.txt がまだ緑色であることがわかります。それから直接送信して、ログを確認します。次に、-soft パラメーターを使用します。それが何であるかを見てみましょう
。コマンドを実行してgit reset --soft HEAD~、ログとステータスを確認します。
確かに緑色になり、送信ログが消えていることがわかります。つまり、--soft rolls back to add, before commit; now
I送信を続行し、ログとステータスを確認します:
ログが追加されたことがわかります。はい、つまり送信しました。ステータスはクリーンです。
今、 --mixed パラメータを使用してロールバックして実行します。コマンド: git reset --mixed HEAD~、覚えておいてください~mixed がデフォルトであり、追加しないことも可能です。その後、ログとステータスを確認します。
見てください~ 赤の追跡されていない状態になり、送信されたログ レコードが消えています。これは追加なしの状態です。追加する前に戻っていますか。その後、追加してコミットします: 今、-hard パラメーターを使用します: コマンドを実行
し
ます: git reset --hard HEAD~、次のようなプロンプトが表示されます:
ログとステータスを再度確認してください: ログ
が消え、ステータスがクリーンに変化していることがわかります。これはどういう意味ですか? ファイル ディレクトリをもう一度見てみましょう: はい、それが表示されてい
ます新しく作成されたファイル b.txt はロールバックされ、元の状態、つまり b.txt が作成されていない状態にロールバックされました~
OK~ 上記の実験を通じて、リセットの意味を明確に理解しました。それから実際のシーンを見てください
シナリオ 2: ある日、関数を書き終えて、それをコミットした直後にプッシュする必要があるとき、上司が来て、この関数は当分オンラインにしないと言われました...
この場合、ロールバック送信を直接使用しgit reset --soft HEAD、不要なコードを stash に一時的に保存し (よくわからない場合は、stash に関する私の記事を読んでください)、それを新しいブランチに保存し、次の期間まで永久に保存します。いつか、必要に応じてターゲットのブランチにチェリーピックします。このアイデアに従って実装し、お気に入りの Baozi もそれに従うことができます。
新しいファイル c.txt を作成し、「私は美しい女性です」という内容を書き込みます。
次に、追加してコミットします。このとき、リーダーがやって来て、この機能は現時点では必要ないので、後で説明しますと言いました。
直接リセットしてコミット前に戻します。
その後、stash は一時的に保管されます。
新しく一時的なブランチを切り取り、一時的に保存したコードを取り出し、このブランチに保存します。おお、git stash pop 0pop と apply の違いを使用していることに注意してください。pop は直接取り出され、保存されていた stash は失われ、直接取り去られます。 apply は単なるアプリケーションであり、スタッシュの内容はまだそこにあります。
突然上司が「この機能をもう一度やり直す必要がある」と言い、「シャオフー、あなたは一生懸命働いて、オンラインにして残業代を与えるために一晩中残業してきました。あなたは難しいと言って同意し、その後、全員が仕事を終えて残りました」と言いました。上司のニーズを満たすために残業する必要がありました。あなたは落ち着いてテイクアウトを注文し、ガールフレンドと 2 時間の電話をし、食事を終えて仕事を始めました。あなたは以前保存したブランチを冷静に見つけて、開発ブランチにマージしました。 、そして上司にそれが完了しました、提出されてMRに送信されました、上司に見てもらいましょう、ウーフーは仕事を休んでいます、エレガント〜
シナリオ 3: 複数の提出物をリリースしましたが、どれもプッシュされていません。少し乱雑で面倒に感じます。それらを 1 つの提出物にマージしたい場合はどうすればよいですか?
この操作を実行するには 2 つの方法があります。前回のリセットを覚えておいてください。--softパラメータを覚えておいてください。後でこれを使用して複数のコミットをマージします。また、リベースも実装できます。
方法 1: リセットでバージョンをロールバックでき、–soft パラメーターを追加すると、追加後コミット前にロールバックされ、追加後すべてのコミットをロールバックしてから再コミットします。マージされませんか?それを実現しましょう。
新しいファイル d.txt を作成し、追加してコミットして最初のコミットを完了します。
ファイル d.txt を変更し、追加してコミットして 2 番目のコミットを完了します。
ファイル d.txt を変更し、追加してコミットして 3 番目のコミットを完了します。
ファイル d.txt を変更し、追加してコミットして 4 番目のコミットを完了します。
次に、2 番目、3 番目、4 番目のコミットを 1 つのコミットにマージします。つまり、図のコミット ID は、丸で囲んで 1 つのコミットにマージした 3 回の値です。 コマンドを実行します。3つのgit reset --soft HEAD~~~コミットが正常に配置されたことがわかります。ストレージ領域の後、つまり追加後は、再度コミットしてマージして一緒に送信するだけで済みます。
コマンド内の「HEAD~~~」は、現在の先頭ポインタが 3 回前に移動することを意味します。ただし、3 つの ~ を除いて、3 つの「 」はHEAD~3同じです。
方法 2: リベースを使用して実装します。
ファイル d.txt の編集を続け、追加してコミットして最初の送信を完了します。
ファイル d.txt の編集を続け、追加してコミットして 2 番目の送信を完了します。
ファイル d.txt の編集を続け、追加してコミットして 3 番目の送信を完了します。
次に、リベースによって edit1、edit2、および edit3 をマージし、コマンドを実行します。git rebase -i HEAD~3この時点で、リベース ウィンドウが開き、3 つを選択します。図に示すように、指定した送信が表示されます。
たとえば、edit2 と edit3 を edit1 にマージして 1 つにしたい場合、前の選択を squash または s に変更するだけで済みます (操作は次の場合と同じであることに注意してください) Linux vim では、まず挿入モードに入ります (図に示すように):
次に、保存して終了すると、メッセージ編集ボックスがポップアップ表示され、3 つの送信がマージされた後にメッセージをどのように書くかを尋ねられます。これらを削除して、次の操作を行います。それを文に変換し、保存して終了します。
リベースが成功し、ログを確認し、マージが成功したことがわかります。
このリベースの神聖さは何なのか、なぜ複数のコミットがマージできるのか、来て見てください。
rebaseコマンドの詳しい説明
どこから始めてもダメな気がします 色々考えた結果、先ほどのマージの際に使ったマージコミットコマンドから始めましょう ここの -i は対話型エディタを開くためのものです 対話的にリベースできますgit rebase -i HEAD~3インターフェースおおよそ次のようになります。
各コマンドの意味は次のとおりです。
- リスト項目
- pick: コミットを維持する (省略形: p)
- 言い換え: コミットは保持しますが、コミットのコメントを変更する必要があります (略語: r)
- edit: コミットは保持しますが、コミットを停止して (コメントだけでなく) 変更したい (省略形: e)
- squash: このコミットを前のコミットとマージします (省略形: s)
- 修正: このコミットを前のコミットとマージしますが、コミットのコメント情報を保持したくありません (省略形: f)
- exec：シェルコマンドの実行（略称：x）
- Drop：コミットを破棄したい（略称：d）
使用方法については、次のシーンを参照してください。
シナリオ 4: master ブランチからブランチをプルして開発しています。開発が完了したらサブミットしたいのですが、若い男性がすでにマスターにサブミットを行っていることに気付きました。ブランチは前のマスターからカットされています。彼のコミットはありませんが、マージすると彼のコミットが存在します。この状況ではどうすればよいですか?
この状況は非常に単純で、現在のブランチをリベースし、ブランチに送信したマスターをリベースし、命令を実行します。git rebase masterリベースが完了したら、競合することなく送信すれば、すべて問題ありません。