Using version control and deploying（バージョン管理機能の使用とデプロイ）

このページは、プロジェクトはすでにバージョン管理用に設定されていることを前提としています。このページで説明する選択肢ではなく [Git の構成] ボタンが表示されている場合は、最初にプロジェクト用に Git を設定する必要があります。

Git の統合によるバージョン管理

Looker は、Git を使用して変更を記録し、ファイルのバージョンを管理します。各 LookML プロジェクトは 1 つの Git リポジトリに対応し、各デベロッパー ブランチは 1 つの Git ブランチに相関します。Git リポジトリは通常、リポジトリと呼ばれます。

Looker は通常、LookML のソースファイル管理に GitHub を使用します。ただし、GitLab、Bitbucket、または認証に SSH 認証鍵を使用できる他の Git サーバーなど、他の Git プロバイダと連携するように Looker を構成することもできます。

GitHub では、github.com での Git オペレーションの認証用のアカウントのパスワードを使用できません。詳しくは、GitHub のブログ投稿をご覧ください。HTTPS を使用して Looker プロジェクトを GitHub に接続するには、GitHub のデベロッパー設定を使用して個人用のアクセス トークンを作成します。HTTPS を使用して GitHub に接続する既存の Looker プロジェクトの場合は、GitHub の個人アクセス トークンを使用して Git 接続をリセットします。

Looker プロジェクトは、すべての Git インタラクションに Git プロバイダで 1 つのアカウントのみを使用します（Git の設定については、Looker と Git の統合のドキュメントをご覧ください）。Looker プロジェクトごとに、すべての Looker デベロッパーによる開発はすべてこの 1 つの Git アカウントを通過します。つまり、Looker デベロッパーが Git 統合オプションのいずれかで設定されていない限り、Looker デベロッパーは Git プロバイダに独自のアカウントを持つ必要はありません。この場合、Looker デベロッパーは Git プロバイダへの外部リンクを開くか、pull リクエストを作成するために Git アカウントが必要になります。

Git ブランチの操作

Git の主な利点の一つは、Looker デベロッパーがファイル リポジトリの分離されたバージョンである「ブランチ」で作業できることです。他のユーザーに影響を与えずに開発とテストを行うことができます。Looker の開発者は、開発モードのときはいつでも Git ブランチを使用します。

Git のもう一つの主な特長は、他のデベロッパーと簡単にコラボレーションできることです。ブランチを作成して（必要に応じて）変更し、他のデベロッパーがそのブランチに切り替えて、ブランチの内容を確認したり、変更したりできます。別のデベロッパーがブランチに変更を commit した場合、Looker は [Pull Remote Changes] ボタンを表示します。これらの追加変更をブランチに pull してから、さらに変更を行ってください。

マスター ブランチ、現在のブランチ、またはデベロッパーの個人用ブランチ以外のブランチを削除することもできます。

自身の支店

初めて開発モードに切り替えると、個人用の Git ブランチが自動的に作成されます。個人用のブランチは dev- で始まり、名前が含まれます。

個人ブランチは固有のブランチであり、削除することはできません。個人用のブランチは他のすべてのデベロッパーに対して読み取り専用になります。プロジェクトで他のデベロッパーと共同作業している場合は、新しいブランチを作成して、他のユーザーがそのブランチに切り替え、変更に対応できるようにすることをおすすめします。

ヒント: 別のデベロッパーの個人用ブランチに変更を加えることはできません。他の誰かが個人用のブランチで作業しているときは、そのブランチから新しいブランチを作成できます。

新しい Git ブランチを作成する

単純な修正に取り組む中で、他のデベロッパーとは共同作業をしない場合は、個人用のブランチが適しています。個人用のブランチを使用して迅速に更新し、変更を commit して本番環境に push できます。

ただし、個人用のブランチに加えて、新しい Git のブランチを作成することも可能です。新しい Git ブランチは次の状況で役立ちます。

• 他のデベロッパーと協力して作業する。個人用ブランチは他のデベロッパーには読み取り専用なので、他のデベロッパーと共同編集したい場合は、新しい Git ブランチを作成して、他のデベロッパーがそのブランチに書き込めるようにする必要があります。他のユーザーと共同作業している場合は、作業を再開するたびに変更を取得してください。そうすれば、作業を進める前に、すべてのデベロッパーからの最新情報を入手できます。
• あなたは一度に複数の機能セットに取り組んでいます。場合によっては、大きなプロジェクトの途中で、軽微な問題を解決したり、簡単な修正を行ったりする必要があります。この場合は、現在のブランチに変更を commit してから、別のブランチを作成するか別のブランチに切り替えて、別の機能セットを作業できます。新しいブランチで修正した後、そのブランチの変更を本番環境にデプロイしてから、元のブランチで作業を再開できます。

新しいブランチを作成する前に:

• 現在のブランチでマージ競合がある場合は、新しいブランチを作成する前に競合を解決する必要があります。
• 現在のブランチに commit されていない変更がある場合は、新しいブランチを作成する前に現在のブランチで変更を commit する必要があります。
• （本番環境のブランチではなく）既存の開発ブランチからブランチを作成する場合は、まずそのブランチに切り替えて、最新バージョンの開発ブランチを取得します。次に、リモートで変更を pullしてそのブランチのローカル バージョンを同期します。

新しい Git ブランチを作成するには:

1. 開発モードが有効になっていることを確認します。

2. [Develop] メニューで、プロジェクト ファイルに移動します。

   

3. 左側のアイコンメニューで [Git] アイコンをクリックして、[Git Actions] パネルを開きます。

4. [ブランチを表示] プルダウン メニューをクリックします。

5. [New Branch] を選択します。

   

6. [New Branch] ウィンドウで、ブランチの名前を入力します。Git ブランチ名には制限があります。命名要件については、このページの Git ブランチに名前を付ける際のルールをご覧ください。

7. [Create From] プルダウン メニューをクリックし、既存のブランチを選択して、新しいブランチの出発点として使用します。

8. [Create] をクリックしてブランチを作成します。

または、[Project Settings] ページの [Branch Management] タブで Git ブランチを作成することもできます。

Git ブランチに名前を付けるためのルール

Looker では、Git で指定されたブランチ命名規則の要件を使用している。

Git ブランチ名は、次のことを行ってはなりません。

• スペースが含まれている
• 二重ピリオド（..）を含む
• バックスラッシュを含む: \
• シーケンス @{ を含む
• 疑問符（?）を含む
• 左角かっこ（[）を入力してください
• ASCII 制御文字（~、\^、または :）を含む
• ピリオドで始める: .
• 接頭辞 dev- で始まります（Looker デベロッパーの個人ブランチ用に予約されています）。
• 末尾にはスラッシュ（/）を使用します。
• 広告表示オプションで終わる: .lock
  

また、ブランチ名にはアスタリスク（*）のみを使用できます。アスタリスクがパス コンポーネント全体（foo/* や bar/*/baz など）を表す場合は、実際のブランチ名の一部ではなく、ワイルドカードとして解釈されます。

別の Git ブランチへの切り替え

現在のブランチでマージ競合がある場合は、別のブランチに切り替える前に競合を解決する必要があります。

また、現在のブランチに commit されていない変更がある場合、現在のブランチで変更を commit するまで既存のブランチに切り替えることはできません。

別の Git ブランチに切り替えるには:

1. プロジェクトで、左側のアイコンメニューの [Git] アイコンをクリックして、[Git Actions] パネルに移動します。
2. [Git Actions] パネルで、現在の Git ブランチ名の横の [Git ブランチ] プルダウン メニューをクリックします。
3. メニューで切り替え先のブランチを選択するか、検索ボックスにブランチ名を入力します。ブランチ名検索では大文字と小文字が区別されません。たとえば、「DEV"」を検索して、「dev"」、「"DEV"」、「&devt\」などの名前を持つすべてのブランチを確認できます。

Git ブランチの管理

[プロジェクトの設定] ページの [ブランチ管理] タブに、Looker プロジェクトのすべての Git ブランチのテーブルが表示されます。[Branch Management] タブを開くには、左側のアイコン メニューから [Settings] アイコンをクリックし、[Branch Management] タブを選択して、[Project Settings] ページに移動します。

[Branch Management] タブでは、次のことができます。

1. [New Branch] ボタンをクリックして、新しいブランチを作成します。詳細については、このページの新しい Git ブランチの作成をご覧ください。
2. 検索バーで支店名を検索します。
3. [更新] ボタンをクリックしてテーブルを更新します。
4. 列の名前をクリックして、表を並べ替えることができます。

表には次の情報が含まれています。

• 名前: Git ブランチの名前。Looker デベロッパー&#39。個人ブランチは dev- で始まり、デベロッパーの姓名が含まれます。
• ステータス: ローカル バージョンのブランチとリモート バージョンのブランチの違い。たとえば、ステータスが 3 commits behind の場合、ローカル バージョンのブランチは、リモート バージョンのブランチよりも 3 つ commit されていることを意味します。Looker では常にマスターのリモート バージョンが使用されるため、[Branch Management] タブにマスター ブランチのローカル バージョンのステータスは表示されません。master ブランチは常に最新であると考えられます。
• 最終更新: Looker デベロッパーがブランチに commit してからの時間。
• 操作: ブランチを削除するボタン、またはブランチが削除の対象とならない理由。

Git ブランチを削除する

[ブランチ管理] タブで、テーブル内に [削除] ボタンがあるブランチを削除できます。次のブランチは削除できません。

• master ブランチ
• 現在のブランチ
• Looker デベロッパーの個人ブランチ

上のブランチには [削除] ボタンがありません。代わりに、その表の [操作] 列に、そのブランチを削除できない理由が示されています。

削除したブランチは復元できません。ブランチを削除すると、Looker はブランチのローカル バージョンとリモート バージョンのブランチの両方を削除します。

ただし、そのブランチが別の Looker デベロッパーのものである場合、または他のデベロッパーがそのブランチをチェックアウトしている場合、それらのデベロッパーは依然としてローカル バージョンのブランチを保持します。Looker デベロッパーがローカル バージョンのブランチを commit して本番環境に push すると、ブランチのリモート バージョンが再び表示されます。これは、ブランチを復元する場合に役立ちます。それ以外の場合は、ブランチを削除するときに、他のすべての Looker デベロッパーは同じブランチを削除して、誰かがリモートに push して誤ってブランチを再表示しないようにする必要があります。

プロジェクトから 1 つ以上の Git ブランチを削除するには、左側のアイコンメニューから [設定] アイコンをクリックし、[ブランチ管理] タブを選択して [Project Settings] ページに移動します。[Branch Management] タブでは、次の 2 つの方法でブランチを削除できます。

1. 複数のブランチを削除するには、各ブランチ チェックボックスをオンにして [Delete Selected Branches] をクリックします。
2. ブランチ名の横にある [Delete] をクリックして、ブランチを 1 つ削除します。

Looker での Git コマンドの実行

Looker には、Git サービスと統合するインターフェースが組み込まれている。LookML IDE では、Git の右上に次のボタンが表示されます。

[Git] ボタンには、変更を行って本番環境にデプロイする段階に応じて、さまざまなオプションが表示されます。通常は、ボタンに表示されるオプションが次のアクションに進むための最適なガイドになります。

デベロッパー ブランチが本番環境ブランチと同期している場合、[Up to Date] メッセージが表示されます。

プロジェクトを Git に構成すると、IDE の Git Actions パネルに Git のその他のコマンドが表示されます。

[Git Actions] パネルで使用できるコマンドは、変更を行って本番環境にデプロイするプロセスの場所によって異なります。

本番環境に変更を適用する

Looker とデフォルトの Looker Git 統合により、Looker は以下の Git ワークフローを通じてデベロッパーにメッセージを表示します。

• デベロッパーの現在の開発ブランチに変更を commitする（プロジェクトがデプロイ前にテストを要求するように設定されている場合はデータテストを実行します）
• 開発ブランチを本番環境ブランチにマージする（デフォルトでは master）。
• Looker エンドユーザーに提示される Looker 本番環境への本番環境ブランチのデプロイ

つまり、デフォルトの Git 統合では、すべてのデベロッパーが変更を master というブランチにマージし、master ブランチでの最新の commit が Looker の本番環境に使用されることを意味します。

高度な Git 実装では、このワークフローをカスタマイズできます。

• 開発者が Looker IDE を介して変更を統合できるようにする代わりに、デベロッパーに Git 本番環境ブランチの pull リクエストを送信させることができます。詳細については、プロジェクトのバージョン管理の設定に関するドキュメントをご覧ください。
• [Git Production Branch Name] フィールドを使用して、Looker がターゲットのブランチとして使用する Git リポジトリのブランチと、Looker デベロッパーがマージするブランチを指定できます。詳細については、プロジェクトのバージョン管理の設定に関するドキュメントをご覧ください。
• Looker の本番環境にデプロイする別の commit SHA またはタグ名を指定するには、本番環境ブランチで最新の commit を使用する代わりに、高度なデプロイモードを使用できます。（別のブランチから commit をデプロイする場合は、高度なデプロイモードの Webhook または API エンドポイントを使用します）。詳細については、高度なデプロイモードのドキュメントをご覧ください。

このセクションで説明する選択肢の代わりに [Git の構成] ボタンが表示されている場合は、最初にプロジェクト用に Git を設定する必要があります。

コミットされていない変更の表示

LookML IDE には複数のインジケーターがあります。開発モードを使用していて、 commit されていない変更がある場合、LookML の編集と検証に関するドキュメント ページの追加、変更、削除をマーキングするのセクションで説明したとおりです。

[Git Actions] パネルの [View Uncommitted Changes] オプションを使用すると、すべてのファイルの違いの概要を確認できます。

[プロジェクトへの commit されていない commit] ウィンドウに、すべてのプロジェクト ファイルに含まれる commit されていない保存済みの変更内容の概要が表示されます。Looker では、変更のたびに次の情報が表示されます。

• 置換対象のファイルの名前と追加されたファイルの名前。
  • 置き換えられたファイルの名前（--- で指定）と追加されたファイルの名前（+++ で示されます）。多くの場合、同じファイルの異なるバージョンが表示されることがあります。版には --- a/ と +++ b/ で識別されます。
  • 削除されたファイルは null ファイル（+++ /dev/null）を置き換えるファイルとして表示されます。
  • 追加されたファイルは null ファイル（--- /dev/null）を置き換えるファイルとして表示されます。
• 変更が始まる行番号。
  たとえば、-101,4 +101,4 は、ファイルの 101 行目から 4 行が削除され、4 行が追加されたことを示します。削除されたファイルが 20 行ある場合は -1,20 +0,0 と表示され、ファイルの先頭の 20 行が削除されて 0 行に置き換えられます。
• 更新されたテキスト:
  • 削除された行は赤色で表示されます。
  • 追加した行は緑色で表示されます。

単一のファイルの違いの概要は、ファイルのメニューから [変更を表示] オプションを選択して取得することもできます。

変更を commit する

LookML プロジェクトに変更を加え、保存した後、LookML の検証を求められることがあります。

これが必要かどうかは、プロジェクトのコード品質の設定によって異なります。コンテンツ バリデータの詳細については、LookML の検証のドキュメントをご覧ください。

ローカル ブランチを最後に更新した後に、別のデベロッパーが本番環境ブランチに変更を行った場合、Looker はそれらの更新を本番環境ブランチから pull する必要があります。

プロジェクトで高度なデプロイモードが有効になっている場合、このボタンには「プライマリ ブランチから pull」と表示されます。

変更を保存して（必要に応じて LookML の警告やエラーを修正し）、必要に応じて本番環境から pull すると、Git ボタンに次のメッセージが表示されます。

必要に応じて、 commit する前にコミットされていない変更を確認できます。

変更を commit する準備ができたら、[Commit Changes &Push;] ボタンを使用して、現在のブランチに変更を commit します。次のウィンドウが開き、追加、変更、削除されたファイルが一覧で表示されます。

変更内容を簡単に説明するメッセージを入力し、同期に含めたくないファイルはチェックボックスをオフにします。[Commit] をクリックして変更を commit します。

ビルドされていない PDT の確認

プロジェクト内の PDT に変更を加えた場合は、本番環境にデプロイするときにすべての PDT をビルドすることをおすすめします。そうすれば、テーブルを本番環境バージョンとしてすぐに使用できるようになります。変更をデプロイする前に、[Project Health] パネルでプロジェクトで未ビルドの PDT を確認できます。Project Health アイコンをクリックし、[Validate PDT Status] ボタンをクリックします。

LookML プロジェクトのビルドされていない PDT のチェックと、開発モードでの派生テーブルの操作について詳しくは、Looker の派生テーブルのページをご覧ください。

データテストの実行

プロジェクトに、LookML モデルのロジックを検証するためのデータテストが含まれる場合があります。プロジェクトでのデータテストの設定については、test パラメータのドキュメント ページをご覧ください。

データテストを実行するには、開発モードになっている必要があります。開発モードに入った後、プロジェクトのデータテストを開始するには、いくつかの方法があります。

1. プロジェクト設定でファイルを本番環境にデプロイする前にデータテストに合格する必要がある場合、IDE はcommitcommit 後にテストを実行します。これにより、テストを定義するファイルに関係なく、プロジェクトのすべてのテストが実行されます。変更を本番環境にデプロイする前に、データテストに合格する必要があります。
2. [Project Health] パネルの [Run Data Tests] ボタンをクリックします。これにより、テストを定義するファイルに関係なく、プロジェクト内のすべてのデータテストが実行されます。
3. ファイルのメニューから [LookML テストを実行] オプションを選択します。これにより、現在のファイルで定義されているテストのみが実行されます。

データテストを実行すると、[Project Health] パネルに進行状況と結果が表示されます。

• テストテストのアサーションが、テストのクエリの各行で true の場合、データテストは合格です。テストのアサーションとクエリの設定について詳しくは、test パラメータのドキュメント ページをご覧ください。
• データテストが失敗した場合は、[プロジェクトの状態] パネルに、テストが失敗した理由、テストでモデルのロジックにエラーが見つかった場合、テスト自体が無効であったかどうかの情報が表示されます。
• データテストの結果で、データテストの名前をクリックして LookML に直接移動してデータテストを行うか、[Explore Query] ボタンをクリックしてデータテストで定義されたクエリを含む Explore を開きます。

本番環境にデプロイする

ブランチに変更を commit すると、変更内容をプライマリ ブランチにマージするよう求める Looker IDE のプロンプトが表示されます。IDE に表示されるプロンプトの種類は、プロジェクトの構成によって異なります。

• プロジェクトが高度なデプロイモード用に構成されている場合、変更をプライマリ ブランチにマージするよう求めるプロンプトが IDE に表示されます。コミットをマージしたら、deploy 権限を持つ Looker デベロッパーは、Looker IDE Deployment Manager を使用するか、Webhook または API エンドポイントを使用して commit を本番環境にデプロイできます。
• pull リクエストを使用して Git 統合用にプロジェクトが構成されている場合、Git プロバイダのインターフェースを使用して pull リクエストを開くように求めるプロンプトが表示されます。
• それ以外の場合は、デフォルトの Looker Git 統合で deploy 権限が付与されている場合、Looker IDE で変更を本番環境ブランチにマージし、変更内容を本番環境バージョンの Looker インスタンスにデプロイするように求められます。

高度なデプロイモード

デフォルトの Looker Git 統合では、Looker デベロッパーは変更を開発ブランチに commit してから、開発ブランチを本番環境ブランチにマージします。その後、Looker 環境にデプロイすると、Looker は本番環境ブランチで最新の commit を使用します。（デフォルトの Git ワークフローと、高度な Git 実装のその他のオプションについては、このページの本番環境への変更を取得するをご覧ください）。

Looker 環境の本番環境ブランチで常に最新の commit を使用したくない場合は、deploy 権限を持つデベロッパーが、高度なデプロイモードを使用して Looker 環境に使用する commit を正確に指定できます。これは、各環境で異なるバージョンのコードベースを参照するマルチ環境のデベロッパー ワークフローで役立ちます。また、1 つ以上のデベロッパーや管理者が、本番環境にデプロイされる変更をより詳細に制御できるようになります。

高度なデプロイモードが有効の場合、Looker IDE には変更を本番環境にデプロイするよう求めるプロンプトがデベロッパーに表示されません。代わりに、変更を本番環境ブランチにマージするよう求めるプロンプトが表示されます。ここから変更をデプロイする方法は次のとおりです。

• Looker IDE 内で Deployment Manager を使用する
• Webhook をトリガーする
• API エンドポイントの使用

詳細については、高度なデプロイモードのドキュメントをご覧ください。

変更による影響を確認する

組織で変更を利用できるようにした後、コンテンツ検証を使用して、ダッシュボードや保存済みの Look が無効化されていないことを確認できます。問題があれば、修正することができます。

一般的な問題の処理

モデルの開発中に次のことが必要になることがあります。

• 変更を破棄する

  データ モデリングの変更を破棄したほうがよい場合もあります。保存されていない場合は、ページを更新するか、このページから移動して警告プロンプトを受け入れます。変更を保存した場合は、確定されていない変更を元に戻すセクションの手順に沿って、 commit されていない変更を元に戻すことができます。

• 他のデベロッパーとのマージの競合を処理する&#39、作業

  複数のデベロッパーがデータモデルに取り組んでいる場合、Git は通常、状況に対応します。ただし、Git では、マージの競合の解決に人間が関与する場合があります。

フィールド名の変更など、一部の変更は、既存のダッシュボードと Look に影響する可能性があります。前述のとおり、組織で変更を利用できるようにした後、コンテンツ検証を使用してコンテンツを確認し、問題があれば修正できます。

未確定の変更を元に戻す

個人用開発ブランチで作業しているときに、デプロイしない場合は、 commit していない変更内容を元に戻すことができます。プロジェクト内のすべてのファイルに対して commit されていない変更を元に戻すことも、1 つのファイルの変更のみを元に戻すこともできます。

すべてのファイルについて、commit されていない状態を元に戻すには:

1. [Git Actions] パネルの [Replace to...] オプションをクリックします。
2. 元に戻すオプションを選択します。
   • commit されていない変更のみを元に戻すには、commit されていない変更を元に戻すを選択します。[変更を表示] リンクをクリックして、元に戻す変更を確認することもできます。
   • コミットされていない変更やコミットされた変更など、すべての変更を元に戻すには、[本番環境に戻す] を選択します。
3. 元に戻すには、[確認] をクリックします。

単一ファイルのコンテンツの追加、削除を元に戻すには、ファイル メニューから [変更を元に戻す] オプションを選択してください。

ファイル名を変更すると、基本的には元のファイルを削除し、新しい名前で新しいファイルを作成します。これには複数のファイルが含まれているため、[元に戻す] オプションを使用してファイルの名前の変更を元に戻すことはできません。ファイル名の変更を元に戻すには、[Git Actions] パネルの [Rename to...] オプションを使用します。

また、削除したファイルは IDE ファイル ブラウザに表示されなくなり、ファイルの削除を元に戻す場合は、[Git Actions] パネルの [Return to...] オプションを使用します。

マージの競合の解決

通常、Git は新しい変更を本番環境バージョンの LookML ファイルに自動的にマージできます。Git で保持する変更を決定できない場合、マージの競合が発生します。これは通常、最後に pull してから別のデベロッパーが変更を行い、同じ領域で変更を行った場合に発生します。コード内にマージの競合がある場合は、変更を commit し本番環境から pull した後、Looker で警告が表示されます。

Looker で merge-conflict 警告が表示されたら、さらに変更を加える前にマージ競合を解決することをおすすめします。マージの競合を本番環境に push すると解析エラーが発生し、データ探索ができなくなる可能性があります。上級 Git ユーザーで、変更を push して続行する場合は、[Don't Resolve] ボタンをクリックします。

LookML ファイル自体では、競合のある行は次のようになります。

<<<<<<< HEAD
Your code
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
Production code
>>>>>>> branch 'master'

Looker では、マージの競合を示す以下のマージ マーカーが表示されます。

• <<<<<<< HEAD は競合する行の先頭を表します。
• >>>>>>> branch 'master' は、競合する行の末尾を意味します。
• ======= は、各バージョンのコードを区切って比較します。

上記の例で、your code は commit した変更を表し、production code は Git が変更を自動的にマージできなかったコードを表します。

マージの競合を解決するには:

1. マージが競合するファイルを探します。Looker では、これらのファイルは赤色で表示されます。また、プロジェクトを検索して結合のマーカー（<<<< や HEAD）などのプロジェクトを検索し、プロジェクト内のすべての競合を検索することもできます。また、[Git Actions] パネルに表示される統合の警告で [files] リンクをクリックすると、影響を受けるファイルを確認できます。
2. このファイル内で統合の競合が発生している行に移動し、保持しないテキストのバージョンを削除します。また、統合の競合を示すすべてのマーカーも削除します。

3. ファイルを保存し、マージの競合としてマークされている他のファイルに前述の手順を繰り返します。

   ヒント: マージ マーカーごとにプロジェクトを検索して、すべての競合マーカーが解決され、すべてのマージ マーカーが削除されたことを確認します。LookML ファイル内のマージ マーカーのインスタンスをすべて削除してください。これらのマーカーは解析エラーを引き起こし、ユーザーがデータを調査できない可能性があります。

4. すべてのマージの競合を解決し、プロジェクトからすべてのマージ マーカーを削除したら、変更を commit し、本番環境にデプロイします。

マージの競合が解決され、解決策が本番環境に push されたので、他のデベロッパーは本番環境から pull して通常どおり作業を続行できます。

Git ガベージ コレクション

Git ガベージ コレクションは、不要なファイルをクリーンアップし、ファイルのリビジョンを圧縮して Git リポジトリを最適化します。Git ガベージ コレクション（git gc）は、Looker インスタンスの更新または再起動時に自動的に実行されます。git gc が頻繁に実行されないように、Looker は前回の git gc から 30 日間待機してから、次回の再起動時に git gc を実行します。

まれに、git gc の実行時に Remote に変更を push したり、Remote にブランチを push しようとすることがあります。Looker でエラーが表示された場合は、1 ～ 2 分待ってからもう一度変更を push してみてください。