リベースとは、一連のコミットを新しいベースコミットに移動または結合するプロセスです。 リベーシングは、機能分岐ワークフローのコンテキストで最も便利で簡単に視覚化できます。 一般的なプロセスは次のように視覚化できます。

コンテンツの観点からは、リベースとは、ブランチのベースをあるコミットから別のコミットからブランチを作成したかのように見えるようにすることです。, 内部的には、Gitは新しいコミットを作成し、指定されたベースに適用することでこれを達成します。 ブランチは同じように見えますが、まったく新しいコミットで構成されていることを理解することは非常に重要です。

使用法

リベースの主な理由は、線形プロジェクト履歴を維持することです。 たとえば、フィーチャブランチの作業を開始してからmasterブランチが進行している状況を考えてみましょう。, Featureブランチでmasterブランチの最新の更新を取得したいが、最新のmasterブランチで作業しているかのように表示されるように、ブランチの履歴をきれいに これにより、フィーチャブランチをマスタブランチにきれいにマージすることができます。 なぜ私たちは”きれいな歴史”を維持したいのですか？ クリーンな履歴を持つことの利点は、回帰の導入を調査するためにGit操作を実行するときに具体的になります。 より現実的なシナリオは次のとおりです。

1. masterブランチでバグが特定されます。, 正常に動作していた機能が壊れています。
2. 開発者は、git log“クリーン履歴”のため、開発者はプロジェクトの履歴についてすぐに推論することができます。
3. 開発者は、git logを使用してバグがいつ導入されたかを識別できないため、開発者はgit bisectを実行します。
4. gitの履歴がきれいであるため、git bisect回帰を探すときに比較する洗練されたコミットセットがあります。, 開発者はすぐにバグを導入したコミットを見つけ、それに応じて行動することができます。

git logおよびgit bisectの詳細については、個々の使用法ページを参照してください。

機能をmasterブランチに統合するには、直接マージするか、リベースしてからマージするかの二つのオプションがあります。 前者のオプションは3ウェイマージとマージコミットをもたらし、後者のオプションは早送りマージと完全に線形の履歴をもたらします。 次の図は、masterブランチへのリベースが早送りマージを容易にする方法を示しています。,

リベーシングは、アップストリームの変更をローカルリポジトリに統合する一般的な方法です。 Git mergeで上流の変更を取り込むと、プロジェクトがどのように進行したかを確認するたびに余分なマージコミットが発生します。 一方、リベーシングは、”私は誰もがすでに行っていることに私の変更をベースにしたいと言っているようなものです。”

公開履歴をリベースしない

以前に履歴の書き換えで説明したように、公開リポジトリにプッシュされたコミットをリベースしないでください。, リベースは古いコミットを新しいコミットに置き換え、プロジェクト履歴のその部分が突然消えたように見えます。

Git Rebase Standard vs Git Rebase Interactive

Git rebase interactiveは、git rebaseが-- i引数を受け入れるときです。 これは”Interactive”の略です。”引数なしで、コマンドは標準モードで実行されます。 どちらの場合も、別の機能ブランチを作成したとしましょう。,

 # Create a feature branch based off of master git checkout -b feature_branch master # Edit files git commit -a -m "Adds new feature" 

標準モードのGit rebaseは、現在の作業ブランチのコミットを自動的に受け取り、渡されたブランチの先頭に適用します。

 git rebase 

これにより、現在のブランチが自動的ににリベースされ、任意の種類のコミット参照（たとえば、ID、ブランチ名、タグ、HEAD

git rebase-iフラグで-iを実行すると、対話型のリベースセッションが開始されます。, すべてのコミットを新しいベースに盲目的に移動する代わりに、対話型リベースは、プロセス内の個々のコミットを変更する機会を与えます。 これにより、既存の一連のコミットを削除、分割、変更することで履歴をクリーンアップできます。 それはステロイドのGit commit --amendのようなものです。

 git rebase --interactive 

これは現在の分岐をにリベースしますが、対話型のリベースセッションを使用します。 これにより、リベースされる各コミットのコマンド（後述）を入力できるエディタが開きます。, これらのコマン また、コミットリストを並べ替えて、コミット自体の順序を変更することもできます。 リベース内の各コミットに対してコマンドを指定すると、Gitはリベースコマンドを適用してコミットの再生を開始します。 リベース編集コマンドは次のとおりです。

追加のリベースコマンド

書き換え履歴ページで詳しく説明されているように、リベースを使用して、古いコミット、複数のコミット、コミットされたファイル、複数のメッセージを変更できます。, これらは最も一般的なアプリケーションですが、git rebaseには、より複雑なアプリケーションで役立つ追加のコマンドオプションもあります。

• git rebase -- d再生中にコミットが結合された最後のコミットブロックから破棄されることを意味します。
• git rebase -- pコミットはそのまま残します。 コミットのメッセージやコンテンツは変更されず、ブランチ履歴の個々のコミットになります。
• git rebase -- x再生中に、マークされた各コミットでコマンドラインシェルスクリプトを実行します。, 便利な例としては、特定のコミットに対してコードベースのテストスイートを実行することで、リベース中の回帰を特定するのに役立ちます。

Recap

対話型リベースを使用すると、プロジェクト履歴の外観を完全に制御できます。 これは、コードを書くことに集中している間に”厄介な”履歴をコミットし、その後戻って事実の後にクリーンアップすることができるため、開発者に多くの

ほとんどの開発者は、メインコードベースにマージする前に、機能ブランチを磨くために対話型リベースを使用するのが好きです。, これにより、重要でないコミットをスカッシュし、古いコミットを削除し、”公式”プロジェクト履歴にコミットする前に他のすべてが順番になっている 他のすべての人にとっては、機能全体がよく計画されたコミットの単一のシリーズで開発されたように見えます。

インタラクティブなリベースの本当の力は、結果として得られるマスターブランチの履歴に見ることができます。 他のみんなにとって、あなたは最初に完全な量のコミットで新しい機能を実装した素晴らしい開発者のようです。, こうして双基準改定できるプロジェクトの歴史はクリーンで意義深いものでした。

設定オプション

git configを使用して設定できるリベースプロパティがいくつかあります。 これらのオプションは、git rebase出力の外観を変更します。

• rebase.stat:デフォルトでfalseに設定されているブール値。 オプションを切り替え表示の視覚diffstatるコンテンツは現在表示されているはdebase.

• rebase.autoSquash:--autosquash動作を切り替えるブール値。,

• rebase.missingCommitsCheck:は、欠落しているコミットの周りのリベース動作を変更する複数の値に設定できます。,/tr>

  error

  Stops the rebase and prints removed commit warning messages

  ignore

  Set by default this ignores any missing commit warnings
  • rebase.instructionFormat: A git log format string that will be used for formatting interactive rebase display

  Advanced rebase application

  The command line argument --onto can be passed to git rebase., Git rebase--ontoモードでは、コマンドは次のように展開されます。

    git rebase --onto 

  --ontoコマンドは、より強力なフォームまたはリベースを可能にし、リベースのヒントとなる特定のrefを渡すことを可能にします。
  次のようなブランチを持つ例のレポがあるとしましょう。

    o---o---o---o---o master \ o---o---o---o---o featureA \ o---o---o featureB 

  featureBはfeatureAに基づいていますが、featureBはfeatureAの変更に依存せず、masterから分岐することができます。

    git rebase --onto master featureA featureB 

  フィーチャはです。, masterはになり、featureBはHEADのが指すものの参照です。 結果は次のとおりです。

    o---o---o featureB / o---o---o---o---o master \ o---o---o---o---o featureA 

  リベースの危険性を理解する

  Git Rebaseを操作するときに考慮すべき注意点は、リベースワークフロー中にマージの競合がより頻繁になる可能性があることです。 これは、マスターから逸脱した長命のブランチがある場合に発生します。, その時点で、ブランチの変更が競合する可能性のある多くの新しいコミットが含まれている可能性があります。 これは、masterに対してブランチを頻繁にリベースし、より頻繁にコミットすることで簡単に改善できます。 --continueおよび--abortコマンドライン引数をgit rebaseに渡して、競合を処理するときにリベースを進めたりリセット

  より深刻なリベース警告は、対話型履歴の書き換えから失われたコミットです。, 対話モードでrebaseを実行し、squashやdropのようなサブコマンドを実行すると、brancheの即時ログからコミットが削除されます。 一見すると、これはコミットが永久になくなったかのように見えます。 Div id=”241a8b651a”>を使用すると、これらのコミットを復元し、リベース全体を元に戻すことができます。 git reflogを使用して失われたコミットを見つける方法の詳細については、Git reflogのドキュメントページをご覧ください。

  Git Rebase自体は深刻な危険ではありません。, 実際の危険なケースは、対話型リベースの書き換え履歴を実行し、他のユーザーが共有するリモートブランチに結果を強制的にプッシュするときに発生します。 このパターンになることは避けるべきとしての能力を上書きその他のリモートユーザーの作業が引きしています。

  上流リベースからの回復

  別のユーザーがリベースし、コミットしているブランチに強制的にプッシュされた場合、git pullは、その前のブランチに基づいていたコミットを強制的にプッシュされたヒントで上書きします。, 幸いなことに、git reflogを使用すると、リモートブランチのreflogを取得できます。 リモートブランチのreflogでは、refがリベースされる前にrefを見つけることができます。 その後、高度なRebaseアプリケーションセクションで説明したように、--ontoオプションを使用して、そのリモートrefに対してブランチをリベース

  概要

  この記事では、git rebaseの使用法について説明しました。 また基礎的及び高度利用の場合、より高度な例です。, いくつかの重要な議論ポイントは次のとおりです。

  • git rebase標準対インタラクティブモード
  • git rebase設定オプション
  • git rebase–ont
  • git rebase lost commits