Exécuter des opérations Git sur Dossiers Git Databricks (Repos)

L’article explique comment effectuer des opérations Git courantes dans votre espace de travail Databricks à l’aide de dossiers Git, notamment le clonage, la création de branches, la validation et l’envoi (push).

Cloner un référentiel connecté à un référentiel Git

1. Dans la barre latérale, sélectionnez Espace de travail, puis accédez au dossier dans lequel vous souhaitez créer le clone du référentiel Git.

2. Cliquez sur la flèche vers le bas à droite d’Ajouter en haut à droite de l’espace de travail, puis sélectionnez Dossier Git dans la liste déroulante.

   

3. Dans la boîte de dialogue Créer un dossier Git, fournissez les informations suivantes :

   • URL du référentiel Git que vous souhaitez cloner, au format https://example.com/organization/project.git
   • Fournisseur Git pour le référentiel que vous souhaitez cloner. Les options incluent GitHub, GitHub Enterprise, GitLab et Azure DevOps (Azure Repos)
   • Nom du dossier dans votre espace de travail qui contiendra le contenu du référentiel cloné
   • Que vous utilisiez ou non le basculement partiel sur une branche, lors duquel seuls les sous-répertoires indiqués par un modèle de cône sont clonés

   

À ce moment, vous avez la possibilité de cloner uniquement un sous-ensemble des répertoires de votre dépôt au moyen du basculement partiel sur une branche. Cela est utile si votre dépôt est plus grand que les limites prises en charge par Databricks

1. Cliquez sur Créer un dossier Git. Le contenu du référentiel distant est cloné dans le référentiel Databricks et vous pouvez commencer à travailler avec, à l’aide d’opérations Git prises en charge via votre espace de travail.

Meilleure pratique : Collaboration dans Dossiers Git

Les dossiers Git Databricks se comportent efficacement en tant que clients Git incorporés dans votre espace de travail afin que les utilisateurs puissent collaborer à l’aide du contrôle de code source et du contrôle de version Git. Pour rendre la collaboration d’équipe plus efficace, utilisez un dossier Databricks Git distinct mappé à un dépôt Git distant pour chaque utilisateur qui travaille dans sa propre branche de développement. Bien que plusieurs utilisateurs puissent contribuer au contenu d’un dossier Git, seuls un utilisateur désigné doit effectuer des opérations Git comme le tirage, la poussée, le commit et le basculement de branche. Si plusieurs utilisateurs effectuent des opérations Git sur un dossier Git, la gestion des branches peut devenir difficile et source d’erreurs, en particulier quand un utilisateur change de branche et s’il change de branche de façon non intentionnelle pour tous les utilisateurs de ce dossier.

Important

Actuellement, vous ne pouvez pas utiliser l’interface CLI de Git pour effectuer des opérations Git dans un dossier Git. Si vous clonez un référentiel Git à l’aide de l’interface CLI par le biais du terminal web d’un cluster, les fichiers ne s’afficheront pas dans l’interface utilisateur Azure Databricks.

Accéder à la boîte de dialogue Git

Vous pouvez accéder à la boîte de dialogue de Git à partir d’un notebook ou du navigateur de Dossiers Git Databricks.

• Dans un notebook, cliquez sur le bouton en regard du nom du notebook, qui identifie la branche Git active.

  

• Dans le navigateur de Dossiers Git Databricks, cliquez sur le bouton à la droite du nom du référentiel. Vous pouvez également effectuer un clic droit sur le nom de dépôt, puis sélectionner Git... dans le menu.

  

Vous verrez une boîte de dialogue en plein écran dans laquelle vous pouvez effectuer des opérations Git.

1. Votre branche de travail actuelle. Vous pouvez sélectionner d’autres branches ici. Si d’autres utilisateurs ont accès à ce dossier Git, modifier la branche change également la branche de leur côté s’ils partagent le même espace de travail. Consultez la meilleure pratique recommandée pour éviter ce problème.
2. Bouton permettant de créer une branche.
3. Liste des ressources de fichiers et des sous-dossiers archivés dans votre branche actuelle.
4. Bouton qui vous dirige vers votre fournisseur Git et vous présente l’historique de la branche actuelle.
5. Bouton permettant d’extraire du contenu à partir du référentiel Git distant.
6. Zone de texte dans laquelle vous ajoutez un message de validation et une description développée facultative pour vos modifications.
7. Bouton permettant de valider votre travail sur la branche de travail et d’envoyer (push) la branche mise à jour vers le référentiel Git distant.

Cliquez sur le menu des trois points en haut à droite pour choisir parmi d’autres opérations de branche Git, telles qu’une réinitialisation en dur, une fusion ou un rebasage.

Voilà votre point de départ pour effectuer des opérations Git sur votre dossier Git d’espace de travail. Vous êtes limité aux opérations Git présentées dans l’interface utilisateur.

Créer une branche

Vous pouvez créer une nouvelle branche basée sur une branche existante à partir de la boîte de dialogue de Git :

Passer à une autre branche

Vous pouvez basculer vers (basculement sur une branche) une autre branche à l’aide de la liste déroulante des branches dans la boîte de dialogue Git :

Important

Une fois que vous avez basculé une branche dans un dossier Git, elle peut toujours être supprimée sur le référentiel Git distant par quelqu’un d’autre. Si une branche est supprimée sur le référentiel distant, la version locale peut rester présente dans le dossier Git associé pendant jusqu’à 7 jours. Les branches locales dans Databricks ne peuvent pas être supprimées. Pour les supprimer, vous devez supprimer le dépôt et le recloner.

Valider et envoyer (push) des modifications au dépôt Git distant

Après avoir ajouté de nouveaux notebooks ou fichiers, ou après avoir modifié des notebooks ou des fichiers existants, l’interface utilisateur de dossier Git met en évidence les modifications.

Ajoutez un message de validation obligatoire pour les modifications, puis cliquez sur Valider et envoyer (push) pour envoyer ces modifications au dépôt Git distant.

Si vous n’avez pas l’autorisation de commiter sur la branche par défaut (par exemple la branche main), créez une branche et utilisez l’interface de votre fournisseur Git pour créer une demande de tirage (pull request) afin de la fusionner dans la branche par défaut.

Remarque

• Les sorties de notebook ne sont pas incluses dans les commits par défaut quand les notebooks sont enregistrés dans des formats de fichier source (.py, .scala, .sql, .r). Pour en savoir plus sur la validation des sorties de notebook en utilisant le format IPYNB, consultez Contrôler les validations des artefacts de sortie de notebook IPYNB

Extrait de modifications à partir du référentiel Git distant

Pour extraire des modifications à partir du référentiel Git distant, cliquez sur Extraire dans la boîte de dialogue des opérations Git. Les notebooks et autres fichiers sont mis à jour automatiquement vers la dernière version de votre référentiel Git distant. Si les modifications extraites du référentiel distant sont en conflit avec vos modifications locales dans Databricks, vous devez résoudre les conflits de fusion.

Important

Les opérations Git qui extraient des modifications en amont effacent l’état du notebook. Pour plus d’informations, consultez Les modifications entrantes effacent l’état du notebook.

Fusionner des branches

Accédez à l’opération de fusion Git en la sélectionnant dans le menu des trois points en haut à droite de la boîte de dialogue des opérations Git.

La fonction de fusion dans Dossiers Git Databricks fusionne une branche dans une autre à l’aide de git merge. Une opération de fusion est une façon d’associer l’historique de validations de l’un des branches à l’autre ; la seule différence est la stratégie qu’il utilise pour y parvenir. Pour les débutants Git, nous recommandons d’utiliser la fusion (sur rebaser), car elle n’exige pas l’envoi (push) de force à une branche. Elle ne réécrit donc pas l’historique des validations.

Pour découvrir plus d’informations sur les différences entre les validations de rebasage et la fusion, veuillez consulter Documentation d’Atlassian sur le sujet.

• S’il existe un conflit de fusion, résolvez-le dans l’interface utilisateur de Dossiers Git.
• En l’absence de conflit, la fusion est envoyée au référentiel Git distant à l’aide de git push.

Rebase une branche sur une autre branche

Accédez à l’opération de fusion Git en la sélectionnant dans le menu des trois points en haut à droite de la boîte de dialogue des opérations Git.

Le rebasage modifie l’historique de validation d’une branche. Comme git merge, git rebase intègre les modifications d’une branche dans une autre. Rebaser effectue les opérations suivantes :

1. Enregistre les validations sur votre branche actuelle dans une zone temporaire.
2. Réinitialise la branche actuelle à la branche choisie.
3. Réapplique chaque validation individuelle précédemment enregistrée sur la branche actuelle, ce qui aboutit à un historique linéaire qui combine les modifications des deux branches.

Pour obtenir une explication détaillée du rebasage, consultez Rebasage de git.

Avertissement

L’utilisation du rebasage peut entraîner des problèmes de contrôle de version pour les collaborateurs travaillant dans le même référentiel.

Un workflow courant consiste à rebaser une branche de fonctionnalité sur la branche primaire.

Pour rebaser une branche sur une autre branche :

1. Dans le menu Branche de l’interface utilisateur de Dossiers Git, sélectionnez la branche que vous souhaitez rebaser.

2. Sélectionnez Rebaser dans le menu des trois points.

   

3. Sélectionnez la branche sur laquelle vous souhaitez rebaser.

   L’opération de rebasage intègre des modifications de la branche que vous choisissez ici dans la branche actuelle.

Dossiers Git Databricks exécute git commit et git push --force pour mettre à jour le référentiel distant.

Résoudre les conflits de fusion

Les conflits de fusion se produisent quand au moins deux utilisateurs tentent de fusionner des modifications sur les mêmes lignes d’un fichier dans une branche courante et que Git ne peut pas choisir les modifications « appropriées » à appliquer. Les conflits de fusion peuvent se produire quand un utilisateur tente d’extraire ou de fusionner des modifications d’une autre branche dans une branche avec des modifications non validées.

Si une opération telle que l’extraction, le rebasage ou la fusion provoque un conflit de fusion, l’interface utilisateur de Dossiers Git affiche une liste de fichiers présentant des conflits, ainsi que des options pour les résoudre.

Vous avez deux options principales :

• Utilisez l’interface utilisateur des dossiers Git pour résoudre le conflit.
• Abandonnez l’opération Git, ignorez manuellement les modifications apportées au fichier en conflit, puis réessayez l’opération Git.

Lors de la résolution de conflits de fusion avec l’interface utilisateur de Dossiers Git, vous devez choisir entre la résolution manuelle des conflits dans l’éditeur ou la conservation de toutes les modifications actuelles ou à venir.

Conserver toutes les modifications actuelles ou Accepter les modifications à venir

Si vous savez que vous voulez uniquement conserver toutes les modifications actuelles ou à venir, cliquez sur le kebab à droite du nom de fichier dans votre volet de notebook et sélectionnez Conserver toutes les modifications actuelles ou Accepter les modifications à venir. Cliquez sur le bouton avec la même étiquette pour valider les modifications et résoudre le conflit.

Conseil

Êtes-vous perplexe au niveau de l’option à sélectionner ? La couleur de chaque option correspond aux modifications de code respectives conservées dans le fichier.

Résolution manuelle des conflits

La résolution manuelle de conflits vous permet de déterminer les lignes en conflit qui peuvent être acceptées dans la fusion. Pour les conflits de fusion, vous les résolvez en modifiant directement le contenu du fichier avec les conflits.

Pour résoudre le conflit, sélectionnez les lignes de code que vous souhaitez conserver et supprimer tout le reste, notamment les marqueurs de conflit de fusion Git. Une fois terminé, sélectionner Marquer comme résolu.

Si vous décidez que vous avez effectué les mauvais choix lors de la résolution des conflits de fusion, cliquez sur le bouton Abandonner pour abandonner le processus et annuler tout. Une fois tous les conflits résolus, cliquez sur l’option Poursuivre la fusion ou Continuer le rebasage pour résoudre le conflit et effectuer l’opération.

Git reset

Dans Dossiers Git Databricks, vous pouvez effectuer une opération reset Git dans l’interface utilisateur Azure Databricks. La réinitialisation Git dans Dossiers Git Databricks équivaut à git reset --hard combiné avec git push --force.

La réinitialisation de Git remplace le contenu et l’historique de la branche par l’état le plus récent d’une autre branche. Vous pouvez l’utiliser lorsque les modifications sont en conflit avec la branche en amont et que vous n’hésitez pas à perdre ces modifications lorsque vous réinitialisez la branche en amont. Découvrez-en plus sur reset –hard de Git.

Rétablir une branche amont (distante)

Avec git reset dans ce scénario :

• Vous réinitialisez votre branche sélectionnée (par exemple, feature_a) à une autre branche (par exemple, main).
• Vous réinitialisez également la branche feature_a en amont (distante) sur la branche primaire.

Important

Lorsque vous réinitialisez, vous perdez toutes les modifications validées et non validées dans la version locale et distante de la branche.

Pour réinitialiser une branche à une branche distante :

1. Dans le menu Branche de l’interface utilisateur de Dossiers Git, choisissez la branche que vous souhaitez réinitialiser.

   

2. Sélectionnez Réinitialiser dans le menu kebab.

   

3. Sélectionnez la branche à réinitialiser.

   

Configurer le mode de basculement partiel sur une branche (Sparse Checkout)

Basculement partiel sur une branche (Sparse Checkout) est un paramètre côté client qui vous permet de cloner et de travailler avec seulement un sous-ensemble des répertoires des dépôts distants dans Databricks. Cela est particulièrement utile si la taille de votre dépôt dépasse les limites prises en charge par Databricks.

Vous pouvez utiliser le mode de basculement partiel sur une branche (Sparse Checkout) lors de l’ajout (clonage) d’un nouveau dépôt.

1. Dans la boîte de dialogue Ajouter un dossier Git, ouvrez Avancé.

2. Sélectionnez Mode de basculement partiel sur une branche (Sparse Checkout) .

   

3. Dans la zone Modèles de cône, spécifiez les modèles de basculement sur une branche de cône souhaités. Séparez plusieurs modèles par des sauts de ligne.

Pour l’instant, vous ne pouvez pas désactiver le basculement partiel sur une branche pour un dépôt dans Azure Databricks.

Fonctionnement des modèles de cône

Pour comprendre le fonctionnement du modèle de cône en mode de basculement partiel sur une branche (Sparse Checkout), consultez le diagramme suivant représentant la structure d’un dépôt distant.

Si vous sélectionnez Mode de basculement partiel sur une branche (Sparse Checkout), mais que vous ne spécifiez pas de modèle de cône, le modèle de cône par défaut est appliqué. Cela inclut uniquement les fichiers à la racine et aucun sous-répertoire, ce qui produit une structure de dépôt semblable à la suivante :

La définition du modèle de cône de basculement partiel sur une branche sur parent/child/grandchild entraîne l’inclusion récursive de tout le contenu du répertoire grandchild. Les fichiers se trouvant immédiatement dans le répertoire /parent, /parent/child et racine sont également inclus. Consultez la structure de répertoires dans le diagramme suivant :

Vous pouvez ajouter plusieurs modèles séparés par des sauts de ligne.

Remarque

Les comportements d’exclusion (!) ne sont pas pris en charge dans la syntaxe du modèle de cône Git.

Modifier les paramètres de basculement partiel sur une branche

Une fois qu’un dépôt est créé, le modèle de cône de basculement partiel sur une branche peut être modifié à partir de Paramètres > Avancés > Modèles de cône.

Notez le comportement suivant :

• La suppression d’un dossier du modèle de cône le supprime de Databricks en l’absence de modification non validée.

• L’ajout d’un dossier via la modification du modèle de cône de basculement partiel sur une branche l’ajoute à Databricks sans nécessiter une opération tirer (pull) supplémentaire.

• Les modèles de basculement partiel sur une branche (Sparse Checkout) ne peuvent pas être modifiés pour supprimer un dossier quand ce dernier contient des changements non indexés.

  Par exemple, un utilisateur modifie un fichier dans un dossier et ne commite pas les changements. Il tente ensuite de changer le modèle de basculement partiel sur une branche (Sparse Checkout) pour ne pas inclure ce dossier. Dans ce cas, le modèle est accepté, mais le dossier réel n’est pas supprimé. Il doit rétablir le modèle pour inclure ce dossier, commiter les changements, puis réappliquer le nouveau modèle.

Notes

Vous ne pouvez pas désactiver le basculement partiel sur une branche pour un dépôt qui a été créé avec le mode de basculement partiel sur une branche (Sparse Checkout) activé.

Apporter et envoyer (push) des modifications avec un basculement partiel sur une branche

Vous pouvez modifier des fichiers existants, puis les valider et les envoyer à partir de l’interface de dossier Git. Lorsque vous créez des dossiers de fichiers, incluez-les dans le modèle de cône que vous avez spécifié pour ce référentiel.

L’inclusion d’un nouveau dossier en dehors du modèle de cône génère une erreur pendant l’opération de commit et d’envoi (push). Pour y remédier, modifiez le modèle de cône pour inclure le nouveau dossier que vous essayez de valider et d’envoyer.

Modèles pour un fichier de configuration de référentiel

Le fichier de configuration de validation des sorties utilise des modèles similaires aux modèles gitignore et effectue les opérations suivantes :

• Les modèles positifs permettent l’inclusion de sorties pour des notebooks correspondants.
• Les modèles négatifs désactivent l’inclusion de sorties pour des notebooks correspondants.
• Les modèles sont évalués dans l’ordre pour tous les notebooks.
• Les chemins d’accès non valides ou ceux qui ne sont pas résolus en notebooks .ipynb sont ignorés.

Modèle positif : pour inclure des sorties du chemin d’accès d’un notebook folder/innerfolder/notebook.ipynb, utilisez les modèles suivants :

**/*
folder/**
folder/innerfolder/note*

Modèle négatif : pour exclure des sorties d’un notebook, vérifiez qu’aucun des modèles positifs ne correspond ou n’ajoute un modèle négatif dans un emplacement correct du fichier de configuration. Les modèles négatifs (exclure) commencent par ! :

!folder/innerfolder/*.ipynb
!folder/**/*.ipynb
!**/notebook.ipynb

Limitation de la caisse éparse

L’extraction éparse ne fonctionne pas actuellement pour les référentiels Azure DevOps d’une taille supérieure à 4 Go.

Ajouter un dépôt et se connecter à distance ultérieurement

Pour gérer et utiliser des dossiers Git par programmation, utilisez l’API REST des dossiers Git.