実用的な例を備えたGit Interactive Rebaseのガイド

gitインタラクティブベースの変更：開発効率を向上させるための強力なツール

GITバージョン制御は、最新の開発者のツールボックスで標準になっています。 commit、push、pull

コアポイント

Interactive Rebaseは、開発者が適切に構造化されたコミット履歴を作成できる強力なGitツールであり、プロジェクトのコードベースを読みやすくしやすくします。
インタラクティブなレベーゼを使用して、古いコミット情報の編集、コミットの削除、複数のコミットのマージ、コミットの再注文、古いコミットの修理、編集のために古いコミットを分割/再開することができます。
履歴を書き換えるため、リモートリポジトリの同僚と共有されているコミットでインタラクティブなリベースを使用しないことが重要です。代わりに、チームブランチにマージする前に、地元のコミットをクリーンアップするために使用する必要があります。
• インタラクティブな基本操作の基本メカニズムには、操作する提出履歴パーツの識別、
コマンドでセッションを開始し、オープンエディターウィンドウで必要なアクションを指定することが含まれます。
• git rebase -iインタラクティブなリベースを使用して、古いコミット情報を編集し、不必要なコミットを削除し、複数のコミットを1つにマージし、それによりコミット履歴を最適化およびクリーンアップできます。
インタラクティブなレベーゼがすべての開発者ツールボックスの一部である必要がある

要するに、インタラクティブなリベースは、プロジェクトでクリーンでよく構築されたコミット履歴を作成できるようにすることで、より良い開発者になるのに役立つと言うことは誇張ではありません。

なぜよく構造化された提出履歴が重要なのですか？反対を想像してください：読みにくい提出履歴、あなたの同僚の最近の変更が実際に何をしたかわかりません。このようなプロジェクトにはますます「暗いコーナー」があり、あなたはあなたの参加のほんの一部しか知っていません。

それをきれいで十分に構築されたコミット履歴と比較してください。プロジェクトのコードベースをより読みやすく、

およびを理解しやすくするのに役立ちます。これは、健康で永続的なプログラムの必要な部分です！

インタラクティブなベース変更はあなたのために何をすることができますか

インタラクティブなレベーゼは、コミット履歴を最適化してクリーンアップするのに役立ちます。多くの異なるユースケースをカバーしていますが、そのうちのいくつかは次のことを行うことができます。

• 古い提出情報を編集します
• 提出物を削除
• 複数のコミットをマージ/結合
• 提出の再注文
• 古いコミットを修正
• 編集のための古いコミットを分割/再開します

インタラクティブなリベースを使用する時期（およびそうでない場合）

他のいくつかのgitツールと同様に、「履歴を書き直す」ことをインタラクティブに再編成します。つまり、インタラクティブなリベース操作を使用して一連のコミットを操作する場合、コミット履歴のこの部分は

には、単純だが重要なルールが必要であるという事実は、リモートリポジトリの同僚と共有しているコミットに関するインタラクティブなレベース（または履歴を書き換えるための他のツール）を使用しないでください。代わりに、それを使用して、たとえば、独自の機能ブランチの1つで、独自のローカルコミットをクリーンアップし、チームブランチにマージします。

インタラクティブベース操作の基本的なメカニズム

インタラクティブなレベースは多くの異なるものに使用できますが、それらの基本的なワークフローは常に同じです。この基本的なメカニズムをしっかりと理解すると、インタラクティブなリベースは「複雑で神秘的な」雰囲気を失い、ツールボックスで貴重で使いやすいツールになります。

ステップ1：セッションはどこから始めればよいですか？

最初に答える必要があるのは、「コミット履歴のどの部分を動作させたいですか？」実用的な例を示しましょう。古いコミット情報を編集したいとします（これはまさに実際にやろうとしていることです）。

開始状況を以下の図に示します。インタラクティブな変更ベースを通じて古い提出情報を編集します。

C2のコミット情報を変更できるようにするには、親のコミットでインタラクティブなリベースセッションを開始する必要があります（または以前に、必要に応じて）。この例では、C1をインタラクティブリベースセッションの出発点として使用します。

ステップ2：実際のセッションを開始してください！

実際のセッションを開始するのは非常に簡単です：

コマンドを

フラグ（「インタラクティブ」にしたいことを示します）を使用し、基本的なコミットを提供します（上記の最初のステップで思いついた）。この例では、「頭の後ろに遅れをとった3つのコミット」というコミットを指定するために

を使用しました。または、特定のSHA-1ハッシュも提供することもできます。

<code>$ git rebase -i HEAD~3</code>

ステップ3：gitに何をしたいかを伝えます-i git rebaseインタラクティブなリベースセッションを開始した後、GITが一連のコミットをリストするエディターウィンドウが表示されます。 。 HEAD~3

このステップでは、2つのポイントに注意する必要があります。

1. 提出物は逆順序でリストされています！リストの上部に表示される最新の提出物は、リストのの下部に表示されると予想されます。心配しないでください：あなたのgitリポジトリはそのままです！操作の終了時に、GITが古いものから新しいものに再請求する必要があることを覚えています。 このエディターウィンドウで実際の変更を加えないでください！このエディターウィンドウでコミット情報を直接変更するように誘惑されるかもしれませんが（結局、それはまさに私たちがやりたいことです...）、あなたは忍耐強くなければなりません。ここでは、実際の変更を加えるのではなく、私たちがやりたいことをGitに伝えています。私はこれをすぐに実際に実証します！
この理論的な概要では、いくつかの実用的なケースに一緒に飛び込みましょう！
2. 古い提出情報を編集します
インタラクティブなリベースの最も人気のあるユースケースの1つは、その後古い提出物を編集できることです。また、

で送信された情報を変更することもできますが、これは最新の

提出物にのみ適用されます。これより古いコミットでは、インタラクティブなリベースを使用する必要があります！

特定のシナリオを見てみましょう。以下は、修正する必要があるエラー送信情報の画像です。

git commit --amend

注：より良い概要とより明確な視覚化のために、いくつかのスクリーンショットでTower Gitデスクトップクライアントを使用しました。このチュートリアルに従うためにタワーは必要ありません。

この例では、「インデックスの最適化マークアップ構造...」というタイトルの現在の提出のメッセージを編集したいとします。

最初のステップは、このインタラクティブなリベースセッションの基本的なコミットを決定することです。 「Bad Apple」コミットの親コミットに（少なくとも）親のコミットに戻る必要があるため、

（ヘッドコミットの後ろに3つのコミット、つまり、「Hading Headlines ...」というタイトルのコミット）を使用します。セッション： このコマンドを実行した後、お気に入りの編集者は、選択したばかりのコミットのリストを開いて表示します（基本的なコミットを提供することで）。

HEAD~3リマインダー：これを行うように誘惑されるかもしれませんが、ここで提出情報は変更しません。 「操作キーワード」のみを使用して、対応する列の行をマークします。私たちの場合、コミットをオーバーライドしたい（つまり、コミット情報を変更したいが、残りのコミットを維持することを意味します）。

<code>$ git rebase -i HEAD~3</code>

実際、利用可能なすべてのアクションキーワードは、このウィンドウの下部に指定されています。そのため、何も覚えておく必要はありません。

標準

キーワードを優先アクションキーワード（「そのまま」を受け入れることを意味する）に置き換えたら、ウィンドウを保存して閉じるだけです。

これを行うと、現在のコミット情報とともに新しいエディターウィンドウが開きます。最後に、最初にやろうとしていることを行うことができます。この古いコミットメッセージを編集してください！

変更を加えてエディターウィンドウを保存して閉じた後、インタラクティブなリベースセッションが完了しました。私たちの提出情報が更新されました！ ？

不要な提出物を削除

また、

Interactive Rebaseを使用すると、必要のない（または望まない）歴史からの古いコミットを削除することもできます。最近の提出に誤って個人的なパスワードを含めることを想像してください。ほとんどの場合、そのような機密情報をコードベースに含めるべきではありません。

また、情報を削除して再度コミットするだけでは、実際に問題を解決することはありません。これは、パスワードが古いコミットとしてリポジトリに保存されていることを意味します。本当に欲しいのは、このデータをリポジトリから完全にきれいに削除することです！

最初にインタラクティブリベースセッションの基本的なコミットを決定します。少なくとも間違ったコミットの親のコミットから始める必要があるため、「最適化マークアップ構造...」を使用します。 今回は、

コマンドで特定のSHA-1ハッシュを使用したことに注意してください。もちろん、ハッシュをコミットすることに加えて、そのコミットを処理するために

を使用することもできます。

このコマンドを実行した後、再びコミットリストが表示されます。

<code>$ git rebase -i HEAD~3</code>

git rebase -iHEAD~2

今回は、

アクションキーワードを使用して、不要なコミットを取り除きます。または、この特別な場合、エディターから行全体を削除するだけです。ウィンドウを保存および閉じるときに行が存在しなくなった場合（コミットを表します）、Gitは対応するコミットを削除します。

あなたが選択したものは何でも、エディターウィンドウを保存して閉じた後、リポジトリ履歴から送信が削除されます！

複数のコミットを1つの

にマージします インタラクティブなリベースの別のユースケースは、複数の個別のコミットを1つにマージしたい場合です。仕事の方法に飛び込む前に、いつ、またはなぜ価値があるのか​​を議論して数分間費やしましょう。 drop

一般的に言えば、（複数のコミットを1つに組み合わせることにより）コミットすることは、ほとんどの場合、良い戦略ではありません。一般的な経験則は、「小さい」という意味で「読みやすくなりやすい」ことを意味するため、一般的な経験則はできるだけ小さくすることです。ただし、場合によっては、これはまだ理にかなっています。 2つの例を次に示します。

• 古いコミットに何か問題があることに気づいたと想像してください。その後、A newコミットを生成して、問題を修正することができます。この場合、これらのコミットを1つに統合することは理にかなっています。結局のところ、新しいコミットは、存在するべきではない問題を修正するための「停止可能」です。これらのコミットを組み合わせることで、まったく問題はないようです！
• もう1つの例は、少し詳細にしていることに気付いたときです。小規模なコミットを作るのは良いことですが、多くの不必要な小さなコミットでコミット履歴を埋めることは、目標を超えることを意味します。 両方の例の基本原則は同じです。コミットであった2つ（またはそれ以上）のコミットを組み合わせることで、よりクリーンで読みやすいコミット履歴を作成しています！

一緒に実用的な例を完成させ、次の写真に示されている状況を最初の状況として使用しましょう。

この2つのコミットを1つのコミットに統合する方が意味があると仮定します。インタラクティブなリベースツールを使用して、これを行うことができます：

これまでのところ、何が起こっているのか慣れています。エディターウィンドウは、提出物のリストで開きます。 squash

<code>$ git rebase -i HEAD~3</code>

この場合、

操作キーワードを使用すると述べました。どのように機能するかについて知っておくべき重要なことが1つあります。キーワードでマークされた行は、すぐ上の行と融合します。 これは、例の

キーワードで行2をマークした理由を説明しています。

このウィンドウを保存および閉じた後、新しいウィンドウが開きます。これは、複数のコミットを組み合わせることで、もちろん新しいコミットを作成するためです。また、この提出には、他の提出と同様に、提出情報も必要です！ squash squash 上記のスクリーンショットに表示されているのは、Gitが私たちのために準備したものです。それは、対応する元のコミットの提出情報といくつかのコメントを組み合わせています。古いメッセージを自由に削除してやり直してください。または、それらを保持して情報を追加してください。 squash このエディターウィンドウを保存して閉じた後、誇らしげに言うことができます。以前は2つの別々のコミットでしたが、今では1つのコミットです！

インタラクティブなベース変更の強力な関数を使用します

Gitのインタラクティブなリベースツールが非常に価値があることに同意していただければ幸いです。開発者として、私たちはクリーンで明確なコミット履歴を求めて努力しなければなりません。これは、コードベースを健康で理解しやすい状態に保つための重要な要素です（チームメイトとあなた自身のために、しばらくしてからです）。

もっと知りたい場合は、「Git First Aid Kit」を強くお勧めします。これは、Gitのエラーをクリーンアップして元に戻す方法を示す（無料の）短いビデオコレクションです。

楽しんでください！

gitインタラクティブチェンジベースFAQ（FAQ）

Git RebaseとGit Mergeの違いは何ですか？

Git RebaseとGit Mergeは、あるブランチから別のブランチに変更を統合する2つの異なる方法です。 Git Mergeは、2つの異なるブランチからコードを直接結合する方法です。それは歴史に新しいコミットを生み出し、コミットの時系列秩序を維持します。一方、Git Rebaseは、一連のコミットを新しい基本的なコミットに移動または組み合わせる方法です。 「私は自分の変化に他の人の仕事を追加したい」と言っているようなものです。言い換えれば、別のブランチの上部にある現在のブランチに変更を配置できます。

gitのリベースを元に戻す方法は？

Git Rebaseを元に戻す場合は、コマンドを使用して、返信するコミットを見つけて、コマンドgit reflogを使用できます。 git reset --hard HEAD@{number}コマンドには、ヘッドに作成された各変更のリストが表示され、git reflogコマンドを使用すると、現在の頭を指定された状態に設定できます。 git reset

Git Interactive Rebaseの目的は何ですか？

Git Interactive Rebaseを使用すると、編集、削除、圧縮など、さまざまな方法でコミットを変更できます。コミット情報を変更するだけでなく、実際のコードを変更することもできます（間違いを犯した場合）。これは、プロジェクトの提出履歴を完全に制御できる強力なツールです。

Git Interactive Variable-Base圧縮提出の使用方法は？

圧縮は、複数のコミットを1つのコミットに統合する行為です。 GITでは、

コマンドを使用してコミットを圧縮できます。 Open Text Editorでは、またはに置き換えて、圧縮したいコミットをマークすることができます。 git rebase -i pick Git Interactive Rebaseを使用するリスクは何ですか？ squash sGit Interactive Rebaseは強力なツールですが、不適切に使用すると危険になります。それはコミット履歴を書き直します。これは、他の人が扱っている公共支部を扱っている場合に問題を引き起こす可能性があります。まだプッシュされていないローカルブランチで使用することをお勧めします。

git変更ベース中に競合を解決する方法は？

衝突は、リベースのプロセス中に発生する可能性があります。 GITは一時停止し、継続する前にこれらの競合を解決することができます。ファイルを編集して競合する変更を修正し、

を使用して解決されたファイルを追加して、競合を解決することができます。すべての競合が解決された後、

を使用してベースを変更し続けることができます。

gitインタラクティブな変更ベースを使用してコミットを分割できますか？

はい、Git Interactive Rebaseを使用してコミットを小規模なコミットに分割できます。これは、1つのコミットで複数の変更を加えたが、それらが別々のコミットであるべきだと判断した場合に非常に便利です。

gitインタラクティブな変更基準を使用して送信情報を編集する方法は？

インタラクティブなリベース中に送信情報を編集できます。送信リストで、pickまたはrewordにrまたはrewordに置き換えて、編集する提出物をマークします。継続すると、GITは

とマークされた各提出物のテキストエディターを開き、提出情報を変更できるようにします。

Git RebaseとGit Pullの違いは何ですか？

Git pullGit rebaseは、リモートリポジトリから変更を取得し、それらを現在のブランチにマージするコマンドです。一方、

は、一連のコミットを新しい基本的なコミットに移動または組み合わせるコマンドです。両方のコマンドは統合の変更に使用されますが、それらは異なる方法で実行されます。

Git Interactive Rebaseを使用してコミットの順序を変更できますか？

はい、Git Interactive Rebaseを使用してコミットの順序を変更できます。コミットリストでは、行の順序を変更してコミットの順序を変更するだけです。これは、コミット履歴をより論理的またはより明確にしたい場合に非常に便利です。

以上が実用的な例を備えたGit Interactive Rebaseのガイドの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。