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

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

Looker では、変更の記録とファイルのバージョン管理のために、Git を使用します。 各 LookML プロジェクトは Git リポジトリに対応しており、各デベロッパー ブランチは Git ブランチに関連付けられています。

Looker は、多くの Git プロバイダ（GitHub、GitLab、Bitbucket など）と連携するように構成できます。Looker プロジェクト用の Git の設定については、Git 接続の設定とテストのドキュメント ページをご覧ください。

Git ブランチの操作

Git の主な利点の 1 つは、Looker のデベロッパーがブランチ（ファイル リポジトリの分離されたバージョン）で作業できる点です。他のユーザーに影響を与えることなく、開発とテストを行うことができます。Looker のデベロッパーは、Development Mode で常に Git ブランチを使用しています。

Git のもう 1 つの主な特長は、他のデベロッパーとの共同作業のしやすさです。ブランチを作成し、必要に応じて変更を行うと、他のデベロッパーがそのブランチに切り替えて、ブランチを確認または変更できます。別のデベロッパーがブランチへの変更を commit した場合、Looker には [リモートの変更をプル] ボタンが表示されます。追加の変更を行う前に、commit された変更をブランチに pull する必要があります。

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

個人用のブランチ

初めて Development Mode に入ると、Looker によって個人の Git ブランチが自動的に作成されます。dev- で始まり、ユーザー名が含まれる個人用ブランチ。

個人用ブランチはユーザー固有のもので、削除できません。個人用ブランチは他のすべてのデベロッパーに対して読み取り専用になります。プロジェクトで他のデベロッパーとコラボレーションしている場合は、新しいブランチを作成することで、そのブランチに切り替えたり、変更を提供したりできます。

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

新しい Git ブランチの作成

単純な修正を行っていて、他のデベロッパーとコラボレーションしていない場合は、通常、個人用ブランチが作業に適しています。個人用のブランチを使用してすばやく更新を行い、変更を commit して本番環境に push できます。

ただし、個人用ブランチに加えて、新しい Git ブランチを作成することが必要になる場合もあります。次のような場合には新しい Git ブランチが有効です。

• 他のデベロッパーとコラボレーションしている。個人用ブランチは他のデベロッパーには読み取り専用で、他のデベロッパーとコラボレーションする場合は、他のデベロッパーがブランチに書き込めるように新しい Git ブランチを作成する必要があります。他のユーザーと共同編集している場合は、作業を再開するたびに変更を pull するようにしてください。これにより、作業を続行する前に、すべてのデベロッパーから最新のアップデートを入手できます。
• 一度に複数の機能セットを扱う。 大きなプロジェクトの最中に、軽微な問題を解決したり、すぐに修正したりする必要がある場合があります。この場合、表示しているブランチに変更を commit してから、別のブランチを作成するか、別のブランチに切り替えて別の機能セットで作業できます。新しいブランチで問題を修正し、そのブランチの変更を本番環境にデプロイしてから、元のブランチで作業を再開できます。

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

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

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

1. Development Mode がオンになっていることを確認します。

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

   

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

4. [View Branches] プルダウン メニューを選択します。

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

   

6. [新しいブランチ] ウィンドウで、ブランチの名前を入力します。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 branch] プルダウン メニューを選択します。
3. 切り替え先のブランチを選択するには、メニューで選択するか、検索ボックスにブランチ名を入力します。ブランチ名の検索では大文字と小文字が区別されません。たとえば、「DEV」を検索すると、「dev」、「DEV」、「Dev」などを含む名前を持つすべてのブランチを表示できます。

Git ブランチの管理

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

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

1. [New Branch] ボタンを選択して新しいブランチを作成します。詳細については、このページの新しい Git ブランチの作成セクションをご覧ください。
2. 検索バーでブランチ名を検索します。
3. [Refresh] ボタンを選択して、テーブルを更新します。
4. 列名を選択してテーブルを並べ替えます。

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

• 名前: Git ブランチの名前。Looker デベロッパーの個人用ブランチは、dev- で始まり、デベロッパーの姓と名が含まれます。
• ステータス: ブランチのローカル バージョンとブランチのリモート バージョンの違い。たとえば、ステータスが 3 commits behind の場合、ブランチのローカル バージョンは、3 回の commit 分、ブランチのリモート バージョンより遅れています。Looker は常にリモート バージョンのマスターを使用するため、[ブランチの管理] タブには、マスター ブランチのローカル バージョンのステータスは表示されません。マスター ブランチは常に最新状態であると考えられます。
• Last Updated: Looker デベロッパーがブランチを commit した時間。
• Actions: ブランチを削除するボタン、またはブランチを削除できない理由。

Git ブランチの削除

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

• マスター ブランチ
• 現在のブランチ
• Looker デベロッパーの個人用ブランチ

テーブルでは、ブランチには [Delete] ボタンはありません。テーブルの [Action] 列には、ブランチを削除できない理由が表示されます。

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

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

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

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

Looker での Git コマンドの実行

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

Git ボタンには、変更と本番環境へのデプロイにおいてどの段階にあるかに応じて異なるオプションが表示されます。一般的に、ボタンに表示されるオプションは、次のアクションへの最適なガイドです。

デベロッパー ブランチが本番環境ブランチと同期している場合、Git ボタンには「Update to Date」メッセージが表示され、選択できません。

プロジェクトが Git 用に構成されたら、[Git Actions] ボタンを選択して [Git Actions] パネルを開きます。

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

本番環境に対する変更の取得

Looker のデフォルトの Git 統合では、Looker は次の Git ワークフローに沿ってデベロッパーにプロンプトを表示します。

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

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

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

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

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

commit されていない変更の表示

LookML IDE には、デベロッパー モードで実行中に commit されていない変更がある場合に表示されるインジケーターがあります。詳しくは、LookML の編集と検証のドキュメント ページの追加、変更、削除のマークセクションをご覧ください。

すべてのファイルの差分の概要を取得するには、[Git Actions] パネルから [View Uncommitted Changes] オプションを選択します。

Looker の [Uncommitted Changes to Project] ウィンドウには、プロジェクトのすべてのファイルで、commit されずに保存されたすべての変更の概要が表示されます。Looker は変更ごとに次の内容を表示します。

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

1 つのファイルの差分の概要を表示するには、ファイルのメニューから [View Changes] オプションを選択します。

変更を commit する

LookML プロジェクトに変更を加えて保存した後、IDE で LookML の検証が必要になる場合があります。このシナリオでは、Git ボタンに「Validate LookML」というテキストが表示されます。

これが必要かどうかは、プロジェクトのコード品質の設定によって異なります。Content Validator の詳細については、LookML を検証するのドキュメント ページを参照してください。

最後にローカル ブランチを更新した後に、別のデベロッパーが本番環境ブランチに変更を加えた場合、Looker は本番環境ブランチからそれらの更新を pull する必要があります。このシナリオでは、Git ボタンに「Pull from Production」というテキストが表示されます。

プロジェクトで高度なデプロイモードが有効になっている場合、代わりに Git ボタンに [Pull from Primary Branch] というテキストが表示されます。

変更を保存し（必要に応じて、LookML の警告やエラーを修正して）、（必要に応じて）本番環境から pull すると、Git ボタンに「Commit Changes & Push」というテキストが表示されます。

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

変更を commit する準備ができたら、Git ボタンを使用して、変更を現在のブランチに commit します。Looker に [Commit] ダイアログ ボックスが表示され、追加、変更、削除されたファイルが一覧表示されます。

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

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

プロジェクト内の PDT に変更を加えた場合は、本番環境にデプロイするときにすべての PDT を作成することをおすすめします。これにより、本番環境バージョンとしてテーブルをすぐに使用できます。プロジェクト内の PDT のステータスを確認するには、[プロジェクトの状態] アイコンを選択して、[プロジェクトの状態] パネルを開き、[PDT のステータスを検証] ボタンを選択します。

LookML プロジェクトでビルドされていない PDT を確認する方法と、開発モードで派生テーブルを操作する方法については、Looker の派生テーブルのドキュメント ページをご覧ください。

データテストの実行

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

注: デフォルトでは、新しい LookML プロジェクトはデータテストに合格する必要があります。プロジェクトに 1 つ以上の test パラメータがある場合は、プロジェクトを本番環境にデプロイする前にデータテストに合格する必要があります。

プロジェクトにデータテストが含まれていて、Development Mode を使用している場合は、いくつかの方法でプロジェクトのデータテストを開始できます。

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

データテストを実行すると、[プロジェクトの状態] パネルに進行状況と結果が表示されます。

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

本番環境にデプロイする

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

• プロジェクトが高度なデプロイモードで構成されている場合、IDE は変更をプライマリ ブランチにマージするように求めるプロンプトを表示します。commit を統合した後は、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 エンドポイント を使用する

  注: 高度なデプロイモードが有効になっているプロジェクトの場合、プロジェクトが本番環境にデプロイされたことがない場合は、Looker IDE で Deployment Manager を使用して、本番環境への初期デプロイを行う必要があります。高度なデプロイモードでプロジェクトを初期デプロイする場合、API または Webhook は使用できません。本番環境への初期デプロイ後（高度なデプロードを使用しない初期デプロイであっても）、Webhook または API を使用して、高度なデプロイモードを使用して本番環境に後続の変更をデプロイできます。

詳しくは、高度なデプロイモードのドキュメント ページをご覧ください。

変更による影響の確認

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

一般的な問題への対応

モデルに関する作業を行う際には、次を行う必要があります。

• 変更を破棄する

  データモデルの変更を破棄する場合もあります。まだ保存されていない場合は、単に更新するか、ページから移動して、警告プロンプトを受け入れます。変更を保存している場合は、commit していない変更を元に戻すで説明されているように、commit されていない変更を元に戻すことができます。

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

  データモデルに対して複数のデベロッパーが作業している場合、通常は Git が状況に対処します。ただし、Git ではマージの競合を解決する担当者が必要になります。

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

commit されていない変更を元に戻す

個人用開発ブランチで作業を行う際に、デプロイしたくない場合は、保存した commit されていない変更を元に戻すことができます。プロジェクト内のすべてのファイルの commit されていない変更を元に戻すか、1 つのファイルの変更だけを元に戻すことができます。

すべてのファイルの commit されていない変更を元に戻すには:

1. [Git アクション] パネルで [元に戻す] オプションを選択します。
2. 元に戻すオプションを選択します。
   • commit していない変更のみを元に戻すには、[Revert uncommitted changes] を選択します。[変更を表示] リンクをクリックして、元に戻す変更を表示することもできます。
   • commit されていない変更や commit された変更を含むすべての変更を元に戻すには、[プロダクションに戻す] を選択します。
3. 元に戻す処理を完了するには、[確認] を選択します。

1 つのファイルの内容の追加または削除を元に戻すには、ファイルのメニューから [変更内容を元に戻す] オプションを選択します。

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

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

マージの競合の解決

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

Looker で結合の競合という警告が表示されたら、さらに変更を行う前に結合の競合を解決することをおすすめします。結合の競合を本番環境に 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 の実行中に変更のリモートへの push またはリモートへのブランチの push が試行されます。Looker でエラーが表示された場合は、1～2 分待ってから再度変更を push してみてください。