Créer et gérer des dossiers Git

Cette page explique comment créer des dossiers Git Azure Databricks et effectuer des opérations Git courantes, notamment le clonage, la branchement, la validation et l’envoi (push) d’Azure Databricks.

Ce guide couvre les opérations Git suivantes :

Cloner un dépôt

Lorsque vous clonez un référentiel distant, Databricks crée un dossier Git dans votre espace de travail qui contient le contenu du référentiel et effectue le suivi des modifications. Vous pouvez créer des dossiers Git à l’aide de l’interface utilisateur Azure Databricks ou du terminal web.

Cloner depuis l’interface utilisateur

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

2. Cliquez sur Créer un>dossier Git.

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

   Champ	Descriptif
   URL du référentiel Git	URL du dépôt Git que vous souhaitez cloner, au format https://example.com/organization/project.git.
   Fournisseur Git	Fournisseur Git pour le référentiel que vous souhaitez cloner.
   Nom du dossier Git	Nom du dossier de votre espace de travail qui contient le contenu du dépôt cloné.
   Mode d’extraction éparse	Indique s’il faut utiliser l’extraction éparse, qui clone seul un sous-ensemble de répertoires de votre référentiel à l’aide d’un modèle en cône. Cela est utile si votre référentiel dépasse les limites de taille.

4. Cliquez sur Créer un dossier Git. Le contenu du référentiel distant est cloné dans votre espace de travail et vous pouvez commencer à utiliser les opérations Git prises en charge. Lorsque votre espace de travail est éligible, le dossier Git est créé automatiquement avec l’accès Git CLI . Voir Quand un dossier Git obtient-il l’accès à Git CLI ?.

Cloner à partir du terminal web

Vous pouvez également créer des dossiers Git avec un accès CLI directement à partir du terminal web :

1. Accédez au terminal web. Consultez Exécuter des commandes d’interpréteur de commandes dans un terminal web Azure Databricks.

2. Accédez au répertoire parent dans /Workspace:

   cd /Workspace/Users/<your-email>/<project>
   

3. Clonez votre référentiel :

   git clone <remote-url>
   

   La git clone commande utilise les informations d’identification Git configurées dans votre espace de travail. Consultez Connecter votre fournisseur Git à Databricks.

4. Actualisez votre navigateur pour afficher le nouveau dossier dans le navigateur de fichiers de l’espace de travail.

Utiliser les commandes Git en ligne de commande

Les dossiers Git avec accès Git CLI vous permettent d’exécuter des commandes Git standard sur le calcul serverless, à partir d’un notebook, d’un terminal web ou d’un code Genie. Vous pouvez:

• Exécutez n’importe quelle commande Git, y compris git stash, git push --forceet git rebase -i.
• Intégrez le linting et l'analyse du code à des hooks de pré-commit.
• Utilisez des référentiels qui dépassent les limites de 2 Go de mémoire et de 4 Go de disques de dossiers Git standard.
• Utilisez des sous-modules Git et un stockage de fichiers volumineux (LFS).
• Effectuez plusieurs validations localement avant d’envoyer (push) vers le référentiel distant.

Exigences informatiques de la CLI Git

Le calcul requis dépend de la façon dont vous utilisez un dossier Git prenant en charge l’interface CLI :

Pour activer le calcul sans serveur (serverless), consultez Se connecter au calcul sans serveur (serverless).

Si votre fournisseur Git nécessite une connectivité réseau privée, consultez Configurer la connectivité réseau.

Quand un dossier Git obtient-il un accès à Git CLI ?

Lorsque vous créez un dossier Git à partir de l’interface utilisateur, Azure Databricks active automatiquement l’accès à Git CLI si votre espace de travail est éligible. Si votre espace de travail n'est pas éligible, Azure Databricks crée un dossier Git standard à la place et vous pouvez toujours effectuer des opérations Git à partir de l'interface utilisateur des dossiers Git.

Un dossier Git que vous créez à partir de l’interface utilisateur obtient l’accès Git CLI lorsque toutes les valeurs suivantes sont vraies :

• La préversion git CLI est activée pour votre espace de travail. Les administrateurs de l’espace de travail contrôlent cela à partir de la page Aperçus . Consultez Gérer les préversions d’Azure Databricks.
• Le calcul serverless est disponible dans votre espace de travail. Voir Connexion à l'informatique sans serveur.
• Azure Databricks peut accéder à votre fournisseur Git depuis un environnement de calcul sans serveur. Azure Databricks vérifie la connectivité avant de cloner le référentiel. Si votre fournisseur Git nécessite une connectivité réseau privée, consultez Configurer la connectivité réseau.
• Pendant la préversion publique, les dépôts sont limités à 10 000 fichiers. Les dépôts qui dépassent cette limite sont clonés en tant que dossiers Git standard à la place.

Les dossiers Git que vous clonez à partir du terminal web ont toujours accès à Git CLI.

Créer un dossier Git avec accès à Git CLI

Pour créer un dossier Git avec accès CLI :

• Si vous utilisez l’interface utilisateur, Azure Databricks crée automatiquement le dossier Git avec l’accès Git CLI lorsque votre espace de travail est éligible. Voir Quand un dossier Git obtient-il l’accès à Git CLI ?. Si votre espace de travail n'est pas éligible, Azure Databricks crée un dossier Git standard à la place.
• Si vous utilisez le terminal web, tout dépôt que vous clonez dispose automatiquement de l’accès à l’interface CLI Git.

Après avoir créé un dossier Git avec accès CLI, exécutez n’importe quelle commande Git standard à partir du terminal web. Pour ouvrir un terminal web, consultez Lancer le terminal web.

cd /Workspace/Users/<your-email>/<project>/my-repo

# Interactive rebase
git rebase -i main

# Stash uncommitted changes
git stash

# Work with submodules
git submodule update --init --recursive

Limitations de l’interface CLI Git

Les dossiers Git avec accès CLI présentent les limitations suivantes :

• Les listes d'autorisation d'URL Git s'appliquent aux opérations Git que vous exécutez à partir de l'interface utilisateur Azure Databricks, mais ne sont pas appliquées pour les commandes Git que vous exécutez directement avec l'interface cli Git.
• Les dossiers Git avec accès Git CLI ne sont pas retournés par l'API List Repos.

Résoudre les problèmes liés aux opérations Git CLI

• Les opérations Git sont désactivées dans l’interface utilisateur de l’espace de travail : le calcul serverless n’est pas activé dans votre espace de travail. Vous pouvez toujours exécuter des commandes Git à partir du terminal web. Pour activer le calcul sans serveur (serverless), consultez Se connecter au calcul sans serveur (serverless).
• Le terminal vous invite à sélectionner des informations d’identification : les opérations Git CLI utilisent automatiquement les informations d’identification Git de votre espace de travail stocké. Azure Databricks déduit le fournisseur Git à partir de l’URL distante et utilise les informations d’identification par défaut pour ce fournisseur. Si Azure Databricks ne pouvez pas identifier d'informations d'identification uniques à utiliser, vous êtes invité à en sélectionner un. Pour éviter l’invite, définissez la DB_GIT_CREDENTIAL_NAME variable d’environnement sur le nom des informations d’identification que vous souhaitez utiliser. Azure Databricks mémorise les informations d’identification que vous utilisez pour un référentiel et la réutilise.
• Les opérations Git échouent avec des erreurs d’autorisation : vérifiez que vous disposez CAN MANAGE d’autorisations sur le dossier parent et que vos informations d’identification Git de votre espace de travail sont valides. Consultez Connecter votre fournisseur Git à Databricks.

Accéder à la boîte de dialogue Git

Accédez à la boîte de dialogue Git à partir d’un notebook ou à partir du navigateur de dossiers Git Azure Databricks.

• À partir d’un bloc-notes, cliquez sur le bouton en regard du nom du bloc-notes qui identifie la branche Git actuelle.

  

• Dans le navigateur des dossiers Git Azure Databricks, cliquez sur Git en regard du nom du dépôt.

Une boîte de dialogue plein écran s’affiche 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, la modification de la branche modifie également la branche pour eux s’ils partagent le même espace de travail. Consultez la meilleure pratique recommandée pour éviter ce problème.
2. Créez une branche.
3. Ressources de fichiers et sous-dossiers archivés dans votre branche actuelle.
4. Afficher l’historique de la branche actuelle.
5. Extrayez du contenu à partir du référentiel Git distant.
6. Ajoutez un message de validation et une description développée facultative pour vos modifications.
7. Validez votre travail sur la branche de travail et envoyez la branche mise à jour au référentiel Git distant.

Cliquez sur pour choisir parmi d’autres opérations de branche Git, telles qu’une réinitialisation en dur, une fusion ou un rebase.

Créer une branche

Pour créer une branche :

1. Ouvrez la boîte de dialogue Git.
2. Cliquez sur Créer une branche.
3. Entrez un nom pour la nouvelle branche et sélectionnez la branche de base.
4. Cliquez sur Créer.

Basculer vers une autre branche

Pour changer de branche, utilisez le menu déroulant des branches dans la fenêtre Git :

Les modifications non validées sur la branche actuelle continuent et s’affichent comme des modifications non validées sur la nouvelle branche, si les modifications non validées ne sont pas en conflit avec le code sur la nouvelle branche. Abandonnez les modifications avant ou après les changements de branche si vous n’avez pas l’intention de transmettre les modifications non validées.

La version locale d’une branche peut rester présente dans le dossier Git associé pendant jusqu’à 30 jours après la suppression de la branche distante. Pour supprimer complètement une branche locale dans un dossier Git, supprimez le référentiel.

Valider et envoyer (push) les modifications

Lorsque vous ajoutez de nouveaux blocs-notes ou fichiers, ou apportez des modifications aux blocs-notes ou fichiers existants, l’interface utilisateur du dossier Git met en surbrillance les modifications.

Ajoutez un message de validation requis pour les modifications, puis cliquez sur Commit &Push pour envoyer (push) les modifications vers le référentiel Git distant.

Si vous n’êtes pas autorisé à valider des modifications dans la branche par défaut, créez une nouvelle branche et utilisez l’interface de votre fournisseur Git pour créer une pull request et la fusionner dans la branche par défaut.

Créer dans un dossier Git tout en agissant en tant que rôle

Avec RBAC, vous assumez un rôle pour accéder aux données délimitées à ce rôle. Pour créer du code qui lit ces données, vous assumez le rôle afin que son accès aux données soit en vigueur, puis validez vos modifications. Vous pouvez effectuer un commit soit avec votre propre identité utilisateur, soit avec le rôle. Le choix détermine la manière dont votre fournisseur Git attribue les commits, en contrepartie du niveau de configuration requis par le workflow. Les deux dépendent des informations d’identification Git du rôle.

Valider avec votre identité utilisateur

Dans cette approche, vous effectuez des commits avec vos identifiants Git personnels, de sorte que votre fournisseur Git vous attribue ces commits. Vous endossez ce rôle uniquement pour modifier les données auxquelles il peut accéder, puis vous revenez à votre identité d’utilisateur pour valider vos modifications. Étant donné que vous créez des modifications en tant que rôle, mais que vous les validez sous votre identité utilisateur, le dossier Git doit être accessible via ces deux identités. Configurez-le de deux façons, qui diffèrent selon les personnes qui possèdent le dossier et la direction que vous partagez.

Option 1 : Cloner dans votre dossier d’accueil et le partager avec le rôle

1. En tant qu’identité utilisateur (ne supposez pas le rôle), clonez le référentiel dans un dossier Git dans votre dossier d’accueil (/Workspace/Users/<your-username>/...). Consultez Cloner un dépôt. Le clone utilise vos informations d’identification Git personnelles et vous êtes propriétaire du dossier. Le rôle n’a pas besoin de ses propres informations d’identification Git pour cette option.
2. Accordez l’accès au rôle au dossier (peut s’exécuter ou modifier si le rôle doit modifier des fichiers) afin de pouvoir y travailler tout en agissant comme rôle.
3. Assumez le rôle, puis apportez vos modifications dans le dossier. L’accès aux données du rôle est actif.
4. Revenez à votre identité utilisateur, puis validez et envoyez(push). La validation utilise votre code personnel git_username et git_email.

Étant donné que vous partagez le dossier de votre identité utilisateur vers le rôle, les contrôles de partage des ressources de l’espace de travail n’affectent pas cette option. Ces contrôles limitent uniquement un rôle du partage des ressources vers l’extérieur.

Option 2 : Cloner dans le dossier d’accueil du rôle et le partager avec votre identité utilisateur

1. Assumez le rôle et clonez le référentiel dans un dossier Git dans le dossier d’accueil du rôle. L’opération de clonage utilise les identifiants Git du rôle, lesquels doivent disposer au minimum d’un accès en lecture.
2. Tout en agissant en tant que rôle, accordez à votre identité utilisateur l’accès au dossier (Peut modifier).
3. Apportez vos modifications tout en jouant ce rôle. L’accès aux données du rôle est actif.
4. Revenez à votre identité utilisateur. Comme vous avez accordé l’accès à votre utilisateur, vous pouvez accéder au dossier, donc effectuez un commit et un push avec vos identifiants personnels. La validation utilise votre code personnel git_username et git_email.

Étant donné que le rôle partage le dossier avec votre identité utilisateur, cette option ne fonctionne pas si le rôle figure sur la liste de blocage des contrôles de partage des ressources de l’espace de travail. Utilisez l’option 1 pour ces rôles.

Valider en tant que rôle

Dans cette approche, vous clonez, créez et validez tout en agissant comme rôle. Il s’agit du flux de travail le plus simple : vous ne partagez pas de dossier et n’avez pas à changer d’identité pour effectuer un commit. Cela nécessite que les identifiants Git du rôle disposent d’un accès en écriture, car l’interface utilisateur de l’espace de travail effectue le commit et le push en une seule action.

1. Assumez le rôle.
2. Clonez le référentiel dans un dossier Git. Étant donné que vous jouez le rôle, le clone utilise les informations d’identification Git du rôle.
3. Apportez vos modifications, puis validez et envoyez(push). La validation utilise le rôle git_username et git_email.

Pèsez ces implications avant de choisir cette approche :

• L’attribution se fait au niveau du rôle. Les validations dans votre fournisseur Git indiquent l’identité Git du rôle, et non l’auteur individuel. Les journaux d’audit d’Azure Databricks enregistrent à la fois identity_metadata.run_as (le rôle) et identity_metadata.run_by (vous) pour les validations effectuées via l’interface utilisateur de l’espace de travail. Cela ne s’applique pas aux validations Git brutes exécutées à partir de l’interface de ligne de commande Git dans un terminal web, ce qui Azure Databricks n’est pas attribué à un utilisateur individuel.
• L’identifiant Git du rôle est partagé et doté d’un accès en écriture. Toutes les personnes qui endossent ce rôle utilisent les mêmes identifiants pour effectuer des pushs ; ainsi, un jeton divulgué ou utilisé à mauvais escient peut servir à effectuer des pushs, à supprimer des branches ou à créer des commits sous l’identité du rôle. Pour cette raison, Azure Databricks recommande des informations d’identification Git de groupe en lecture seule et l’approche consistant à effectuer le commit avec votre identité utilisateur. Utilisez des identifiants dotés de droits d’écriture uniquement lorsque vous acceptez ces compromis. Voir Autorisations du jeton. Limitez les informations d’identification aux référentiels dont le rôle a besoin.

Modifications de tirage (pull)

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 automatiquement mis à jour vers la dernière version de votre dépôt Git distant. Si les modifications extraites du dépôt distant sont en conflit avec vos modifications locales dans Azure Databricks, résolvez les conflits de fusion.

Collaborer dans des dossiers Git

Les dossiers Git Azure Databricks se comportent en tant que clients Git incorporés dans votre espace de travail, ce qui vous permet de collaborer via le contrôle de code source et le contrôle de version Git. Pour une collaboration efficace d’équipe :

• Chaque membre de l’équipe possède son propre dossier Git mappé au dépôt Git distant, où il travaille dans sa propre branche de développement.
• Un seul utilisateur effectue des opérations Git sur chaque dossier Git. Plusieurs utilisateurs effectuant des opérations Git sur le même dossier peuvent entraîner des problèmes de gestion des branches, tels qu’un utilisateur qui bascule involontairement des branches pour tout le monde.

Pour partager votre configuration de dossier Git avec un collaborateur :

1. Cliquez sur Partager.
2. Cliquez sur Copier le lien pour créer un dossier Git.
3. Envoyez l’URL à votre collaborateur.
4. Lorsque votre collaborateur ouvre l’URL, une boîte de dialogue est préremplie avec la configuration de votre dossier Git.
5. Ils cliquent sur Créer un dossier Git pour cloner le référentiel dans leur propre espace de travail sous leur dossier de travail actuel.

Fusionner des branches

La fonction de fusion dans les dossiers Git Azure Databricks utilise git merge pour combiner l’historique de validation d’une branche vers une autre. Pour les débutants Git, Databricks recommande d’utiliser la fusion au lieu de la rebase, car elle ne nécessite pas d’envoi de force et ne réécrit pas l’historique de validation.

Pour fusionner une branche dans une autre, cliquez sur Menu Kebab et sélectionnez Fusionner.

• En cas de conflit de fusion, résolvez-le dans l’interface utilisateur des dossiers Git.
• En l'absence de conflit, la fusion pousse vers le référentiel Git distant à l'aide de git push.

Résoudre les conflits de fusion

Les conflits de fusion se produisent lorsque Git ne peut pas rapprocher automatiquement les modifications apportées aux mêmes lignes d’un fichier provenant de différentes sources, telles que lors d’une opération d’extraction, de rebase ou de fusion.

Pour résoudre un conflit de fusion, utilisez l’interface utilisateur des dossiers Git qui affiche les fichiers en conflit et les options de résolution.

• Modifiez manuellement le fichier pour choisir les modifications à conserver.
• Sélectionnez Conserver toutes les modifications actuelles ou Prendre toutes les modifications entrantes pour accepter entièrement une version.
• Abandonnez l’opération et ignorez les modifications en conflit pour réessayer.

Résoudre manuellement les conflits

La résolution manuelle des conflits vous permet de déterminer les lignes en conflit à accepter. Modifiez directement le contenu du fichier pour résoudre 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. Lorsque vous avez terminé, sélectionnez Marquer comme résolu.

Si vous avez fait des choix incorrects lors de la résolution des conflits de fusion, cliquez sur Abandonner pour abandonner le processus et annuler tout. Une fois que tous les conflits sont résolus, cliquez sur Continuer la fusion ou Continuer la rebase pour résoudre le conflit et terminer l’opération.

Rebaser une branche

La fonction de rebasage dans les dossiers Git Azure Databricks utilise git rebase pour intégrer les changements d'une branche dans une autre en réappliquant vos commits sur la branche cible, ce qui crée un historique linéaire.

Pour Kebab menu icon.rebaser une branche sur une autre branche, cliquez sur Menu Kebab, puis sélectionnez Rebase, puis sélectionnez la branche cible.

• Après le rebasage, exécutez les commandes Git git commit et git push --force pour mettre à jour le référentiel distant.
• Rebase réécrit l’historique des validations, ce qui peut entraîner des problèmes de contrôle de version pour les collaborateurs travaillant dans le même référentiel.

Réinitialiser une branche

Effectuez une réinitialisation Git à partir de l’interface utilisateur des dossiers Git. Cette opération est équivalente à 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’avez pas l’esprit de perdre ces modifications lorsque vous réinitialisez la branche en amont. En savoir plus sur git reset --hard.

Réinitialiser à une branche 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.

Pour réinitialiser une branche vers 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 à partir de .

   

3. Sélectionnez la branche à réinitialiser, puis cliquez sur Exécuter la réinitialisation Git.

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

L'extraction parsemée est un paramètre côté client qui vous permet de cloner et de travailler uniquement avec un sous-ensemble des répertoires du référentiel distant dans Azure Databricks. Cela est particulièrement utile si la taille de votre référentiel dépasse les limites prises en charge par Azure Databricks.

Activez le mode d’extraction éparse lorsque vous clonez un nouveau dépôt. Vous ne pouvez pas désactiver le mode d’extraction de façon clairsemée après l’avoir activé.

1. Dans la boîte de dialogue Créer un dossier Git , activez le mode d’extraction éparse.

   

2. Dans la zone Modèles de cône, spécifiez les modèles de validation de cône souhaités. Séparez plusieurs modèles par des sauts de ligne.

Fonctionnement des modèles de cône

Pour comprendre le fonctionnement des modèles de cône en mode de vérification éparse, consultez le diagramme suivant représentant la structure du dépôt distant.

Si vous sélectionnez le mode d’extraction éparse, mais que vous ne spécifiez pas de modèle de cône, le modèle de cône par défaut s’applique. Cela inclut uniquement les fichiers à la racine, sans sous-répertoires, ce qui entraîne une structure de dépôt comme suit :

La définition de manière récursive du modèle de cône d'extraction éparse comme parent/child/grandchild inclut 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 :

Modifier les paramètres de checkout clairsemé

Après avoir créé un dépôt, modifiez le modèle de cône d’extraction épars depuis Paramètres>Avancé>Modèles de cône.

Notez le comportement suivant :

• La suppression d’un dossier du modèle cône le supprime d’Azure Databricks s’il n’existe aucune modification non validée.

• L’ajout d’un dossier en modifiant le modèle de cône de vérification restreinte le synchronise avec Azure Databricks sans nécessiter de pull supplémentaire.

• Les modèles d’extractions par sélection partielle ne peuvent pas être modifiés pour retirer un dossier lorsqu’il existe des modifications non validées dans ce dossier.

  Par exemple, si vous modifiez un fichier dans un dossier et que vous ne validez pas les modifications, essayez de modifier le modèle d’extraction éparse pour exclure ce dossier, le modèle est accepté, mais le dossier n’est pas supprimé. Vous devez rétablir le modèle pour inclure ce dossier, valider vos modifications, puis réappliquer le nouveau modèle.

Apporter des modifications avec l’extraction éparse

Modifiez les fichiers existants et validez-les et envoyez-les à partir du 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 résoudre ce problème, modifiez le modèle de cône pour inclure le nouveau dossier que vous essayez de valider et d’envoyer (push).

Limitations de l'extraction éparse

• L’extraction éparse ne fonctionne pas pour les référentiels Azure DevOps de plus de 4 Go.
• Vous ne pouvez pas désactiver l’extraction éparse pour un dépôt créé avec l’activation de l’extraction éparse.

Gérer les dossiers Git par programmation

Pour gérer les dossiers Git à l’aide de l’API, consultez la référence de l’API Repos.

Supprimer un dossier Git

Pour supprimer un dossier Git de votre espace de travail :

1. Cliquez avec le bouton droit sur le dossier Git et sélectionnez Déplacer vers la corbeille.
2. Cliquez sur Confirmer et déplacer vers la Corbeille.

Étapes suivantes

• Configurez l’authentification pour connecter Azure Databricks à votre fournisseur Git. Consultez Connecter votre fournisseur Git à Databricks.
• Découvrez les limites de taille et d’autres contraintes pour les dossiers Git. Consultez Azure Databricks limites et références des dossiers Git.
• Configurez les paramètres au niveau de l’espace de travail pour l’intégration Git. Consultez Configurer l’intégration Git pour les dossiers Git.