Versionsverwaltung und Bereitstellung

Auf dieser Seite wird davon ausgegangen, dass für Ihr Projekt bereits die Versionsverwaltung eingerichtet ist. Wenn die Schaltfläche Git konfigurieren anstelle der auf dieser Seite beschriebenen Optionen angezeigt wird, müssen Sie zuerst Git für Ihr Projekt einrichten.

Git-Integration für Versionsverwaltung

Looker verwendet Git, um Änderungen aufzuzeichnen und Dateiversionen zu verwalten. Jedes LookML-Projekt entspricht einem Git-Repository und jeder Entwicklerzweig entspricht einem Git-Zweig. Git-Repositories werden häufig als repos bezeichnet.

Looker verwendet im Allgemeinen GitHub für die Verwaltung von Quelldateien in LookML. Looker kann jedoch auch so konfiguriert werden, dass es auch mit anderen Git-Anbietern wie GitLab, Bitbucket oder einem beliebigen Git-Server zusammenarbeitet, der einen SSH-Schlüssel für die Authentifizierung verwenden kann.

GitHub unterstützt keine Kontopasswörter für die Authentifizierung von Git-Vorgängen auf github.com. Weitere Informationen finden Sie im GitHub-Blogpost. Wenn Sie ein Looker-Projekt über HTTPS mit GitHub verbinden möchten, verwenden Sie die Entwicklereinstellungen in GitHub, um ein persönliches Zugriffstoken zu erstellen. Für vorhandene Looker-Projekte, die über HTTPS eine Verbindung zu GitHub herstellen, setzen Sie Ihre Git-Verbindung mit einem persönlichen Zugriffstoken von GitHub zurück.

Ein Looker-Projekt verwendet bei Ihrem Git-Anbieter nur ein Konto für alle Git-Interaktionen. Informationen zum Einrichten von Git finden Sie auf der Dokumentationsseite Looker in Git einbinden. Für jedes Looker-Projekt wird die gesamte Entwicklung von allen Looker-Entwicklern über dieses eine Git-Konto abgewickelt. Das bedeutet, dass Looker-Entwickler keine eigenen Konten bei Ihrem Git-Anbieter haben müssen, es sei denn, Ihre Looker-Instanz ist mit einer der zusätzlichen Git-Integrationsoptionen eingerichtet. In diesem Fall benötigt ein Looker-Entwickler ein Git-Konto, um externe Links zu Ihrem Git-Anbieter zu öffnen oder eine Pull-Anfrage zu erstellen.

Mit Git-Zweigen arbeiten

Einer der Hauptvorteile von Git besteht darin, dass ein Looker-Entwickler in einem Branch arbeiten kann, einer isolierten Version eines Datei-Repositorys. Sie können Anwendungen entwickeln und testen, ohne dass sich dies auf andere Nutzer auswirkt. Als Entwickler in Looker verwenden Sie immer einen Git-Zweig, wenn Sie sich im Entwicklungsmodus befinden.

Eine weitere wichtige Funktion von Git ist die Zusammenarbeit mit anderen Entwicklern. Sie können einen Branch erstellen und bei Bedarf Änderungen vornehmen. Anschließend können andere Entwickler zu diesem Zweig wechseln, um sich den Zweig anzusehen oder Änderungen daran vorzunehmen. Wenn ein anderer Entwickler Änderungen am Zweig vorgenommen hat, zeigt Looker die Schaltfläche Remote-Änderungen abrufen an. Sie sollten diese Commit-Änderungen in den Branch abrufen, bevor Sie weitere Änderungen vornehmen.

Sie können auch eine Verzweigung löschen, mit Ausnahme der Hauptzweig, Ihrer aktuellen Zweig oder der eines Entwicklers.

Persönliche Äste

Wenn Sie zum ersten Mal in den Entwicklungsmodus wechseln, erstellt Looker automatisch Ihren persönlichen Git-Zweig. Ihr persönlicher Zweig beginnt mit dev- und enthält Ihren Namen:

Ihr persönlicher Zweig ist nicht gelöscht. Ihr persönlicher Zweig ist für alle anderen Entwickler schreibgeschützt. Wenn Sie mit anderen Entwicklern an einem Projekt zusammenarbeiten, können Sie einen neuen Branch erstellen, damit auch andere Nutzer zu diesem Branch wechseln und Änderungen vornehmen können.

TIPP: Sie können keine Änderungen an der persönlichen Filiale eines anderen Entwicklers vornehmen. Wenn Sie eine Arbeit in einer persönlichen Zweigstelle erstellen möchten, erstellen Sie eine neue Filiale in der Filiale.

Neuen Git-Zweig erstellen

Wenn Sie an einer einfachen Lösung arbeiten und nicht mit anderen Entwicklern zusammenarbeiten, ist Ihre persönliche Filiale normalerweise ein guter Ort. Sie können Ihre persönlichen Zweige verwenden, um schnelle Aktualisierungen vorzunehmen, die Änderungen zu übernehmen und sie für die Produktion bereitzustellen.

Möglicherweise möchten Sie jedoch zusätzlich zu Ihrem persönlichen Zweig neue Git-Zweige erstellen. Ein neuer Git-Zweig ist in folgenden Situationen sinnvoll:

  • Sie arbeiten mit anderen Entwicklern zusammen. Da Ihr persönlicher Zweig für andere Entwickler schreibgeschützt ist, sollten Sie einen neuen Git-Zweig erstellen, damit andere Entwickler in den Zweig schreiben können, wenn Sie mit anderen zusammenarbeiten möchten. Denken Sie daran, jedes Mal Änderungen vorzunehmen, wenn Sie mit anderen zusammenarbeiten. So erhalten Sie die neuesten Updates aller Entwickler, bevor Sie mit der Arbeit fortfahren.
  • Sie arbeiten an mehreren Funktionen auf einmal. Manchmal sind Sie mitten in einem größeren Projekt, möchten aber ein kleineres Problem beheben oder eine schnelle Lösung vornehmen. In diesem Fall können Sie die Änderungen in einen Zweig übernehmen und dann einen neuen Zweig erstellen oder zu einem anderen Satz von Funktionen wechseln. Sie können die Korrekturen im neuen Branch vornehmen und dann die Änderungen dieses Branch in der Produktion bereitstellen, bevor Sie die Arbeit im ursprünglichen Branch fortsetzen.

Bevor Sie einen neuen Zweig erstellen:

  • Wenn es bei Ihrer aktuellen Verzweigung einen Zusammenführungskonflikt gibt, müssen Sie den Konflikt lösen, bevor Sie einen neuen Zweig erstellen können.
  • Wenn für den aktuellen Zweig Änderungen nicht festgeschrieben sind, müssen Sie die Commits für die aktuelle Zweigstelle übernehmen, bevor Sie einen neuen Zweig erstellen.
  • Wenn Sie einen Zweig erstellen möchten, der aus einem vorhandenen Entwicklungszweig (und nicht aus dem Produktionszweig) erstellt werden kann, müssen Sie zuerst die neueste Version des Entwicklungszweigs abrufen. Wechseln Sie dazu zu diesem Entwicklungszweig und ziehen Sie dann Remote-Änderungen herunter, um Ihre lokale Version dieses Zweigs zu synchronisieren.

So erstellen Sie einen neuen Git-Zweig:

  1. Prüfen Sie, ob der Entwicklungsmodus aktiviert ist.

  2. Rufen Sie Ihre Projektdateien im Menü Entwickeln auf.

  3. Klicken Sie im Menü auf der linken Seite auf das Symbol Git, um den Bereich Git Actions zu öffnen.

  4. Klicken Sie auf das Drop-down-Menü Zweige anzeigen.

  5. Wählen Sie New Branch (Neuer Zweig) aus.

  6. Geben Sie im Fenster New Branch (Neuer Branch) einen Namen für den Branch ein. Beachten Sie, dass es Einschränkungen für Git-Zweignamen gibt. Informationen zu Benennungsanforderungen finden Sie auf dieser Seite unter Regeln für die Benennung eines Git-Zweigs.

  7. Klicken Sie auf das Drop-down-Menü Create from (Erstellen aus) und wählen Sie einen vorhandenen Branch als Ausgangspunkt für den neuen Branch aus.

  8. Klicken Sie auf Erstellen, um Ihren Zweig zu erstellen.

Alternativ können Sie Git-Zweige auf der Seite Projekteinstellungen auf dem Tab Zweigverwaltung erstellen.

Regeln für die Benennung eines Git-Zweigs

Looker verwendet die von Git festgelegten Branch-Namenskonventionen.

Git-Zweignamen dürfen nicht verwendet werden:

  • Enthält ein Leerzeichen
  • Enthält einen doppelten Punkt: ..
  • Enthält einen umgekehrten Schrägstrich: \
  • Enthält die Sequenz: @{
  • Enthält ein Fragezeichen: ?
  • Eckige Klammer offen: [
  • Ein ASCII-Steuerzeichen enthalten: ~, \^ oder :
  • Beginne mit einem Punkt: .
  • Beginnen Sie mit dem Präfix dev- (reserviert für die persönlichen Zweige von Looker-Entwicklern)
  • Mit einem Schrägstrich enden: /
  • Mit der Erweiterung enden: .lock

Außerdem darf der Zweigname nur dann ein Sternchen (*) enthalten, wenn das Sternchen eine ganze Pfadkomponente (z. B. foo/* oder bar/*/baz) darstellt. In diesem Fall wird es als Platzhalter und nicht als Teil des tatsächlichen Zweignamens interpretiert.

Zu einem anderen Git-Zweig wechseln

Wenn es bei Ihrer aktuellen Verzweigung einen Zusammenführungskonflikt gibt, müssen Sie den Konflikt lösen, bevor Sie zu einem anderen Zweig wechseln können.

Wenn für die aktuelle Vertretung nicht festgeschriebene Änderungen vorliegen, können Sie auch erst dann zu einer vorhandenen Verzweigung wechseln, wenn Sie für die aktuelle Verzweigung die Änderungen per Commit übertragen haben.

So wechseln Sie zu einem anderen Git-Zweig:

  1. Rufen Sie im Projekt den Bereich Git Actions (Git-Aktionen) auf, indem Sie im Menü auf der linken Seite auf das Symbol Git klicken.
  2. Klicken Sie im Bereich Git Actions (Git-Aktionen) auf das Drop-down-Menü „Git-Zweig“ neben dem Namen Ihres aktuellen Git-Zweigs.
  3. Wählen Sie den Zweig aus, zu dem Sie wechseln möchten, indem Sie ihn im Menü auswählen oder den Namen des Zweigs in das Suchfeld eingeben. Bei der Suche nach Zweignamen wird die Groß- und Kleinschreibung nicht berücksichtigt. Sie können beispielsweise nach „DEV" suchen und sich alle Zweige mit Namen ansehen, die „dev“ und „DEV“ enthalten.

Git-Zweige verwalten

Auf dem Tab Branch Management der Seite Projekteinstellungen wird eine Tabelle aller Git-Zweige für das Looker-Projekt angezeigt. Um den Tab Branch Management zu öffnen, gehen Sie zur Seite Project Settings (Projekteinstellungen), indem Sie im Menü auf der linken Seite auf das Symbol Settings (Einstellungen) klicken und den Tab Branch Management (Branch-Verwaltung) auswählen.

Auf dem Tab Branchenverwaltung können Sie Folgendes tun:

  1. Erstellen Sie einen neuen Branch, indem Sie auf die Schaltfläche New Branch (Neuer Branch) klicken. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Neuen Git-Zweig erstellen.
  2. Suchen Sie in der Suchleiste nach Zweignamen.
  3. Aktualisieren Sie die Tabelle, indem Sie auf die Schaltfläche Aktualisieren klicken.
  4. Sie können die Tabelle sortieren, indem Sie auf einen Spaltennamen klicken.

Die Tabelle enthält die folgenden Informationen:

  • Name: Name des Git-Zweigs. Looker-Entwickler, die persönliche Zweige beginnen, beginnen mit dev- und enthalten den Vor- und Nachnamen des Entwicklers.
  • Status: Die Differenz zwischen Ihrer lokalen Version des Zweigs und der Remote-Version des Zweigs. Der Status 3 commits behind bedeutet beispielsweise, dass sich Ihre lokale Version des Zweigs 3 Commits hinter der Remote-Version des Zweigs befindet. Da Looker immer die Remote-Version des Masters verwendet, wird auf dem Tab Branch Management der Status der lokalen Version des Master-Branch nicht angezeigt. Der Master-Zweig kann immer als aktuell betrachtet werden.
  • Zuletzt aktualisiert: Zeit seit dem Commit eines Looker-Entwicklers für den Branch.
  • Aktionen: Schaltfläche zum Löschen des Zweigs oder Grund, aus dem der Zweig nicht gelöscht werden kann.

Git-Zweige löschen

Über den Tab Branchenverwaltung können Sie Zweige löschen, bei denen in der Tabelle die Schaltfläche Löschen angezeigt wird. Sie können die folgenden Zweige nicht löschen:

In der Tabelle haben diese Zweige keine Schaltfläche Löschen. Stattdessen wird in der Spalte Aktion der Grund angezeigt, warum der Zweig nicht gelöscht werden kann.

Sie können einen Zweig nicht wiederherstellen, nachdem er gelöscht wurde. Wenn Sie einen Zweig löschen, entfernt Looker sowohl Ihre lokale Version des Zweigs als auch die Remote-Version des Zweigs.

Wenn der Zweig jedoch von einem anderen Looker-Entwickler erstellt wurde oder andere Entwickler den Zweig überprüft haben, haben diese Entwickler weiterhin ihre lokale Version des Zweigs. Wenn ein Looker-Entwickler Commits an seine lokale Version des Zweigs ausführt und ihn in die Produktion überträgt, wird wieder eine Remote-Version des Zweigs angezeigt. Das kann nützlich sein, wenn Sie den Branch wiederherstellen möchten. Wenn Sie einen Zweig löschen, sollten alle anderen Looker-Entwickler denselben Zweig löschen, damit er nicht von jemand anderem aus der Ferne wiederholt aufgerufen wird.

Um einen oder mehrere Git-Zweige aus Ihrem Projekt zu löschen, rufen Sie die Seite Projekteinstellungen auf, indem Sie im Menü auf der linken Seite auf das Symbol Einstellungen klicken und den Tab Branch Management auswählen. Auf dem Tab Branch Management können Sie Zweige auf zwei Arten löschen:

  1. Löschen Sie mehrere Zweige, indem Sie die Kästchen für Zweige auswählen und auf Ausgewählte Zweige löschen klicken.
  2. Wenn Sie einen Zweig löschen möchten, klicken Sie neben dem Namen des Zweigs auf Löschen.

Git-Befehle in Looker ausführen

Looker verfügt über eine integrierte Schnittstelle, die sich in Ihren Git-Dienst einbinden lässt. In der LookML IDE sehen Sie rechts oben eine Schaltfläche für Git:

Die Schaltfläche „Git“ zeigt unterschiedliche Optionen an, je nachdem, wo Sie Änderungen vornehmen und in der Produktion bereitstellen. Im Allgemeinen ist die Option auf der Schaltfläche die beste Anleitung für Ihre nächste Aktion.

Wenn Ihr Entwicklerzweig mit dem Produktionszweig synchronisiert ist, wird die Meldung Aktuell angezeigt:

Nachdem Ihr Projekt für Git konfiguriert wurde, zeigt die IDE den Bereich Git Actions mit zusätzlichen Git-Befehlen an:

Welche Befehle im Steuerfeld Git Actions verfügbar sind, hängt davon ab, wo Sie gerade Änderungen vornehmen und die Bereitstellung in der Produktion vornehmen.

Änderungen an der Produktion abrufen

Bei der Standardeinbindung von Looker Git werden Entwickler durch Looker über den folgenden Git-Workflow aufgefordert:

Das bedeutet, dass bei der standardmäßigen Git-Integration alle Entwickler ihre Änderungen in einem Zweig namens master zusammenführen. Das neueste Commit im master-Zweig wird für die Produktionsumgebung von Looker verwendet.

Für erweiterte Git-Implementierungen können Sie diesen Workflow anpassen:

  • Sie können Ihre Entwickler bitten, Pull-Anfragen für Ihren Git-Produktionszweig einzureichen, anstatt Entwicklern zu erlauben, ihre Änderungen über die Looker-IDE zusammenzuführen. Weitere Informationen finden Sie auf der Dokumentationsseite Einstellungen für die Projektversionssteuerung konfigurieren.
  • Sie können das Feld Git Production-Branch-Name verwenden, um festzulegen, welcher Zweig aus Ihrem Git-Repository von Looker als Zielzweig verwendet werden soll, mit dem Ihre Looker-Entwickler verbunden werden. Weitere Informationen finden Sie auf der Dokumentationsseite Einstellungen für die Projektversionssteuerung konfigurieren.
  • Sie können den erweiterten Bereitstellungsmodus verwenden, um ein anderes Commit-SHA- oder Tag-Namen für die Bereitstellung in Ihrer Looker-Produktionsumgebung anzugeben, anstatt den neuesten Commit für den Produktionszweig zu verwenden. (Wenn Sie ein Commit aus einem anderen Zweig bereitstellen möchten, können Sie den erweiterten Bereitstellungsmodus Webhook oder den API-Endpunkt verwenden.) Weitere Informationen finden Sie auf der Dokumentationsseite Erweiterter Bereitstellungsmodus.

Wenn anstelle der in diesem Abschnitt beschriebenen Optionen die Schaltfläche Git konfigurieren angezeigt wird, müssen Sie zuerst Git für Ihr Projekt einrichten.

Nicht per Commit übertragene Änderungen ansehen

Die LookML-IDE enthält mehrere Indikatoren, die im Entwicklungsmodus angezeigt werden und für die keine Commit-Änderungen vorliegen. Weitere Informationen finden Sie im Abschnitt Hinzufügen, Ändern und Löschen von Elementen auf der Dokumentationsseite zum Bearbeiten und Validieren von LookML.

Sie können eine Übersicht der Unterschiede für alle Dateien abrufen. Dazu verwenden Sie im Steuerfeld Git Actions (Git-Aktionen) die Option View Commited Commits (Nicht unterstützte Änderungen ansehen):

Im Fenster Nicht per Commit übertragene Änderungen am Projekt finden Sie eine Zusammenfassung aller nicht per Commit gespeicherten Änderungen in allen Projektdateien. Für jede Änderung wird in Looker Folgendes angezeigt:

  • Der Name der ersetzten Datei und der Name der hinzugefügten Datei.
    • Der Name der ersetzten Datei (gekennzeichnet mit ---) und der Name der hinzugefügten Datei (gekennzeichnet mit +++). In vielen Fällen werden hier möglicherweise verschiedene Versionen derselben Datei angezeigt. Die Überarbeitungen sind mit --- a/ und +++ b/ gekennzeichnet.
    • Gelöschte Dateien werden als Ersatz für eine Nulldatei (+++ /dev/null) angezeigt.
    • Hinzugefügte Dateien werden als Ersetzen einer Null-Datei angezeigt (--- /dev/null).
  • Die Zeilennummer, bei der die Änderung beginnt.
    Beispiel: -101,4 +101,4 gibt an, dass in der 101. Zeile der Datei 4 Zeilen entfernt und 4 Zeilen hinzugefügt wurden. Für eine gelöschte Datei mit 20 Zeilen würde -1,20 +0,0 bedeuten, dass in der ersten Zeile der Datei 20 Zeilen entfernt und durch Nullzeilen ersetzt wurden.
  • Aktualisierter Text:
    • Gelöschte Linien werden rot angezeigt.
    • Die hinzugefügten Zeilen werden grün dargestellt.

Sie können auch eine Zusammenfassung der Unterschiede für eine einzelne Datei abrufen. Wählen Sie dazu im Menü der Datei die Option Änderungen anzeigen aus:

Änderungen übernehmen

Nachdem Sie Änderungen an Ihrem LookML-Projekt vorgenommen und gespeichert haben, müssen Sie möglicherweise Ihr LookML validieren.

Ob dies erforderlich ist, hängt von der Codequalität in Ihrem Projekt ab. Weitere Informationen zum Inhaltsvalidierungstool finden Sie auf der Dokumentationsseite LookML.

Wenn ein anderer Entwickler Änderungen an der Produktionsfiliale vorgenommen hat, seit Sie Ihre lokale Zweigstelle zuletzt aktualisiert haben, müssen Sie diese Aktualisierungen für Looker aus der Produktionsfiliale abrufen:

Wenn für Ihr Projekt der erweiterte Bereitstellungsmodus aktiviert ist, wird diese Schaltfläche Aus dem primären Zweig abrufen angezeigt.

Nachdem Sie Ihre Änderungen gespeichert und ggf. LookML-Warnungen oder -Fehler behoben haben und gegebenenfalls die Migration aus der Produktion übernehmen, wird auf der Git-Schaltfläche die folgende Meldung angezeigt:

Bei Bedarf können Sie zuerst Ihre nicht per Commit übertragenen Änderungen prüfen, bevor Sie einen Commit durchführen.

Wenn Sie die Änderungen übernehmen möchten, klicken Sie auf die Schaltfläche Commit Changes &amp, um die Änderungen für den aktuellen Zweig zu übernehmen. Im folgenden Fenster werden die Dateien angezeigt, die hinzugefügt, geändert oder gelöscht wurden.

Geben Sie eine Nachricht ein, in der die Änderungen kurz beschrieben werden, und entfernen Sie die Häkchen bei allen Dateien, die nicht in die Synchronisierung aufgenommen werden sollen. Klicken Sie dann auf Commit durchführen, um die Änderungen zu übernehmen.

Suche nach nicht erstellten PDTs läuft

Wenn Sie Änderungen an PDT in Ihrem Projekt vorgenommen haben, wird empfohlen, alle PDTs bei der Bereitstellung in der Produktion zu erstellen, damit die Tabellen sofort als Produktionsversionen verwendet werden können. Bevor Sie Ihre Änderungen bereitstellen, können Sie Ihr Projekt im Bereich Projektzustand auf nicht erstellte PDTs prüfen. Klicken Sie auf das Symbol Projektzustand und dann auf die Schaltfläche PDT-Status validieren:

Weitere Informationen zum Suchen nach nicht erstellten PDTs in Ihrem LookML-Projekt und zum Arbeiten mit abgeleiteten Tabellen im Entwicklungsmodus finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

Datentests ausführen

Ihr Projekt kann Datentests enthalten, um die Logik Ihres LookML-Modells zu überprüfen. Informationen zum Einrichten von Datentests für Ihr Projekt finden Sie auf der Dokumentationsseite zum Parameter test.

Sie müssen sich im Entwicklungsmodus befinden, um Datentests ausführen zu können. Im Entwicklungsmodus haben Sie mehrere Möglichkeiten, Datentests für ein Projekt zu starten:

  1. Wenn Ihre Projekteinstellungen so konfiguriert sind, dass Datentests bestanden werden müssen, bevor Ihre Dateien in der Produktion bereitgestellt werden, zeigt die IDE die Schaltfläche Tests ausführen an, nachdem Sie Änderungen am Projekt per Commit übertragen haben. Dadurch werden alle Tests für Ihr Projekt ausgeführt, unabhängig davon, welche Datei den Test definiert. Sie müssen die Datentests bestehen, bevor Sie die Änderungen für die Produktion bereitstellen können.
  2. Klicken Sie im Bereich Projektzustand auf Datentests ausführen. Dadurch werden alle Datentests in Ihrem Projekt ausgeführt, unabhängig davon, welche Datei den Test definiert.
  3. Wählen Sie im Menü der Datei die Option LookML-Tests ausführen aus. Es werden nur die Tests ausgeführt, die in der aktuellen Datei definiert sind.

Nachdem Sie die Datentests ausgeführt haben, werden im Bereich Projektzustand der Fortschritt und die Ergebnisse angezeigt:

  • Ein Datentest besteht, wenn die Assertion für jede Zeile in der Testabfrage erfüllt ist. Weitere Informationen zum Einrichten von Testansprüchen und Abfragen finden Sie auf der Dokumentationsseite zum Parameter test.
  • Wenn ein Datentest fehlschlägt, finden Sie im Bereich Projektzustand Informationen dazu, warum der Test fehlgeschlagen ist, ob der Test Fehler in der Logik Ihres Modells gefunden hat oder ob der Test selbst ungültig war.
  • In den Ergebnissen des Datentests können Sie auf den Namen eines Datentests klicken, um direkt zu LookML für den Datentest zu gelangen. Alternativ können Sie auch auf die Schaltfläche Erkunden klicken, um die Funktion „Erkunden“ mit der im Datentest definierten Abfrage zu öffnen.

In der Produktion bereitstellen

Nachdem Sie die Änderungen an Ihrem Zweig festgeschrieben haben, werden Sie von der Looker-IDE aufgefordert, Ihre Änderungen mit dem primären Zweig zusammenzuführen. Die Art der Eingabeaufforderung, die Sie in der IDE sehen, hängt von der Konfiguration Ihres Projekts ab:

  • Wenn Ihr Projekt für den erweiterten Bereitstellungsmodus konfiguriert ist, werden Sie von der IDE aufgefordert, Ihre Änderungen mit dem primären Zweig zusammenzuführen. Nachdem Sie das Commit zusammengeführt haben, kann ein Looker-Entwickler mit der Berechtigung deploy Ihr Commit mithilfe des Looker-IDE-Deployment Managers, eines Webhooks oder eines API-Endpunkts in der Produktion bereitstellen.
  • Wenn Ihr Projekt für die Git-Integration mit Pull-Anfragen konfiguriert ist, werden Sie aufgefordert, eine Pull-Anfrage über die Schnittstelle Ihres Git-Anbieters zu öffnen.
  • Wenn Sie die Standardeinbindung von Looker Git haben, werden Sie bei der Berechtigung deploy aufgefordert, Ihre Änderungen mit dem Produktionszweig zusammenzuführen und in der Produktionsversion Ihrer Looker-Instanz bereitzustellen.

Erweiterter Bereitstellungsmodus

Bei der Standardeinbindung von Looker Git übertragen die Looker-Entwickler ihre Änderungen in den Entwicklungszweig und führen dann ihren Entwicklungszweig mit dem Produktionszweig zusammen. Bei der Bereitstellung in der Looker-Umgebung verwendet Looker dann das neueste Commit für den Produktionszweig. Im Abschnitt Produktionsänderungen auf dieser Seite finden Sie den Standard-Git-Workflow und andere Optionen für erweiterte Git-Implementierungen.

Wenn Sie nicht immer das neueste Commit im Produktionszweig für Ihre Looker-Umgebung verwenden möchten, kann ein Entwickler mit deploy-Berechtigung den erweiterten Bereitstellungsmodus verwenden, um den genauen Commit für Ihre Looker-Umgebung anzugeben. Dies ist in Workflows für Entwickler in mehreren Umgebungen nützlich, in denen jede Umgebung auf eine andere Version der Codebasis verweist. Außerdem haben damit ein oder mehrere Entwickler oder Administratoren mehr Kontrolle über die Änderungen, die in der Produktionsumgebung bereitgestellt werden.

Wenn der erweiterte Bereitstellungsmodus aktiviert ist, werden Entwickler von der Looker-IDE nicht aufgefordert, ihre Änderungen für die Produktion bereitzustellen. Stattdessen fordert die IDE Entwickler dazu auf, ihre Änderungen im Produktionszweig zusammenzuführen. Von dort aus können Änderungen nur folgendermaßen bereitgestellt werden:

Weitere Informationen finden Sie auf der Dokumentationsseite Erweiterter Bereitstellungsmodus.

Auswirkungen der Änderungen prüfen

Nachdem Sie Ihre Änderungen der Organisation zur Verfügung gestellt haben, können Sie mithilfe der Inhaltsvalidierung prüfen, ob Sie Dashboards oder gespeicherte Looks ungültig gemacht haben. Sie können sie gegebenenfalls beheben.

Umgang mit typischen Problemen

Während der Arbeit an Ihrem Modell müssen Sie möglicherweise Folgendes tun:

  • Änderungen verwerfen

    Gelegentlich können Sie Ihre Änderungen an der Datenmodellierung verwerfen. Wenn sie noch nicht gespeichert wurden, können Sie sie einfach aktualisieren oder die Seite verlassen und dann die Warnmeldung akzeptieren. Wenn Sie die Änderungen gespeichert haben, können Sie sie wie im Abschnitt Nicht per Commit übertragene Änderungen rückgängig machen beschrieben wieder rückgängig machen.

  • Umgang mit Zusammenführungskonflikten mit anderen Entwicklern

    Wenn mehr als ein Entwickler an Ihrem Datenmodell arbeitet, übernimmt Git normalerweise die Situation. Gelegentlich ist jedoch auch ein Mensch erforderlich, um Zusammenführungskonflikte zu lösen.

Einige Änderungen, z. B. der Name eines Felds, können sich auf vorhandene Dashboards und Looks auswirken. Nachdem Sie Ihre Änderungen der Organisation zur Verfügung gestellt haben, können Sie, wie bereits erwähnt, die Inhaltsvalidierung verwenden, um Ihre Inhalte zu überprüfen und Probleme zu beheben.

Nicht per Commit übertragene Änderungen rückgängig machen

Wenn Sie Ihren persönlichen Entwicklungszweig bearbeiten, können Sie nicht gespeicherte Änderungen rückgängig machen, die Sie nicht bereitstellen möchten. Sie können alle nicht per Commit übertragenen Änderungen für alle Dateien im Projekt oder nur für die Änderungen in einer einzelnen Datei wiederherstellen.

So setzen Sie die Änderungen, die nicht mit einem Commit verknüpft sind, für alle Dateien zurück:

  1. Klicken Sie im Steuerfeld Git Actions auf Reset to... (Zurücksetzen auf).
  2. Wählen Sie eine Wiederherstellungsoption aus:
    • Wenn Sie nur nicht gespeicherte Änderungen rückgängig machen möchten, wählen Sie Nicht per Commit übertragene Änderungen rückgängig machen aus. Sie können auch auf den Link Änderungen anzeigen klicken, um die Änderungen anzusehen, die rückgängig gemacht werden sollen.
    • Wenn Sie alle Änderungen rückgängig machen möchten, einschließlich der nicht übernommenen und per Commit übertragenen Änderungen, wählen Sie Auf Produktion zurücksetzen aus.
  3. Klicken Sie auf Bestätigen, um die Wiederherstellung abzuschließen.

Wenn Sie Hinzufügungen oder Löschungen in den Inhalten einer einzelnen Datei rückgängig machen möchten, wählen Sie im Menü der Datei die Option Änderungen rückgängig machen aus:

Wenn Sie eine Datei umbenennen, löschen Sie im Wesentlichen die Originaldatei und erstellen eine neue Datei mit einem neuen Namen. Da dies mehr als eine Datei umfasst, können Sie die Umbenennung einer Datei nicht mit der Option Datei wiederherstellen rückgängig machen. Wenn Sie die Umbenennung einer Datei rückgängig machen möchten, verwenden Sie im Steuerfeld Git Actions die Option Reset to... (Zurücksetzen auf...).

Außerdem wird die Datei nach dem Löschen nicht mehr im IDE-Dateibrowser angezeigt. Wenn Sie das Löschen einer Datei rückgängig machen möchten, verwenden Sie im Steuerfeld Git Actions die Option Reset to... (Zurücksetzen auf...).

Zusammenführungskonflikte lösen

In der Regel kann Git Ihre neuen Änderungen automatisch mit der Produktionsversion Ihrer LookML-Dateien zusammenführen. Ein Konflikt bei der Zusammenführung tritt auf, wenn Git nicht weiß, welche Änderungen beibehalten werden sollen. Dies ist in der Regel dann der Fall, wenn ein anderer Entwickler Änderungen vorgenommen hat, seit Sie das letzte Mal Daten abgerufen haben und Sie im selben Bereich Änderungen vorgenommen haben. Wenn in Ihrem Code ein Zusammenführungskonflikt auftritt, werden Sie in Looker gewarnt, nachdem Sie Änderungen per Commit übernommen und aus der Produktion abgerufen haben:

Wenn in Looker die Warnung zum Zusammenführen von Konflikten angezeigt wird, sollten Sie den Konflikt beheben, bevor Sie weitere Änderungen vornehmen. Das Zusammenführen eines Konflikts in der Produktionsumgebung führt zu Parsing-Fehlern, die eine explorative Datenanalyse verhindern können. Wenn Sie ein erfahrener Git-Nutzer sind und mit dem Übertragen der Änderungen fortfahren möchten, klicken Sie auf die Schaltfläche Don't Resolve (Nicht beheben).

In der LookML-Datei selbst sind die Zeilen mit Konflikten so gekennzeichnet:

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

Looker zeigt die folgenden Zusammenführungsmarkierungen an, um Konflikte zu kennzeichnen:

  • <<<<<<< HEAD kennzeichnet den Anfang der in Konflikt stehenden Zeilen.
  • >>>>>>> branch 'master' kennzeichnet das Ende der in Konflikt stehenden Linien.
  • ====== trennt jede Version des Codes, damit Sie sie vergleichen können.

Im vorherigen Beispiel stellt your code die von Ihnen per Commit übertragenen Änderungen und production code den Code dar, in dem Git Ihre Änderungen nicht automatisch zusammenführen konnte.

So lösen Sie Konflikte bei Fusionen:

  1. Suchen Sie die Dateien mit Konflikten beim Zusammenführen. Looker markiert diese Dateien rot, Sie können aber auch Ihr Projekt nach Fusionsmarkierungen wie <<<< oder HEAD durchsuchen, um alle Konflikte in Ihrem Projekt zu finden. Sie können die betroffenen Dateien auch finden, indem Sie in der Warnung im Bereich Git-Aktionen auf den Link Dateien klicken.
  2. Gehen Sie in der Datei zu den Zeilen mit Konflikten bei der Zusammenführung und löschen Sie die Textversion, die Sie NICHT behalten möchten. Löschen Sie auch alle Zusammenführungskonfliktmarkierungen.

  3. Speichern Sie die Datei und wiederholen Sie die vorherigen Schritte für alle Dateien, die mit Zusammenführungskonflikten markiert wurden.

    TIPP: Suchen Sie in Ihrem Projekt nach den einzelnen Zusammenführungsmarkierungen, um zu prüfen, ob Sie alle Konflikte behoben und alle Zusammenführungen gelöscht haben. Achten Sie darauf, alle Instanzen von Zusammenführungsmarkierungen aus Ihren LookML-Dateien zu entfernen. Diese Markierungen verursachen Parsing-Fehler, die Nutzer daran hindern, Ihre Daten zu untersuchen.

  4. Nachdem Sie alle Zusammenführungskonflikte gelöst und alle Zusammenführungsmarkierungen aus Ihrem Projekt gelöscht haben, commit für die Änderungen und Bereitstellung in der Produktion.

Nachdem Sie den Konflikt bei der Zusammenführung behoben und die Lösung in die Produktion übertragen haben, können andere Entwickler wie gewohnt zusammenarbeiten und mit der Arbeit fortfahren.

Automatische Speicherbereinigung für Git

Die Git Garbage Collection bereinigt unnötige Dateien und komprimiert Dateiüberarbeitungen, um das Git-Repository zu optimieren. Die automatische Speicherbereinigung für Git (git gc) wird automatisch ausgeführt, wenn die Looker-Instanz aktualisiert oder neu gestartet wird. Damit git gc nicht zu oft ausgeführt wird, wartet Looker 30 Tage seit dem letzten git gc und führt dann git gc beim nächsten Neustart aus.

In seltenen Fällen können Sie versuchen, Änderungen an die Fernbedienung zu übertragen oder Zweig an Fernbedienung zu senden, während git gc ausgeführt wird. Wenn Looker einen Fehler anzeigt, warten Sie ein bis zwei Minuten und versuchen Sie es dann noch einmal.