Utiliser le contrôle des versions et déployer

Dans cette page, nous partons du principe que le contrôle des versions a déjà été configuré pour votre projet. Si un bouton Configurer Git s'affiche au lieu des options décrites sur cette page, vous devez d'abord configurer Git pour votre projet.

Looker utilise Git pour enregistrer les modifications et gérer les versions des fichiers. Chaque projet LookML correspond à un dépôt Git et chaque branche de développeur est liée à une branche Git.

Looker peut être configuré pour fonctionner avec de nombreux fournisseurs Git, tels que GitHub, GitLab et Bitbucket. Consultez la page de documentation Configurer et tester une connexion Git pour en savoir plus sur la configuration de Git pour votre projet Looker.

Utiliser des branches Git

L'un des principaux avantages de Git est qu'un développeur Looker peut travailler dans une branche, une version isolée d'un dépôt de fichiers. Vous pouvez développer et tester sans affecter les autres utilisateurs. En tant que développeur dans Looker, vous utilisez une branche Git chaque fois que vous êtes en mode Développement.

Autre fonctionnalité majeure de Git : il permet de collaborer facilement avec d'autres développeurs. Vous pouvez créer une branche et y apporter des modifications (si vous le souhaitez). Les autres développeurs peuvent ensuite passer à cette branche pour la vérifier ou y apporter des modifications. Si un autre développeur a validé les modifications apportées à la branche, Looker affiche le bouton Pull Remote Changes (Extraire les modifications à distance). Vous devez extraire ces modifications validées sur la branche avant d'apporter des modifications supplémentaires.

Vous pouvez également supprimer une branche autre que la branche principale, votre branche actuelle ou la branche personnelle d'un développeur.

Branches personnelles

La première fois que vous accédez au mode Développement, Looker crée automatiquement votre branche Git personnelle. Votre branche personnelle commence par dev- et inclut votre nom.

Votre branche personnelle vous est propre et ne peut pas être supprimée. Votre branche personnelle est en lecture seule pour tous les autres développeurs. Si vous collaborez avec d'autres développeurs sur un projet, vous pouvez créer une branche afin que les autres puissent y accéder et contribuer aux modifications.

Créer une branche Git

Si vous travaillez sur une correction simple et que vous ne collaborez pas avec d'autres développeurs, votre branche personnelle est généralement un bon endroit pour travailler. Vous pouvez utiliser votre branche personnelle pour effectuer des mises à jour rapides, puis valider les modifications et les déployer en production.

Toutefois, vous pouvez également créer des branches Git en plus de votre branche personnelle. Une nouvelle branche Git est logique dans les situations suivantes:

  • Vous travaillez avec d'autres développeurs. Étant donné que votre branche personnelle est en lecture seule pour les autres développeurs, si vous souhaitez collaborer avec d'autres développeurs, vous devez créer une nouvelle branche Git afin que les autres développeurs puissent écrire dans la branche. Lorsque vous collaborez avec d'autres personnes, veillez à extraire les modifications chaque fois que vous reprenez le travail. De cette façon, vous recevrez les dernières mises à jour de tous les développeurs avant de poursuivre votre travail.
  • Vous travaillez sur plusieurs ensembles de fonctionnalités à la fois. Parfois, vous pouvez être au milieu d’un projet majeur, mais que vous souhaitez résoudre un problème mineur ou faire un correctif rapide. Dans ce cas, vous pouvez valider vos modifications dans la branche sur laquelle vous vous trouvez, puis créer ou basculer vers une autre branche pour travailler sur un ensemble de caractéristiques distinct. Vous pouvez effectuer votre correctif dans la nouvelle branche, puis déployer les modifications de cette branche en production avant de reprendre le travail dans votre branche d'origine.

Avant de créer une branche:

  • Si vous avez un conflit de fusion sur votre branche actuelle, vous devez résoudre le conflit avant de pouvoir créer une branche.
  • Si vous avez des modifications non validées sur la branche actuelle, vous devez valider les modifications sur votre branche actuelle avant de créer une nouvelle branche.
  • Si vous souhaitez créer une branche à partir d'une branche de développement existante (et non de la branche de production), commencez par obtenir la dernière version de la branche de développement en basculant vers cette branche, puis extrayez les modifications distantes pour synchroniser votre version locale de cette branche.

Pour créer une branche Git:

  1. Vérifiez que le mode Développement est activé.

  2. Accédez aux fichiers de votre projet dans le menu Develop (Développer).

  3. Sélectionnez l'icône Git dans le menu des icônes situé à gauche pour ouvrir le panneau Actions Git.

  4. Sélectionnez le menu déroulant View Branches (Afficher les branches).

  5. Sélectionnez New Branch (Nouvelle branche).

  6. Dans la fenêtre New Branch (Nouvelle branche), saisissez le nom de votre branche. Notez qu'il existe des limites pour les noms de branche Git. Pour connaître les exigences de dénomination, consultez Règles pour nommer une branche Git sur cette page.

  7. Sélectionnez le menu déroulant Create from (Créer à partir de) et sélectionnez une branche existante à utiliser comme point de départ pour votre nouvelle branche.

  8. Sélectionnez Create (Créer) pour créer votre branche.

Vous pouvez également créer des branches Git depuis l'onglet Gestion des branches de la page Paramètres du projet.

Règles pour nommer une branche Git

Looker utilise les exigences de la convention d'attribution de noms des branches spécifiées par Git.

Les noms de branche Git ne doivent pas:

  • contenir un espace ;
  • Contenir un double point: ..
  • Contenir une barre oblique inverse: \
  • Contenir la séquence: @{
  • Contenir un point d'interrogation: ?
  • L'adresse doit contenir un crochet ouvrant: [.
  • Contenir un caractère de contrôle ASCII: ~, \^ ou :
  • Commencer par une menstruation: .
  • Commencez par le préfixe: dev- (réservé aux branches personnelles des développeurs Looker)
  • Se terminer par une barre oblique: /
  • Terminez par l'extension: .lock

En outre, le nom de la branche ne peut contenir un astérisque (*) que s'il représente un composant de chemin complet (par exemple, foo/* ou bar/*/baz). Dans ce cas, il est interprété comme un caractère générique et non comme faisant partie du nom de la branche.

Passer à une autre branche Git

Si vous avez un conflit de fusion sur votre branche actuelle, vous devez résoudre le conflit avant de pouvoir changer de branche.

De plus, si vous avez des modifications non validées sur votre branche actuelle, vous ne pouvez pas basculer vers une branche existante tant que vous n'avez pas validé les modifications sur votre branche actuelle.

Pour passer à une autre branche Git, procédez comme suit:

  1. Dans le projet, accédez au panneau Git Actions (Actions Git) en sélectionnant l'icône Git dans le menu des icônes à gauche.
  2. Dans le panneau Git Actions (Actions Git), sélectionnez le menu déroulant de la branche Git à droite du nom de votre branche Git actuel.
  3. Sélectionnez la branche à laquelle vous souhaitez accéder en la sélectionnant dans le menu ou en saisissant le nom de la branche dans le champ de recherche. La recherche du nom d'une branche n'est pas sensible à la casse. Par exemple, vous pouvez rechercher "DEV" et voir toutes les branches dont les noms incluent "dev", "DEV", "Dev", etc.

Gérer les branches Git

L'onglet Gestion des branches de la page Paramètres du projet affiche un tableau de toutes les branches Git pour le projet Looker. Pour ouvrir l'onglet Branch Management (Gestion des branches), accédez d'abord à la page Project Settings (Paramètres du projet) en sélectionnant l'icône Settings (Paramètres) dans le menu des icônes à gauche. Sélectionnez ensuite l'onglet Branch Management (Gestion des branches).

Dans l'onglet Gestion des branches, vous pouvez:

  1. Créez une branche en sélectionnant le bouton New Branch (Nouvelle branche). Pour en savoir plus, consultez la section Créer une branche Git de cette page.
  2. Recherchez les noms des branches dans la barre de recherche.
  3. Actualisez la table en sélectionnant le bouton Actualiser.
  4. Triez le tableau en sélectionnant un nom de colonne.

Le tableau comprend les informations suivantes:

  • Name (Nom) : nom de la branche Git. Les branches personnelles des développeurs Looker commencent par dev- et incluent le prénom et le nom du développeur.
  • État: différence entre la version locale et la version distante de la branche. Par exemple, l'état 3 commits behind signifie que votre version locale de la branche est en retard sur la version distante de la branche par trois commits. Comme Looker utilise toujours la version distante de la branche principale, l'onglet Gestion des branches n'affiche pas l'état de la version locale de la branche principale. La branche principale peut toujours être considérée comme à jour.
  • Dernière mise à jour: temps écoulé depuis qu'un développeur Looker a effectué un commit dans la branche.
  • Actions: bouton permettant de supprimer la branche ou raison pour laquelle la branche ne peut pas être supprimée.

Supprimer des branches Git

Dans l'onglet Gestion des branches, vous pouvez supprimer les branches possédant un bouton Supprimer dans le tableau. Vous ne pouvez pas supprimer les branches suivantes:

Dans le tableau, ces branches ne comportent pas de bouton Supprimer. En revanche, la colonne Action du tableau indique la raison pour laquelle la branche ne peut pas être supprimée.

Vous ne pouvez pas restaurer une branche après sa suppression. Lorsque vous supprimez une branche, Looker supprime à la fois votre version locale de la branche et sa version distante.

Toutefois, si la branche a été créée par un autre développeur Looker ou si d'autres développeurs ont accédé à la branche, ces développeurs conserveront leur version locale de la branche. Si un développeur Looker effectue des commits sur sa version locale de la branche et la transfère en production, vous verrez à nouveau une version distante de la branche. Cela peut être utile si vous souhaitez restaurer la branche. Sinon, lorsque vous supprimez une branche, tous les autres développeurs Looker doivent supprimer la même branche pour éviter qu'elle ne soit refaite par erreur par quelqu'un qui la déploie sur un appareil distant.

Pour supprimer une ou plusieurs branches Git de votre projet, accédez d'abord à la page Project Settings (Paramètres du projet) en sélectionnant l'icône Settings (Paramètres) dans le menu de l'icône à gauche. Sélectionnez ensuite l'onglet Branch Management (Gestion des branches). Dans l'onglet Gestion des branches, vous pouvez supprimer des branches de deux manières:

  1. Pour supprimer plusieurs branches, commencez par cocher les cases correspondant aux branches, puis sélectionnez Supprimer les branches sélectionnées.
  2. Supprimez une seule branche en sélectionnant Delete (Supprimer) à côté de son nom.

Exécuter des commandes Git dans Looker

Looker dispose d'une interface intégrée qui s'intègre à votre service Git. Looker affiche le bouton Git dans le coin supérieur droit de l'IDE LookML.

Le bouton Git présente différentes options selon l'étape où vous en êtes dans le processus d'apport de modifications et de déploiement en production. En général, l'option affichée sur le bouton constitue le meilleur guide pour votre prochaine action.

Si votre branche de développeur est synchronisée avec la branche de production, le bouton Git affiche le message Up to Date (À jour) et ne peut pas être sélectionné.

Une fois votre projet configuré pour Git, vous pouvez sélectionner le bouton Actions Git pour ouvrir le panneau Actions Git.

Les commandes disponibles dans le panneau Actions Git dépendent de l'étape où vous en êtes dans le processus d'apport de modifications et de déploiement en production.

Publier vos modifications en production

Avec l'intégration Git par défaut de Looker, Looker invite les développeurs à suivre le workflow Git suivant:

Cela signifie qu'avec l'intégration Git par défaut, tous les développeurs fusionnent leurs modifications dans une branche appelée master, et le dernier commit de la branche master est utilisé pour l'environnement de production de Looker.

Pour les implémentations Git avancées, vous pouvez personnaliser ce workflow:

  • Vous pouvez demander à vos développeurs d'envoyer des demandes d'extraction pour votre branche de production Git, au lieu de les autoriser à fusionner leurs modifications via l'IDE Looker. Pour en savoir plus, consultez la page de documentation Configurer les paramètres du contrôle des versions de projet.
  • Vous pouvez utiliser le champ Git Production Branch Name (Nom de la branche de production Git) pour spécifier la branche de votre dépôt Git que Looker doit utiliser comme branche cible dans laquelle les branches de vos développeurs Looker seront fusionnées. Pour en savoir plus, consultez la page de documentation Configurer les paramètres du contrôle des versions de projet.
  • Vous pouvez utiliser le mode de déploiement avancé pour spécifier un autre SHA ou nom de tag de commit à déployer dans votre environnement de production Looker, au lieu d'utiliser le dernier commit sur la branche de production. (Si vous souhaitez déployer un commit depuis une autre branche, vous pouvez utiliser le webhook ou le point de terminaison de l'API en mode de déploiement avancé. Pour en savoir plus, consultez la page de documentation Mode de déploiement avancé.

Si un bouton Configurer Git s'affiche au lieu des options décrites dans cette section, vous devez d'abord configurer Git pour votre projet.

Afficher les modifications non validées

L'IDE LookML comporte plusieurs indicateurs qui s'affichent en mode Développement et que vous avez des modifications non validées, comme décrit dans la section Marquer des ajouts, des modifications et des suppressions de la page Modifier et valider du code LookML de la documentation.

Vous pouvez obtenir un récapitulatif des différences pour tous les fichiers en sélectionnant l'option View Uncommitted Changes (Afficher les modifications non validées) dans le panneau Git Actions (Actions Git).

Dans la fenêtre Uncommitted Changes to Project (Modifications non validées du projet), Looker affiche un résumé de toutes les modifications enregistrées et non validées dans tous les fichiers du projet. Pour chaque modification, Looker affiche les éléments suivants:

  • Le nom du fichier remplacé et le nom du fichier ajouté.
    • Nom du fichier remplacé (indiqué par ---) et nom du fichier ajouté (avec +++). Dans de nombreux cas, il peut s'agir de différentes versions du même fichier, avec des révisions identifiées par --- a/ et +++ b/.
    • Les fichiers supprimés remplacent un fichier nul (+++ /dev/null).
    • Les fichiers ajoutés remplacent un fichier nul (--- /dev/null).
  • Numéro de la ligne sur laquelle la modification commence.

    Par exemple, -101,4 +101,4 indique que, à la 101e ligne du fichier, 4 lignes ont été supprimées et 4 lignes ont été ajoutées. Un fichier supprimé comportant 20 lignes affiche -1,20 +0,0 pour indiquer que, sur la première ligne du fichier, 20 lignes ont été supprimées et remplacées par zéro ligne.
  • Le texte mis à jour :
    • Les lignes supprimées apparaissent en rouge.
    • Les lignes ajoutées s'affichent en vert.

Pour afficher le récapitulatif des différences pour un seul fichier, sélectionnez l'option Afficher les modifications dans le menu du fichier.

Valider des modifications

Une fois que vous avez apporté et enregistré des modifications à votre projet LookML, l'IDE peut vous demander de valider votre code LookML. Le bouton Git affiche le texte Validate LookML (Valider LookML) dans ce scénario.

Cette exigence dépend du paramètre de qualité du code défini dans votre projet. Pour en savoir plus sur le validateur de contenu, consultez la page de documentation Valider votre code LookML.

Si un autre développeur a apporté des modifications à la branche de production depuis la dernière mise à jour de votre branche locale, Looker vous demande d'extraire ces mises à jour de la branche de production. Dans ce scénario, le bouton Git affiche le texte Extraire de la production.

Si le mode de déploiement avancé est activé pour votre projet, le bouton Git affiche le texte Pull from Primary Branch (Extraire de la branche principale).

Une fois que vous avez enregistré vos modifications (et corrigé les avertissements ou erreurs LookML, le cas échéant) et retiré de la production (si nécessaire), le bouton Git affiche le texte Commit Changes & Push (Valider les modifications et envoyer les modifications).

Si vous le souhaitez, vous pouvez commencer par examiner les modifications non validées avant de les valider.

Lorsque vous êtes prêt à valider les modifications, utilisez le bouton Git pour les valider dans votre branche actuelle. Looker affiche la boîte de dialogue Commit, qui répertorie les fichiers ajoutés, modifiés ou supprimés.

Saisissez un message décrivant brièvement vos modifications et décochez les cases à côté des fichiers que vous ne souhaitez pas inclure dans la synchronisation. Sélectionnez ensuite Valider pour valider les modifications.

Recherche de PDT non compilées

Si vous avez modifié des PDT dans votre projet, il est préférable que toutes vos PDT soient créées lors du déploiement en production afin que les tables puissent être utilisées immédiatement en tant que versions de production. Pour vérifier l'état des PDT dans le projet, cliquez sur l'icône État du projet pour ouvrir le panneau État du projet, puis sélectionnez le bouton Valider l'état des PDT.

Consultez la page de documentation Tables dérivées dans Looker pour savoir comment vérifier les PDT non compilées dans votre projet LookML et utiliser des tables dérivées en mode Développement.

Exécuter des tests de données

Votre projet peut inclure un ou plusieurs paramètres test qui définissent les tests de données permettant de vérifier la logique de votre modèle LookML. Consultez la page de documentation du paramètre test pour en savoir plus sur la configuration de tests de données dans votre projet.

Si votre projet contient des tests de données et que vous êtes en mode Développement, vous pouvez lancer les tests de données de votre projet de plusieurs manières:

  1. Si les paramètres de votre projet sont configurés pour exiger la réussite des tests de données avant le déploiement de vos fichiers en production, l'IDE affichera le bouton Run Tests (Exécuter les tests) une fois que vous aurez validé les modifications apportées au projet afin d'exécuter tous les tests de votre projet, quel que soit le fichier définissant le test. Vous devez réussir les tests de données avant de pouvoir déployer vos modifications en production.
  2. Sélectionnez le bouton Run Data Tests (Exécuter des tests de données) dans le panneau Project Health (État du projet). Looker exécutera tous les tests de données de votre projet, quel que soit le fichier qui définit le test.
  3. Sélectionnez l'option Run LookML Tests (Exécuter les tests LookML) dans le menu du fichier. Looker n'exécutera que les tests définis dans le fichier actuel.

Une fois les tests de données exécutés, le panneau État du projet affiche la progression et les résultats.

  • Un test de données réussit lorsque l'assertion du test est vraie pour chaque ligne de la requête du test. Consultez la page de documentation du paramètre test pour en savoir plus sur la configuration des assertions et des requêtes de test.
  • Si un test de données échoue, le panneau État du projet fournit des informations sur la raison de l'échec, si le test a détecté des erreurs dans la logique de votre modèle ou s'il s'agit du test lui-même qui n'était pas valide.
  • À partir des résultats des tests de données, vous pouvez sélectionner le nom d'un test de données pour accéder directement au code LookML du test, ou cliquer sur le bouton Explorer la requête pour ouvrir une exploration avec la requête définie dans le test de données.

Déployer en production

Une fois que vous avez validé les modifications de votre branche, l'IDE Looker vous invite à fusionner vos modifications avec la branche principale. Le type d'invite que vous verrez dans l'IDE dépend de la configuration de votre projet:

  • Si votre projet est configuré pour le mode de déploiement avancé, l'IDE vous invitera à fusionner vos modifications dans la branche principale. Une fois votre commit fusionné, un développeur Looker disposant de l'autorisation deploy peut le déployer en production à l'aide du gestionnaire de déploiement de l'IDE Looker, ou à l'aide d'un webhook ou d'un point de terminaison d'API.
  • Si votre projet est configuré pour l'intégration Git à l'aide de requêtes d'extraction, vous serez invité à ouvrir une demande d'extraction d'extraction via l'interface de votre fournisseur Git.
  • Sinon, avec l'intégration Git par défaut de Looker, si vous disposez de l'autorisation deploy, l'IDE Looker vous invitera à fusionner vos modifications dans la branche de production et à les déployer dans la version de production de votre instance Looker.

Mode de déploiement avancé

Avec l'intégration Git par défaut dans Looker, les développeurs Looker valident leurs modifications dans leur branche de développement, puis fusionnent leur branche de développement dans la branche de production. Ensuite, lorsque vous déployez dans l'environnement Looker, Looker utilise le dernier commit de la branche de production. Consultez la section Obtenir vos modifications en production sur cette page pour connaître le workflow Git par défaut et les autres options d'implémentation avancée de Git.

Si vous ne souhaitez pas que le dernier commit de la branche de production de votre environnement Looker soit systématiquement utilisé, un développeur disposant de l'autorisation deploy peut utiliser le mode de déploiement avancé afin de spécifier le commit exact à utiliser pour votre environnement Looker. Cette fonctionnalité est utile dans les workflows de développement multi-environnements, où chaque environnement pointe vers une version différente d'un codebase. Elle permet également à un ou plusieurs développeurs ou administrateurs de mieux contrôler les modifications déployées en production.

Lorsque le mode de déploiement avancé est activé, l'IDE Looker n'invite pas les développeurs à déployer leurs modifications en production. Au lieu de cela, l'IDE invite les développeurs à fusionner leurs modifications dans la branche de production. À partir de là, les modifications ne peuvent être déployées que des manières suivantes:

  • En utilisant le gestionnaire de déploiement dans l'IDE Looker
  • Déclencher un webhook

  • Utiliser un point de terminaison de l'API

Pour en savoir plus, consultez la page de documentation Mode de déploiement avancé.

Vérifier l'impact de vos modifications

Après avoir mis vos modifications à disposition de l'organisation, vous pouvez utiliser la validation du contenu pour vous assurer que vous n'avez pas invalidé de tableaux de bord ni de Looks enregistrés. Vous aurez la possibilité de les corriger, le cas échéant.

Traiter les problèmes courants

Pendant que vous travaillez sur votre modèle, vous devrez peut-être:

  • Abandonner les modifications

    Il peut arriver que vous souhaitiez abandonner les modifications apportées à la modélisation des données. Si elles ne sont pas encore enregistrées, il vous suffit d'actualiser la page ou de quitter la page, puis d'accepter l'avertissement. Si vous avez enregistré les modifications, vous pouvez annuler les modifications non validées en suivant les instructions de la section Rétablir les modifications non validées.

  • Gérer les conflits de fusion avec le travail d'autres développeurs

    Si plusieurs développeurs travaillent sur votre modèle de données, Git s'occupe généralement de la situation. Cependant, Git a parfois besoin d'un humain pour résoudre les conflits de fusion.

Certaines modifications, telles que la modification du nom d'un champ, peuvent affecter les tableaux de bord et les Looks existants. Comme indiqué précédemment, après avoir mis vos modifications à disposition de l'organisation, vous pouvez utiliser la validation de contenu pour vérifier votre contenu et résoudre les éventuels problèmes.

Annuler les modifications non validées

Lorsque vous travaillez sur votre branche de développement personnel, vous pouvez annuler les modifications non validées enregistrées si vous ne souhaitez pas les déployer. Vous pouvez annuler toutes les modifications non validées pour tous les fichiers du projet ou uniquement les modifications dans un seul fichier.

Pour annuler les modifications non validées pour tous les fichiers:

  1. Sélectionnez l'option Rétablir dans le panneau Actions Git.
  2. Sélectionnez une option de rétablissement :
    • Pour annuler uniquement les modifications non validées, sélectionnez Annuler les modifications non validées. Vous pouvez également sélectionner le lien Afficher les modifications pour consulter les modifications qui seraient annulées.
    • Pour annuler toutes les modifications, y compris celles non validées et validées, sélectionnez Revenir à la production.
  3. Pour terminer le processus de rétablissement, sélectionnez Confirmer.

Pour annuler les ajouts ou les suppressions dans le contenu d'un seul fichier, sélectionnez l'option Annuler les modifications dans le menu du fichier:

Lorsque vous renommez un fichier, vous supprimez essentiellement le fichier d'origine pour en créer un autre avec un nouveau nom. Étant donné que cela implique plusieurs fichiers, vous ne pouvez pas utiliser l'option Rétablir le fichier pour annuler le changement de nom d'un fichier. Pour annuler le changement de nom d'un fichier, utilisez l'option Rétablir du panneau Actions Git.

De plus, si vous avez supprimé un fichier, il ne s'affiche plus dans l'explorateur de fichiers de l'IDE. Si vous souhaitez annuler la suppression d'un fichier, utilisez l'option Rétablir... du panneau Actions Git.

Résoudre les conflits de fusion

En règle générale, Git peut fusionner automatiquement vos nouvelles modifications avec la version de production de vos fichiers LookML. Un conflit de fusion se produit lorsque Git rencontre des modifications incompatibles et ne peut pas identifier celles qui doivent être conservées, généralement lorsqu'un autre développeur a apporté des modifications depuis votre dernier extraction et que vous avez apporté des modifications dans le même domaine. Si vous avez un conflit de fusion dans votre code, Looker affiche un avertissement Conflits de fusion une fois que vous avez validé les modifications et extrait les données de la production.

Lorsque Looker affiche un avertissement de conflit de fusion, nous vous recommandons de résoudre le conflit de fusion avant d'apporter d'autres modifications. L'envoi d'un conflit de fusion en production entraînera des erreurs d'analyse susceptibles d'empêcher l'exploration de vos données. Si vous êtes un utilisateur Git expérimenté et que vous souhaitez poursuivre la transmission des modifications, sélectionnez le bouton Don't Resolve (Ne pas résoudre).

Dans le fichier LookML lui-même, les lignes présentant des conflits sont indiquées comme suit:

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

Looker affiche les repères de fusion suivants pour indiquer les conflits de fusion:

  • <<<<<<< HEAD indique le début des lignes en conflit.
  • >>>>>>> branch 'master' marque la fin des lignes en conflit.
  • ======= sépare chaque version du code afin que vous puissiez les comparer.

Dans l'exemple précédent, your code représente les modifications que vous avez validées, et production code représente le code dans lequel Git n'a pas pu fusionner automatiquement vos modifications.

Pour résoudre un conflit de fusion:

  1. Recherchez les fichiers présentant des conflits de fusion. Looker marque ces fichiers en rouge, ou vous pouvez également rechercher des repères de fusion tels que <<<< ou HEAD dans votre projet pour trouver tous les conflits de votre projet. Vous pouvez également trouver les fichiers concernés en sélectionnant le lien fichiers dans l'avertissement de fusion qui s'affiche dans le panneau Actions Git.
  2. Dans le fichier, accédez aux lignes présentant des conflits de fusion et supprimez la version du texte que vous ne souhaitez PAS conserver. Supprimez également tous les repères de conflit de fusion.

  3. Enregistrez le fichier et répétez les étapes précédentes pour tous les autres fichiers présentant des conflits de fusion.

  4. Après avoir résolu tous les conflits de fusion et supprimé tous les repères de fusion de votre projet, validez les modifications et déployez-les en production.

Maintenant que vous avez résolu le conflit de fusion et envoyé votre solution en production, les autres développeurs peuvent sortir de la production et continuer à travailler comme d'habitude.

Récupération de mémoire Git

La récupération de mémoire Git nettoie les fichiers inutiles et compresse les révisions de ces fichiers afin d'optimiser votre dépôt Git. La récupération de mémoire Git (git gc) s'exécute automatiquement lorsque votre instance Looker est mise à jour ou redémarrée. Pour éviter d'exécuter git gc trop souvent, Looker attend 30 jours après la dernière git gc, puis exécute git gc au redémarrage suivant.

Dans de rares cas, vous pouvez essayer d'envoyer les modifications à distance ou d'envoyer la branche à distance alors que git gc est en cours d'exécution. Si Looker affiche une erreur, patientez une minute ou deux, puis réessayez d'appliquer vos modifications.