Utiliser le contrôle des versions et le déploiement

Dans cette page, nous partons du principe 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 développeur correspond à une branche Git.

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

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 vos applications sans affecter les autres utilisateurs. En tant que développeur dans Looker, vous utilisez une branche Git lorsque vous êtes en mode développement.

La facilité de collaboration avec d'autres développeurs est un autre avantage majeur de Git. Vous pouvez créer une branche et (si vous le souhaitez) apporter des modifications. Les autres développeurs peuvent alors passer à cette branche pour examiner ou modifier la branche. 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 de 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 de 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 pour que d'autres utilisateurs puissent y basculer et apporter des modifications.

Créer une branche Git

Si vous travaillez sur une solution simple sans collaborer 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 pertinente 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 écrire dans la branche. Lorsque vous collaborez, veillez à extraire les modifications chaque fois que vous reprenez le travail. De cette façon, vous disposerez des dernières mises à jour de tous les développeurs avant de continuer votre travail.
  • Vous travaillez sur plusieurs ensembles de fonctionnalités à la fois. Parfois, vous êtes au cœur d'un projet majeur, mais vous souhaitez résoudre un problème mineur ou le résoudre rapidement. Dans ce cas, vous pouvez appliquer vos modifications à la branche que vous utilisez, puis créer ou changer de branche pour travailler sur un ensemble distinct de fonctionnalités. Vous pouvez apporter votre correction dans la nouvelle branche, puis déployer les modifications de cette branche en production avant de reprendre le travail dans la branche d'origine.

Avant de créer une branche:

  • En cas de conflit de fusion sur votre branche actuelle, vous devez résoudre le conflit avant de pouvoir créer une nouvelle branche.
  • Si vous avez des modifications non validées sur la branche actuelle, vous devez enregistrer 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 de développement, puis importez les modifications à distance pour synchroniser la 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 à gauche pour ouvrir le panneau Actions Git.

  4. Sélectionnez le menu déroulant Afficher les branches.

  5. Sélectionnez Nouvelle branche.

  6. Dans la fenêtre New Branch (Nouvelle branche), saisissez un nom pour votre branche. Notez que les noms de branches Git sont limités. Pour connaître les règles de dénomination, consultez Règles concernant le nom des branches Git sur cette page.

  7. Cliquez sur le menu déroulant Create From (Créer à partir de), puis sélectionnez une branche existante à utiliser comme point de départ de votre nouvelle branche.

  8. Sélectionnez 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 branchement convention convention spécifiées par Git.

Les noms des branches Git ne doivent pas:

  • Contenir un caractère d'espacement
  • Contenir une période double: ..
  • Contenir une barre oblique inverse: \
  • Contient la séquence: @{
  • Contenir un point d'interrogation: ?
  • Contient un crochet d'ouverture: [
  • Contenir un caractère de contrôle ASCII: ~, \^ ou :
  • Commencez par un point: .
  • Commencez par le préfixe: dev- (réservé aux développeurs personnels des développeurs Looker)
  • Se terminer par une barre oblique: /
  • Se terminer par l'extension: .lock

De plus, le nom de la branche ne peut contenir d'astérisque (*) que s'il représente un composant de chemin 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 la branche elle-même.

Passer à une autre branche Git

En cas de conflit de fusion sur votre branche actuelle, vous devez résoudre le conflit avant de passer à une autre branche.

De plus, si vous avez des modifications non validées dans votre branche actuelle, vous ne pourrez pas passer à une branche existante tant que vous ne les aurez pas validées.

Pour changer de branche Git, procédez comme suit:

  1. Dans le projet, accédez au panneau Actions Git en sélectionnant l'icône Git dans le menu des icônes situé à gauche.
  2. Dans le panneau Actions Git, sélectionnez le menu déroulant de la branche Git à droite du nom de votre branche Git actuelle.
  3. Sélectionnez la branche à utiliser dans le menu ou saisissez le nom de la branche dans le champ de recherche. La recherche par nom de branche ne respecte pas la casse. Par exemple, vous pouvez rechercher "DEV" et afficher toutes les branches dont le nom comprend "dev", "DEV", "Dev", etc.

Gérer les branches Git

L'onglet Branch Management (Gestion des branches) de la page 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 à la page Paramètres du projet en sélectionnant l'icône Paramètres dans le menu des icônes situé à gauche. Sélectionnez ensuite l'onglet 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 sur 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 votre version locale et la version distante de la branche. Par exemple, l'état 3 commits behind signifie que la version locale de la branche se trouve derrière celle de la version distante par trois commits. É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 validé 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 qui comportent un bouton Supprimer dans le tableau. Vous ne pouvez pas supprimer les branches suivantes:

  • Branche maîtresse
  • Branche actuelle
  • Branche d'un développeur Looker

Dans ce tableau, ces branches ne possèdent pas de bouton Supprimer. Au lieu de cela, 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 supprimée. Lorsque vous supprimez une branche, Looker supprime 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 ont consulté la branche, ces développeurs disposeront toujours de la version locale de la branche. Si un développeur Looker effectue des commits dans sa version locale de la branche et la fait passer en production, vous verrez à nouveau une version distante de la branche. Cela peut s'avérer 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'une personne ne la repousse par erreur.

Pour supprimer une ou plusieurs branches Git de votre projet, accédez à la page Paramètres du projet en sélectionnant l'icône Paramètres dans le menu des icônes situé à 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. Supprimez plusieurs branches en cochant les cases correspondantes, puis en sélectionnant Supprimer les branches sélectionnées.
  2. Pour supprimer une seule 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 en fonction de l'état d'avancement dans les processus de modification et de déploiement en production. En général, l'option affichée sur le bouton est le guide le plus adapté pour votre prochaine action.

Si votre branche développeur est synchronisée avec la branche de production, le bouton Git affiche le message À 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 du processus de modification et de déploiement en production.

Rendre vos modifications en production

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

Ainsi, 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 Configurer les paramètres de contrôle des versions du projet.
  • Le champ Git Production Branch Name (Nom de la branche Git de production) vous permet de 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 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 et nom de tag de commit à déployer dans votre environnement de production Looker, plutôt que 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 avancé webhook ou le point de terminaison de l'API.) Pour en savoir plus, consultez la page de documentation Mode de déploiement avancé.

Si vous voyez un bouton Configurer Git au lieu des choix décrits dans cette section, vous devez d'abord configurer Git pour votre projet.

Afficher les modifications non enregistré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 des ajouts, modifications et suppressions de la page de documentation Modifier et valider LookML.

Vous pouvez obtenir un résumé 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 dans le 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:

  • Nom du fichier remplacé et nom du fichier ajouté.
    • Nom du fichier remplacé (indiqué par ---) et nom du fichier ajouté (indiqué par +++). Dans de nombreux cas, cela peut afficher différentes versions du même fichier, avec des révisions identifiées par --- a/ et +++ b/.
    • Les fichiers supprimés sont remplacés par des fichiers nuls (+++ /dev/null).
    • Les fichiers ajoutés remplacent un fichier nul (--- /dev/null).
  • Numéro de ligne commençant par 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. Pour un fichier supprimé comportant 20 lignes, -1,20 +0,0 doit indiquer qu'au début de la ligne, 20 lignes ont été supprimées et remplacées par zéro.
  • Le texte mis à jour :
    • Les lignes supprimées s'affichent 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.

Valider des modifications

Une fois que vous avez apporté et enregistré des modifications dans votre projet LookML, vous devrez peut-être valider votre LookML dans l'IDE. Dans ce scénario, le bouton Git affiche le texte Valider LookML.

La nécessité ou non de cette configuration dépend du paramètre de qualité du code de votre projet. Pour en savoir plus sur l'outil de validation de contenu, consultez la page Valider votre LookML.

Si un autre développeur a modifié la branche de production depuis la dernière mise à jour de votre branche locale, Looker exige que vous les extrayiez de la branche de production. Dans ce scénario, le bouton Git affiche le texte Pull from Production (Extraire de la production).

Si votre projet est activé pour le mode de déploiement avancé, le bouton Git affiche à la place le texte Extraire de la branche principale.

Une fois que vous avez enregistré vos modifications (et résolu les avertissements ou les erreurs LookML si nécessaire) et que vous les avez extraits de la production (si nécessaire), le bouton Git affiche le texte Commit Changes & Push (Valider les modifications et les transférer).

Si vous le souhaitez, vous pouvez d'abord examiner les modifications que vous n'avez pas enregistrées avant de valider ces modifications.

Lorsque vous êtes prêt à valider les modifications, utilisez le bouton Git pour appliquer ces modifications à 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, puis décochez les cases à côté des fichiers que vous ne souhaitez pas inclure dans la synchronisation. Ensuite, sélectionnez Valider pour valider les modifications.

Rechercher des PDT non compilées

Si vous avez modifié les PDT de votre projet, il est optimal que toutes vos PDT soient compilé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 tables dérivées persistantes dans le projet, sélectionnez l'icône Project Health (État du projet) pour ouvrir le panneau Project Health (État du projet), puis cliquez sur le bouton Valider l'état de la PDT.

Consultez la page de documentation Tableaux dérivés dans Looker pour savoir comment vérifier les tables dérivées persistantes non créées dans votre projet LookML et comment utiliser les tables dérivées en mode développement.

Exécuter des tests de données

Votre projet peut inclure des tests de données pour 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.

Vous devez être en mode Développement pour exécuter des tests de données. Une fois en mode développement, vous pouvez lancer des tests de données 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 de déployer vos fichiers en production, l'IDE affiche le bouton Run Tests (Exécuter les tests) une fois que vous avez commis des modifications dans le projet pour 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.
  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écute 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 que vous avez exécuté les tests de données, le panneau État du projet affiche la progression et les résultats.

  • Un test de données réussit lorsque l'assertion est vraie pour chaque ligne de la requête. Consultez la page de documentation sur le 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 Project Health (État du projet) indique pourquoi il a échoué, s'il a détecté des erreurs dans la logique de votre modèle ou s'il s'agit du test en lui-même.
  • Dans les résultats du test de données, vous pouvez sélectionner le nom d'un test de données pour accéder directement au LookML pour ce test de données. Vous pouvez également 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 les modifications validées dans votre branche principale, l'IDE Looker vous invite à fusionner vos modifications 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 déployer votre commit en production à l'aide du gestionnaire de déploiement Looker IDE, ou d'un webhook ou d'un point de terminaison de l'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 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 de Looker, les développeurs Looker appliquent leurs modifications dans leur branche de développement, puis fusionnent leur branche de développement dans la branche de production. Ensuite, lors du déploiement dans l'environnement Looker, Looker utilise le dernier commit sur la branche de production. (Consultez la section Télécharger vos modifications en production de cette page pour connaître le workflow Git par défaut et les autres options d'implémentation Git avancée.)

Dans les cas où vous ne souhaitez pas toujours utiliser le dernier commit sur la branche de production de 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. Cela 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 ne demande pas aux développeurs de déployer leurs modifications en production. L'IDE invite plutôt les développeurs à fusionner leurs modifications dans la branche de production. À partir de là, vous pouvez déployer les modifications comme suit:

  • Utiliser Deployment Manager 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

Une fois vos modifications mises à la disposition de l'organisation, vous pouvez utiliser la validation de contenu pour vous assurer que vous n'avez invalidé aucun tableau de bord ni aucun style enregistré. Vous pourrez les corriger si nécessaire.

Traiter les problèmes courants

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

  • Abandonner vos modifications

    Il peut arriver que vous souhaitiez abandonner vos modifications de modélisation des données. Si elles n'ont pas encore été enregistrées, il vous suffit d'actualiser la page ou de quitter la page, puis d'accepter l'invite d'avertissement. Si vous avez enregistré les modifications non enregistrées, vous pouvez les annuler comme indiqué dans la section Annuler les modifications non validées.

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

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

Certaines modifications, comme la modification du nom d'un champ, peuvent affecter les tableaux de bord et les styles existants. Comme indiqué précédemment, une fois que les modifications ont été mises à la disposition de l'organisation, vous pouvez utiliser la validation de contenu pour vérifier votre contenu et résoudre les problèmes éventuels.

Annuler des modifications non enregistrées

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

Pour annuler les modifications non enregistrées de tous les fichiers:

  1. Sélectionnez l'option Rétablir dans le panneau Actions Git.
  2. Sélectionnez une option d'annulation :
    • Pour n'annuler que les modifications non validées, sélectionnez Annuler les modifications non validées. Vous pouvez également cliquer sur le lien Afficher les modifications pour voir les modifications qui seront annulées.
    • Pour annuler toutes les modifications enregistrées, y compris celles apportées sans engagement, sélectionnez Revenir à l'environnement de production.
  3. Pour finaliser le processus d'annulation, sélectionnez Confirmer.

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

Lorsque vous renommez un fichier, vous supprimez essentiellement le fichier d'origine pour en créer un autre portant un nouveau nom. Étant donné que plusieurs fichiers sont concernés, vous ne pouvez pas annuler le changement de nom d'un fichier à l'aide de l'option Rétablir le fichier. Si vous souhaitez 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 n'est plus affiché dans l'explorateur de fichiers 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 automatiquement fusionner vos nouvelles modifications avec la version de production de vos fichiers LookML. Un conflit de fusion se produit lorsque Git rencontre des modifications contradictoires et ne peut pas identifier celles qui doivent être conservées, généralement lorsqu'un autre développeur a effectué des modifications depuis la dernière extraction et dans la même zone. En cas de conflit de fusion dans votre code, Looker affiche un avertissement Conflits de fusion après la validation des modifications et l'extraction depuis la 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. Le transfert 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 avancé et que vous souhaitez maintenant appliquer 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
&#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 marque 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 ajoute ces fichiers en rouge. Vous pouvez également rechercher dans votre projet des repères de fusion, tels que <<<< ou HEAD, pour rechercher 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.
  2. Dans le fichier, accédez aux lignes comportant des conflits de fusion et supprimez la version du texte que vous ne voulez PAS conserver, ainsi que 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 marqués par 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 que vous êtes passé en production, les autres développeurs peuvent récupérer des fichiers de la production et continuer à travailler normalement.

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 fichiers pour 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 le dernier git gc, puis exécute git gc au prochain redémarrage.

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