Cette page suppose que votre projet a déjà été configuré pour le contrôle des versions. Si vous voyez un bouton Configurer Git au lieu des choix décrits 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 correspond à une branche Git.
Vous pouvez configurer Looker pour qu'il fonctionne avec de nombreux fournisseurs Git, tels que GitHub, GitLab et Bitbucket. Consultez la page de documentation Configurer et tester une connexion Git pour savoir comment configurer 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, qui est 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 Looker, vous utilisez une branche Git chaque fois que vous êtes en mode Développement.
Une autre fonctionnalité majeure de Git est la facilité de collaboration avec d'autres développeurs. Vous pouvez créer une branche et (si vous le souhaitez) y apporter des modifications. D'autres développeurs peuvent ensuite passer à cette branche pour l'examiner ou y apporter des modifications. Si un autre développeur a validé des modifications dans la branche, Looker affiche le bouton Extraire les modifications distantes. Vous devez extraire ces modifications validées vers la branche avant d'en apporter d'autres.
Vous pouvez également supprimer une branche autre que la branche principale, votre branche actuelle ou la branche personnelle d'un développeur.
Branches personnelles
Pour améliorer les performances, la première fois que vous ouvrez un projet LookML en mode Développement, l'IDE Looker affiche la version Mode Production du projet, ainsi que le bouton Créer une copie pour le développement. Une fois que vous avez cliqué sur le bouton Créer une copie développeur pour le projet, l'IDE Looker crée votre branche Git personnelle et charge le projet LookML en mode Développement pour vous.
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 pour que d'autres puissent y accéder et y apporter des 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 transférer en production.
Toutefois, vous pouvez également créer des branches Git en plus de votre branche personnelle. Une nouvelle branche Git est judicieuse 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 personnes, vous devez créer une branche Git afin que les autres développeurs puissent y écrire. Lorsque vous collaborez avec d'autres personnes, veillez à extraire les modifications chaque fois que vous reprenez le travail. Vous disposerez ainsi des dernières mises à jour de tous les développeurs avant de poursuivre votre travail.
- Vous travaillez sur plusieurs ensembles de fonctionnalités à la fois. Il peut arriver que vous soyez en plein milieu d'un projet majeur, mais que vous souhaitiez résoudre un problème mineur ou effectuer une correction rapide. Dans ce cas, vous pouvez valider vos modifications dans la branche sur laquelle vous vous trouvez, puis créer une autre branche ou passer à une autre branche pour travailler sur un autre ensemble de fonctionnalités. Vous pouvez effectuer la correction 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 un conflit de fusion se produit dans votre branche actuelle, vous devez le résoudre 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 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 passant à cette branche de développement, puis extrayez les modifications à distance pour synchroniser votre version locale de cette branche.
Pour créer une branche Git :
- Vérifiez que le mode Développement est activé.
Accédez aux fichiers de votre projet dans le menu Développer.
Sélectionnez l'icône Git dans le menu d'icônes de gauche pour ouvrir le panneau Actions Git.
Sélectionnez le menu déroulant Afficher les branches.
Sélectionnez Nouvelle branche.
Dans la fenêtre Nouvelle branche, saisissez le nom de votre branche. Notez que les noms de branches Git sont soumis à des limites. Pour connaître les exigences de dénomination, consultez Règles de dénomination d'une branche Git sur cette page.
Sélectionnez le menu déroulant Créer à partir de, puis sélectionnez une branche existante à utiliser comme point de départ pour votre nouvelle branche.
Sélectionnez Créer pour créer votre branche.
Vous pouvez également créer des branches Git à partir de l'onglet Gestion des branches des paramètres du projet.
Règles de dénomination d'une branche Git
Looker utilise les exigences de convention de nommage des branches spécifiées par Git.
Les noms de branches 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 :
?
- Contenir un crochet ouvrant :
[
- Contenir un caractère de contrôle ASCII :
~
,\^
ou:
- Commencez par un point :
.
- Commencez par le préfixe
dev-
(réservé aux branches personnelles des développeurs Looker). - Terminez par une barre oblique :
/
- Terminez par l'extension :
.lock
De plus, le nom de branche ne peut contenir un astérisque (*
) que si celui-ci représente un composant de chemin d'accès entier (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 branche.
Passer à une autre branche Git
Si vous avez un conflit de fusion sur votre branche actuelle, vous devez le résoudre avant de pouvoir passer à une autre branche.
De plus, si vous avez des modifications non validées sur votre branche actuelle, vous ne pouvez pas passer à une branche existante tant que vous n'avez pas validé les modifications sur votre branche actuelle.
Pour passer à une autre branche Git :
- Dans le projet, accédez au panneau Actions Git en sélectionnant l'icône Git dans le menu d'icônes de gauche.
- Dans le panneau Actions Git, sélectionnez le menu déroulant de la branche Git à droite du nom de votre branche Git actuelle.
- Sélectionnez la branche vers laquelle vous souhaitez basculer en la sélectionnant dans le menu ou en saisissant son nom dans le champ de recherche. La recherche de noms de branches n'est pas sensible à la casse. Par exemple, vous pouvez rechercher "DEV" et afficher toutes les branches dont le nom inclut "dev", "DEV", "Dev", etc.
Gérer les branches Git
L'onglet Gestion des branches des paramètres du projet affiche un tableau de toutes les branches Git du projet Looker. Pour ouvrir l'onglet Gestion des branches, accédez d'abord aux paramètres du projet en sélectionnant l'icône Paramètres dans le menu d'icônes de gauche. Ensuite, sélectionnez l'onglet Gestion des établissements.
Dans l'onglet Gestion des branches, vous pouvez :
- 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 sur cette page.
- Recherchez des noms de branches dans la barre de recherche.
- Actualisez le tableau en sélectionnant le bouton Actualiser.
- Triez le tableau en sélectionnant le nom d'une colonne.
Le tableau comprend les informations suivantes :
- 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, un état
3 commits behind
signifie que votre version locale de la branche est en retard de trois commits par rapport à la version distante de la branche. Étant donné que 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 motif pour lequel la branche ne peut pas être supprimée.
Supprimer des branches Git
Dans l'onglet Gestion des branches, vous pouvez supprimer les branches qui comportent un bouton Supprimer dans le tableau. Vous ne pouvez pas supprimer les branches suivantes :
- Branche principale
- Votre branche actuelle
- La branche personnelle d'un développeur Looker
Dans le tableau, ces branches ne comportent pas de bouton Supprimer. 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 une fois qu'elle a été supprimée. Lorsque vous supprimez une branche, Looker supprime à la fois votre version locale et la version distante de la branche.
Toutefois, si la branche a été créée par un autre développeur Looker ou si d'autres développeurs l'ont extraite, ils disposeront toujours de leur version locale de la branche. Si un développeur Looker valide des modifications dans sa version locale de la branche et les 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 s'assurer qu'elle ne peut pas être réactivée accidentellement par une personne qui la transfère vers un dépôt distant.
Pour supprimer une ou plusieurs branches Git de votre projet, accédez d'abord aux paramètres du projet en sélectionnant l'icône Paramètres dans le menu d'icônes de gauche. Sélectionnez ensuite l'onglet Gestion des branches. Dans l'onglet Gestion des branches, vous pouvez supprimer des branches de deux manières :
- Pour supprimer plusieurs branches, cochez d'abord les cases correspondantes, puis sélectionnez Supprimer les branches sélectionnées.
- Pour supprimer une branche, sélectionnez 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 en haut à droite de l'IDE LookML.
Le bouton Git affiche différentes options selon l'étape à laquelle vous vous trouvez dans le processus de modification et de déploiement en production. En règle générale, l'option affichée sur le bouton est la meilleure indication pour votre prochaine action.
Si votre branche de développement est synchronisée avec la branche de production, le bouton Git affiche le message À jour et n'est pas sélectionnable.
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 à laquelle vous vous trouvez dans le processus de modification et de déploiement en production.
Déployer vos modifications en production
Avec l'intégration Git Looker par défaut, Looker invite les développeurs à suivre le workflow Git suivant :
- Valider les modifications dans la branche de développement actuelle du développeur (et exécuter des tests de données si votre projet est configuré pour exiger des tests avant le déploiement)
- Fusion de la branche de développement dans la branche de production, qui est appelée
master
par défaut - Déployer la branche de production dans l'environnement de production Looker qui sera présenté à vos utilisateurs finaux Looker
Cela signifie qu'avec l'intégration Git par défaut, tous les développeurs fusionnent leurs modifications dans une branche appelée master
. Le dernier commit de la branche master
est celui qui 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 requêtes d'extraction pour votre branche de production Git, au lieu de leur permettre de fusionner leurs modifications via l'IDE Looker. Pour en savoir plus, consultez la page de documentation Configurer les paramètres de contrôle des versions du projet.
- Vous pouvez utiliser le champ 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 sont fusionnées. Pour en savoir plus, consultez la page de documentation Configurer les paramètres de contrôle des versions du projet.
- Vous pouvez utiliser le mode de déploiement avancé pour spécifier un autre SHA de commit ou nom de tag à 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 à partir d'une autre branche, vous pouvez utiliser le mode de déploiement avancé webhook ou point de terminaison de l'API.) Pour en savoir plus, consultez la page de documentation sur le mode de déploiement avancé.
Si vous voyez un bouton Configure Git (Configurer Git) au lieu des choix décrits 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 lorsque vous êtes en mode Développement et que vous avez des modifications non validées, comme décrit dans la section Marquer les ajouts, les modifications et les suppressions de la page de documentation Présentation de l'IDE Looker.
Vous pouvez obtenir un récapitulatif des différences pour tous les fichiers en sélectionnant l'option Afficher les modifications non validées dans le panneau Actions Git.
Dans la fenêtre Modifications non validées apportées au projet, Looker affiche un récapitulatif de toutes les modifications enregistrées et non validées dans tous les fichiers du projet. Pour chaque modification, Looker affiche les informations suivantes :
- Nom du fichier remplacé et nom du fichier ajouté.
- Le nom du fichier remplacé (indiqué par
---
) et le nom du fichier ajouté (indiqué par+++
). 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 sont affichés comme remplaçant un fichier nul (
+++ /dev/null
). - Les fichiers ajoutés sont indiqués comme remplaçant un fichier nul (
--- /dev/null
).
- Le nom du fichier remplacé (indiqué par
- Numéro de la ligne où commence la modification.Par exemple,
-101,4 +101,4
indique que, à la 101e ligne du fichier, quatre lignes ont été supprimées et quatre lignes ont été ajoutées. Un fichier supprimé de 20 lignes affichera-1,20 +0,0
pour indiquer qu'à la première ligne du fichier, 20 lignes ont été supprimées et remplacées par zéro ligne. - Texte modifié :
- Les lignes supprimées sont affichées en rouge.
- Les lignes ajoutées sont affichées en vert.
Pour afficher un 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é des modifications à votre projet LookML et que vous les avez enregistrées, l'IDE peut vous demander de valider votre code LookML. Dans ce cas, le bouton Git affiche le texte Valider le LookML.
La nécessité de cette étape dépend du paramètre Qualité du code de votre projet. Pour en savoir plus sur le validateur de contenu, consultez la page de documentation Valider votre 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 modifications 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 Extraire de la branche principale.
Une fois que vous avez enregistré vos modifications (et corrigé les éventuels avertissements ou erreurs LookML, si nécessaire) et extrait les données de production (si nécessaire), le bouton Git affiche le texte Valider les modifications et les transférer.
Si vous le souhaitez, vous pouvez d'abord examiner vos 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 Valider, qui liste les fichiers qui ont été ajoutés, modifiés ou supprimés.
Saisissez un message décrivant brièvement vos modifications, puis 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.
Rechercher les tables PDT non compilées
Si vous avez apporté des modifications à des tables PDT de votre projet, il est préférable que toutes vos tables PDT soient créées lorsque vous déployez en production afin que les tables puissent être utilisées immédiatement comme versions de production. Pour vérifier l'état des PDT dans le projet, sélectionnez l'icône État du projet pour ouvrir le panneau État du projet, puis sélectionnez le bouton Valider l'état des PDT.
Pour en savoir plus sur la recherche de tables PDT déconstruites dans votre projet LookML et sur l'utilisation des tables dérivées en mode Développement, consultez la page de documentation Tables dérivées dans Looker.
Exécuter des tests de données
Votre projet peut inclure un ou plusieurs paramètres test
qui définissent des tests de données permettant de vérifier la logique de votre modèle LookML. Consultez la page de documentation sur le paramètre test
pour savoir comment configurer des 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 :
- Si les paramètres de votre projet sont configurés de manière à exiger la réussite des tests de données avant de déployer vos fichiers en production, l'IDE affichera le bouton Exécuter les tests après que vous aurez validé les modifications apportées au projet. Vous pourrez ainsi exécuter tous les tests de votre projet, quel que soit le fichier qui définit le test. Vous devez réussir les tests de données avant de pouvoir déployer vos modifications en production.
- Sélectionnez le bouton Exécuter les tests de données dans le panneau É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.
- Sélectionnez l'option 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 est réussi lorsque l'assertion du test est vraie pour chaque ligne de la requête du test. Pour savoir comment configurer des assertions et des requêtes de test, consultez la page de documentation sur le paramètre
test
. - Si un test de données échoue, le panneau État du projet vous indiquera pourquoi, en précisant si des erreurs ont été détectées dans la logique de votre modèle ou si le test lui-même 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 LookML du test de données. Vous pouvez également sélectionner 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 apportées à votre branche, l'IDE Looker vous invite à les fusionner avec la branche principale. Le type d'invite que vous verrez dans l'IDE dépendra de la configuration de votre projet :
- Si votre projet est configuré pour le mode de déploiement avancé, l'IDE vous invite à 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 demandes d'extraction, vous serez invité à ouvrir une demande d'extraction d'extraction à l'aide de l'interface de votre fournisseur Git.
- Sinon, avec l'intégration Git Looker par défaut, si vous disposez de l'autorisation
deploy
, l'IDE Looker vous invite à fusionner vos modifications dans la branche de production et à les déployer dans la version de production de votre instance Looker.
Mode Déploiement avancé
Avec l'intégration Git Looker par défaut, 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 Déployer vos modifications en production sur cette page pour connaître le workflow Git par défaut et d'autres options pour les implémentations Git avancées.)
Dans les cas où vous ne souhaitez pas toujours utiliser le dernier commit de la branche de production pour votre environnement Looker, un développeur disposant de l'autorisation deploy
peut utiliser le mode de déploiement avancé pour spécifier le commit exact à utiliser pour votre environnement Looker. Cela est utile dans les workflows de développement multi-environnements, où chaque environnement pointe vers une version différente d'un codebase. Il 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. Les modifications ne peuvent être déployées que de l'une des manières suivantes :
- Utiliser le gestionnaire de déploiement dans l'IDE Looker
- Déclencher un webhook
Utiliser un point de terminaison d'API
Pour en savoir plus, consultez la page de documentation sur le mode de déploiement avancé.
Vérifier l'impact de vos modifications
Une fois vos modifications disponibles pour l'organisation, vous pouvez utiliser la validation du contenu pour vous assurer de ne pas avoir invalidé de tableaux de bord ni de Looks enregistrés. Vous aurez la possibilité de les corriger, le cas échéant.
Gérer les problèmes courants
Lorsque vous travaillez sur votre modèle, vous devrez peut-être :
Annuler vos modifications
Il peut arriver que vous souhaitiez abandonner les modifications apportées à votre modélisation des données. Si elles ne sont pas encore enregistrées, il vous suffit d'actualiser la page ou de la quitter, puis d'accepter l'invite d'avertissement. Si vous avez enregistré les modifications, vous pouvez annuler les modifications non validées, comme décrit dans la section Annuler 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 gère généralement la situation. Toutefois, Git a parfois besoin d'une personne pour résoudre les conflits de fusion.
Certaines modifications, comme le changement de nom d'un champ, peuvent affecter les tableaux de bord et les Looks existants. Comme indiqué précédemment, une fois que vous avez mis vos modifications à la disposition de l'organisation, vous pouvez utiliser la validation du 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 enregistrées et non validé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 apportées à un seul fichier.
Pour annuler les modifications non validées pour tous les fichiers :
- Sélectionnez l'option Revenir à… dans le panneau Actions Git.
- 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 voir les modifications qui seraient annulées.
- Pour annuler toutes les modifications, y compris celles qui ont été validées et celles qui ne l'ont pas été, sélectionnez Revenir à la production.
- 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 Rétablir les modifications dans le menu de ce fichier :
Lorsque vous renommez un fichier, vous supprimez en fait le fichier d'origine et vous en créez un autre avec un nouveau nom. Comme cela implique plusieurs fichiers, vous ne pouvez pas utiliser l'option Rétablir le fichier pour annuler le changement de nom d'un fichier. Si vous souhaitez annuler le renommage d'un fichier, utilisez l'option Revenir à… dans le panneau Actions Git.
De plus, si vous avez supprimé un fichier, il n'apparaît plus dans l'explorateur de fichiers de l'IDE. Si vous souhaitez annuler la suppression d'un fichier, utilisez l'option Revenir à… dans le 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 conflictuelles et ne peut pas identifier celles qui doivent être conservées. Cela se produit généralement lorsqu'un autre développeur a apporté des modifications depuis votre dernière extraction et que vous avez apporté des modifications dans la même zone. Si votre code présente un conflit de fusion, Looker affiche un avertissement Conflits de fusion après que vous avez validé les modifications et extrait les données de production.
Lorsque Looker affiche l'avertissement de conflit de fusion, nous vous recommandons de résoudre le conflit de fusion avant d'apporter d'autres modifications. Si vous transférez un conflit de fusion en production, cela entraînera des erreurs d'analyse qui peuvent empêcher l'exploration de vos données. Si vous êtes un utilisateur Git avancé et que vous souhaitez continuer à transférer les modifications, sélectionnez le bouton Ne pas résoudre.
Dans le fichier LookML lui-même, les lignes comportant des conflits sont marquées comme suit :
<<<<<<< HEAD
Your code
=======
Production code
>>>>>>> branch 'master'
Looker affiche les marqueurs de fusion suivants pour indiquer les conflits de fusion :
- <<<<<<<
HEAD
marque le début des lignes en conflit. - >>>>>>>
branch 'master'
marque la fin des lignes en conflit. - ======= sépare chaque version du code pour 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 :
- Recherchez les fichiers présentant des conflits de fusion. Looker marque ces fichiers en rouge. Vous pouvez également rechercher des marqueurs de fusion dans votre projet, tels que <<<< ou
HEAD
, pour trouver tous les conflits dans 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. - Dans le fichier, accédez aux lignes comportant des conflits de fusion, supprimez la version du texte que vous NE souhaitez pas conserver, puis supprimez tous les marqueurs de conflits de fusion.
Enregistrez le fichier et répétez les étapes précédentes pour tous les autres fichiers marqués comme présentant des conflits de fusion.
Une fois que vous avez résolu tous les conflits de fusion et supprimé tous les marqueurs 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 résolution en production, les autres développeurs peuvent extraire les données de production et continuer à travailler comme d'habitude.
Récupération de mémoire Git
La collecte des déchets Git nettoie les fichiers inutiles et compresse les révisions de fichiers pour optimiser votre dépôt Git. Le garbage collection Git (git gc
) est exécuté 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 exécution de git gc
, puis exécute git gc
au prochain redémarrage.
Dans de rares cas, vous pouvez essayer d'envoyer les modifications au dépôt distant ou d'envoyer la branche au dépôt distant pendant l'exécution de git gc
. Si Looker affiche une erreur, attendez une ou deux minutes, puis réessayez d'envoyer vos modifications.