Créer et gérer des dossiers Git

Cette page décrit comment créer des dossiers Git Databricks et effectuer des Opérations Git courantes, y compris le clonage, le branchement, le commit et le push.

Ce guide couvre les Opérations Git suivantes :

Configuration et installation	Workflow quotidien	Opérations avancées
Cloner un référentiel Utiliser la CLI Git Accéder à la boîte de dialogue Git	Créer une nouvelle Branch Passer à une autre branch commit et envoyez les modifications. Extraire les modifications Collaborer dans des dossiers Git	Merge branches. Résoudre les conflits de merge Baser à nouveau une Branch Reset une branch Configurer le sparse checkout Supprimer un dossier Git

Configuration et installation	Workflow quotidien	Opérations avancées
Cloner un référentiel Utiliser la CLI Git Accéder à la boîte de dialogue Git	Créer une nouvelle Branch Passer à une autre branch commit et envoyez les modifications. Extraire les modifications Collaborer dans des dossiers Git	Merge branches. Résoudre les conflits de merge Baser à nouveau une Branch Reset une branch Configurer le sparse checkout Supprimer un dossier Git

Cloner un référentiel

Lorsque vous clonez un repository distant, Databricks crée un dossier Git dans votre Workspace qui contient le contenu du repo et suit les modifications. Vous pouvez créer des dossiers Git à l'aide de l'interface utilisateur de Databricks ou du terminal web.

remarque

• Vous devez disposer de la permission CAN MANAGE sur le dossier parent où vous souhaitez créer le dossier Git.
• Votre Workspace doit avoir des identifiants Git configurés. Voir Connecter votre fournisseur Git à Databricks.

Cloner depuis l'interface utilisateur

1. Dans la barre latérale, sélectionnez **Workspace** et accédez au dossier où vous souhaitez créer le clone du dépôt Git.

2. Cliquez sur Créer > Dossier Git .

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

Champ	Description
URL du repository Git	L'URL du repository Git que vous souhaitez cloner, au format https://example.com/organization/project.git.
Fournisseur Git	Le fournisseur Git du repository que vous souhaitez cloner.
Nom du dossier Git	Le nom du dossier dans votre Workspace qui contient le contenu du dépôt cloné.
Mode de récupération fragmentée	Indique s'il convient d'utiliser le checkout éparse, qui clone uniquement un sous-ensemble des répertoires de votre repository à l'aide d'un motif en cône. Ceci est utile si votre repository dépasse les limites de taille.

Champ	Description
URL du repository Git	L'URL du repository Git que vous souhaitez cloner, au format https://example.com/organization/project.git.
Fournisseur Git	Le fournisseur Git du repository que vous souhaitez cloner.
Nom du dossier Git	Le nom du dossier dans votre Workspace qui contient le contenu du dépôt cloné.
Mode de récupération fragmentée	Indique s'il convient d'utiliser le checkout éparse, qui clone uniquement un sous-ensemble des répertoires de votre repository à l'aide d'un motif en cône. Ceci est utile si votre repository dépasse les limites de taille.

4. Cliquez sur Créer un dossier Git . Le contenu du repository distant est cloné vers votre Workspace, et vous pouvez start à travailler avec les opérations Git prises en charge. Lorsque votre Workspace est éligible, le dossier Git est créé automatiquement avec l'accès à l'interface de programmation Git. Voir Quand un dossier Git obtient-il l'accès à l'interface CLI Git ?

Cloner à partir du terminal web

Vous pouvez également créer des dossiers Git avec accès CLI directement depuis le terminal web :

1. Accédez au terminal web. Consultez Exécuter des commandes Shell dans le terminal web Databricks.

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

   Bash

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

3. Cloner votre repository :

   Bash

   git clone <remote-url>

   La commande git clone utilise les identifiants Git configurés dans votre Workspace. Consultez Connecter votre fournisseur Git à Databricks.

4. refresh votre navigateur pour voir le nouveau dossier dans le navigateur de fichiers du Workspace.

Utiliser les commandes Git CLI

info

Aperçu

Cette fonctionnalité est en Aperçu public. Les administrateurs de Workspace peuvent contrôler l'accès à la prise en charge de Git CLI pour les dossiers Git depuis la page Aperçus . Consultez Gérer les aperçus Databricks.

Les dossiers Git avec accès à la CLI Git vous permettent d'exécuter des commandes Git standard sur le compute serverless, depuis un notebook, le terminal web ou Genie Code. Vous pouvez :

• Exécutez n’importe quelle commande Git, notamment git stash, git push --force et git rebase -i.
• Intégrez le linting et l'analyse de code avec des hooks de pré-commit.
• Travaillez avec des repositories qui dépassent les limites de 2 Go de mémoire et de 4 Go de disque des dossiers Git standards.
• Utilisez les sous-modules Git et le stockage de fichiers volumineux (LFS).
• Stager plusieurs commits localement avant de les pousser vers le repository distant.

Exigences de compute CLI Git

Le compute requis dépend de la façon dont vous utilisez un dossier Git compatible CLI :

Opérations	Exigence de compute
Créer un dossier Git avec accès CLI depuis l'interface utilisateur	Compute serverless
Exécuter les opérations Git à partir de l’interface utilisateur des dossiers Git (pull, push, commit)	Compute serverless
Exécutez les commandes Git CLI depuis un notebook, le terminal Web ou Genie Code.	compute serverless (version d'environnement 5 ou ultérieure) ou compute classique (Databricks Runtime 17.0 ou ultérieure)

Opérations	Exigence de compute
Créer un dossier Git avec accès CLI depuis l'interface utilisateur	Compute serverless
Exécuter les opérations Git à partir de l’interface utilisateur des dossiers Git (pull, push, commit)	Compute serverless
Exécutez les commandes Git CLI depuis un notebook, le terminal Web ou Genie Code.	compute serverless (version d'environnement 5 ou ultérieure) ou compute classique (Databricks Runtime 17.0 ou ultérieure)

Pour activer le compute serverless, voir Se connecter au compute serverless.

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

remarque

Vous pouvez également exécuter des commandes Git CLI à partir d'un IDE ou d'un terminal connecté au compute Databricks via un tunnel SSH. Cela répond aux exigences de compute pour les commandes Git CLI dans le terminal.

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

Lorsque vous créez un dossier Git depuis l'interface utilisateur, Databricks active automatiquement l'accès Git CLI si votre workspace est éligible. Si votre workspace n'est pas éligible, Databricks crée un dossier Git standard à la place, et vous pouvez toujours effectuer des opérations Git depuis 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 conditions suivantes sont remplies :

• L'aperçu de la CLI Git est activé pour votre workspace. Les administrateurs du Workspace contrôlent cela depuis la page **Prévisualisation**. Voir Gérer les aperçus Databricks.
• Le compute serverless est disponible dans votre workspace. Voir Se connecter au compute serverless.
• Databricks peut atteindre votre fournisseur Git à partir du compute serverless. Databricks vérifie la connectivité avant de cloner le repository. Si votre fournisseur Git nécessite une connectivité réseau privée, consultez Configurer la connectivité réseau.
• Pendant l'Aperçu public, les repositories sont limités à 10 000 fichiers. Les repositories qui dépassent cette limite sont clonés en tant que dossiers Git standard à la place.

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

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

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

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

Après avoir créé un dossier Git avec accès CLI, exécutez toute commande Git standard depuis le terminal web . Pour ouvrir un terminal web, consultez Lancer le terminal web.

Bash

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 la CLI Git

Les dossiers Git avec accès CLI ont les limitations suivantes :

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

Dépanner les opérations Git CLI

• Les opérations Git sont désactivées dans l'interface utilisateur du Workspace : le compute Serverless n'est pas activé dans votre Workspace. Vous pouvez toujours exécuter des commandes Git depuis le terminal web. Pour activer le compute serverless, consultez Connectez-vous au compute serverless.
• Le terminal vous invite à sélectionner un identifiant : les opérations Git CLI utilisent automatiquement vos identifiants Git de workspace stockés. Databricks déduit le fournisseur Git de l'URL distante et utilise l'identifiant default pour ce fournisseur. Si Databricks ne peut pas identifier un seul identifiant à utiliser, vous êtes invité à en sélectionner un. Pour éviter l'invite, définissez la variable d'environnement DB_GIT_CREDENTIAL_NAME sur le nom de l'identifiant que vous souhaitez utiliser. Databricks mémorise l'identifiant que vous utilisez pour un repository et le réutilise.
• Les opérations Git échouent avec des erreurs d'autorisation : vérifiez que vous disposez de l'autorisation CAN MANAGE sur le dossier parent et que vos informations d'identification Git du Workspace sont valides. Consulter Connecter votre fournisseur Git à Databricks.

Accédez à la boîte de dialogue Git

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

• À partir d'un Notebook, cliquez sur le bouton à côté du nom du Notebook qui identifie la Branch Git actuelle.

  

• Depuis le navigateur de dossiers Git de Databricks, cliquez sur **Git** à côté du nom du repo.

Une boîte de dialogue plein écran apparaît où vous pouvez effectuer des opérations Git.

1. Votre Branch de travail actuelle. Vous pouvez sélectionner d'autres branches ici. Si d'autres utilisateurs ont accès à ce dossier Git, changer de Branch change également la Branch pour eux s'ils partagent le même Workspace. Consultez une bonne pratique recommandée pour éviter ce problème.
2. Créer une nouvelle Branch.
3. Actifs de fichiers et sous-dossiers enregistrés dans votre current branch.
4. Afficher l'historique de la Branch actuelle.
5. Extraire le contenu du repository Git distant.
6. Ajoutez un commit message et une description étendue facultative pour vos modifications.
7. Commit votre travail sur la branch de travail et poussez la branch mise à jour vers le repository Git distant.

Cliquez sur le menu kebab pour choisir parmi d'autres Opérations de Branch Git, telles qu'un Reset dur, un Merge ou un rebase.

Créez une nouvelle branch

Pour créer une nouvelle Branch :

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

Passer à une autre branch

Pour extraire une autre branch, utilisez le menu déroulant de la branch dans la boîte de dialogue Git :

Les modifications non validées sur la Branch actuelle sont reportées et apparaissent comme des modifications non validées sur la nouvelle Branch, si les modifications non validées n’entrent pas en conflit avec le code de la nouvelle Branch. Ignorez les modifications avant ou après les changements de Branch si vous n’avez pas l’intention de reporter les modifications non validées.

La version locale d'une Branch peut rester présente dans le dossier Git associé pendant un maximum de 30 jours après que vous avez supprimé la Branch distante. Pour supprimer complètement une locale Branch dans un dossier Git, supprimez le repository.

important

Le changement de branch pourrait entraîner la suppression des assets du Workspace si la nouvelle branch ne contient pas ces assets. Si vous revenez à la branch actuelle, les assets supprimés sont recréés avec de nouveaux identifiants et URL. Cette modification ne peut pas être annulée.

Si vous avez partagé ou mis en signet des assets d'un dossier Git, vérifiez que l'asset existe sur la nouvelle Branch avant de changer.

Commit et envoi des modifications

Lorsque vous ajoutez de nouveaux notebooks ou fichiers, ou que vous apportez des modifications à des notebooks ou fichiers existants, l'interface utilisateur du dossier Git met en évidence les modifications.

Ajoutez un message de commit obligatoire pour les modifications, puis cliquez sur Commit & Push pour envoyer les modifications au repository Git distant.

Si vous n'avez pas l'autorisation de commit sur la default Branch, créez une nouvelle Branch et utilisez l'interface de votre fournisseur Git pour créer une demande d'extraction et la Merge dans la default Branch.

remarque

Les sorties de notebook ne sont pas incluses par default dans les commits lorsque les notebooks sont enregistrés dans des formats de fichier source (.py, .scala, .sql, .r). Pour plus d'informations sur le commit des sorties de Notebook à l'aide du format IPYNB, consultez Contrôler les commits d'artefacts de sortie de Notebook IPYNB.

Rédiger dans un dossier Git en tant que rôle

info

Aperçu

Cette section s'applique au contrôle d'accès basé sur les rôles (RBAC), qui est en préversion publique.

Avec le RBAC, vous assumez un rôle pour accéder aux données dans le cadre de 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 effectif, puis commit vos modifications. Vous pouvez commit soit en tant que votre propre identité d'utilisateur, soit en tant que rôle. Le choix détermine comment votre fournisseur Git attribue les commits, en fonction du compromis avec la quantité de configuration que le workflow nécessite. Les deux dépendent de l'identifiant Git du rôle.

Approche	Commits attribués à	Compromis
Effectuez un commit avec votre identité d'utilisateur.	Vous, individuellement.	Plus de configuration : vous partagez le dossier Git afin qu'il soit accessible sous les deux identités, et revenez à votre identité d'utilisateur pour le commit. Fonctionne avec un identifiant de rôle en lecture seule.
Commit en tant que rôle	Le rôle.	Plus simple : vous agissez en tant que rôle et ne partagez pas de dossier. Les commits utilisent l'identité Git du rôle, et les identifiants Git du rôle doivent avoir un accès en écriture et sont partagés par toute personne qui assume le rôle.

Approche	Commits attribués à	Compromis
Effectuez un commit avec votre identité d'utilisateur.	Vous, individuellement.	Plus de configuration : vous partagez le dossier Git afin qu'il soit accessible sous les deux identités, et revenez à votre identité d'utilisateur pour le commit. Fonctionne avec un identifiant de rôle en lecture seule.
Commit en tant que rôle	Le rôle.	Plus simple : vous agissez en tant que rôle et ne partagez pas de dossier. Les commits utilisent l'identité Git du rôle, et les identifiants Git du rôle doivent avoir un accès en écriture et sont partagés par toute personne qui assume le rôle.

Effectuer un commit avec votre identité d’utilisateur

Dans cette approche, vous validez avec vos informations d'identification Git personnelles, ainsi votre fournisseur Git vous attribue les commits. Vous assumez le rôle uniquement pour rédiger par rapport aux données auxquelles le rôle peut accéder, puis vous revenez à votre identité d'utilisateur pour commit. Parce que vous rédigez en assumant le rôle, mais commit en tant que votre identité d'utilisateur, le dossier Git doit être accessible sous les deux identités. Configurez cela de deux manières, qui diffèrent selon le propriétaire du dossier et la direction dans laquelle vous le partagez.

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

1. En tant qu'identité de votre utilisateur (n'assumez pas le rôle), clonez le repository dans un dossier Git de votre dossier personnel (/Workspace/Users/<your-username>/...). Voir Cloner un repo. Le clone utilise vos identifiants Git personnels, et vous êtes propriétaire du dossier. Le rôle n'a pas besoin de ses propres identifiants Git pour cette option.
2. Accordez au rôle l'accès au dossier ( Exécution autorisée ou Modification autorisée si le rôle doit modifier des fichiers) afin que vous puissiez y travailler en tant que rôle.
3. Assumez le rôle, puis apportez vos modifications dans le dossier. L'accès aux données du rôle est en vigueur.
4. Retournez à votre identité d'utilisateur, puis commit et envoyez. Le commit utilise vos git_username et git_email personnels.

Parce que vous partagez le dossier de votre identité d'utilisateur au rôle, les contrôles de partage d'asset du Workspace n'affectent pas cette option. Ces contrôles limitent un rôle uniquement dans le partage des assets vers l'extérieur.

Option 2 : Cloner dans le dossier personnel du rôle et le partager avec votre identité d'utilisateur.

1. Endossez le rôle et clonez le repository dans un dossier Git du dossier personnel du rôle. Le clone utilise l'identifiant Git du rôle, qui doit avoir au moins un accès en lecture.
2. Lorsque vous agissez en tant que rôle, accordez à votre identité d'utilisateur l'accès au dossier (**Peutmodifier**).
3. Effectuez vos modifications en agissant en tant que rôle. L'accès aux données du rôle est en vigueur.
4. Revenez à votre identité d'utilisateur. Parce que vous avez accordé l'accès à votre utilisateur, vous pouvez atteindre le dossier, vous pouvez donc commit et pousser avec vos identifiants personnels. Le commit utilise vos git_username et git_email personnels.

Parce que le rôle partage le dossier vers votre identité d'utilisateur, cette option ne fonctionne pas si le rôle figure sur la liste de refus des contrôles de partage d'assets de Workspace. Utilisez l'option 1 pour ces rôles.

commit as the role

Dans cette approche, vous clonez, créez et effectuez des commits tout en agissant en tant que rôle. Il s'agit du flux de travail le plus simple : vous ne partagez pas de dossier ni ne changez d'identité pour effectuer un commit. Cela nécessite que l'identifiant Git du rôle dispose d'un accès en écriture, car l'IU du Workspace effectue des commits et des pushes en une seule action.

1. Assumer le rôle.
2. Clonez le repository dans un dossier Git. Puisque vous agissez en tant que rôle, le clone utilise l’identifiant Git du rôle.
3. Apportez vos modifications, puis commit et envoyez. Le commit utilise les git_username et git_email du rôle.

Pesez ces implications avant de choisir cette approche :

• L'attribution se fait au niveau du rôle. Les commits dans votre fournisseur Git montrent l'identité Git du rôle, et non l'auteur individuel. Les Logs d'audit de Databricks enregistrent à la fois identity_metadata.run_as (le rôle) et identity_metadata.run_by (vous) pour les commits effectués via l'interface utilisateur du Workspace. Ceci ne s'applique pas aux commits Git bruts exécutés depuis l'Git CLI dans un terminal web, que Databricks n'attribue pas à un utilisateur individuel.
• L'identifiant Git du rôle est partagé et activé en écriture. Tous ceux qui endossent le rôle utilisent le même identifiant pour envoyer des modifications. Par conséquent, un jeton divulgué ou mal utilisé peut envoyer des modifications, supprimer des Branch, ou effectuer des commit sous l'identité du rôle. Pour cette raison, Databricks recommande un identifiant Git de groupe en lecture seule et l'approche effectuer des commits avec votre identité d'utilisateur. Utilisez des identifiants avec accès en écriture uniquement si vous acceptez ces compromis. Consultez Autorisations du jeton. Restreignez l'identifiant aux seuls repository dont le rôle a besoin.

Extraire les modifications

Pour extraire les modifications du repository Git distant, cliquez sur Extraire dans la boîte de dialogue Opérations Git. Les Notebooks et autres fichiers sont mis à jour automatiquement vers la dernière version dans votre repository Git distant. Si les modifications extraites du dépôt distant entrent en conflit avec vos modifications locales dans Databricks, résolvez les conflits de merge.

important

Les Opérations Git qui extraient les modifications en amont effacent l'état du Notebook. Voir Les modifications entrantes effacent l'état du Notebook.

Collaborer dans les dossiers Git

Les dossiers Git de Databricks fonctionnent comme des clients Git intégrés dans votre workspace, vous permettant de collaborer par le biais du contrôle de source basé sur Git et du versionnement. Pour une collaboration efficace en équipe :

• Chaque membre de l'équipe a son propre dossier Git mappé au repository Git distant, où il travaille dans sa propre branch 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 de branch, comme un utilisateur changeant involontairement de branch pour tout le monde.

Pour partager la configuration de votre dossier Git avec un collaborateur :

1. Cliquez sur « Partager » .
2. Cliquez sur Copier le link pour créer un dossier Git .
3. Envoyez l'URL à votre collaborateur.
4. Lorsque votre collaborateur ouvre l'URL, il voit une boîte de dialogue préremplie avec la configuration de votre dossier Git.
5. Ils cliquent sur Créer un dossier Git pour cloner le repository dans leur propre Workspace sous leur dossier de travail actuel.

Merge Branch

La fonction de Merge dans les dossiers Git Databricks utilise git merge pour combiner l'historique des commits d'une Branch dans une autre. Pour les débutants Git, Databricks recommande d'utiliser la Merge plutôt que le rebasage, car cela ne nécessite pas de forcer le push et ne réécrit pas l'historique des commits.

Pour fusionner une Branch dans une autre, cliquez sur le menu kebab et sélectionnez Merge .

• En cas de conflit de Merge, résolvez-le dans l'interface utilisateur des dossiers Git.
• S'il n'y a pas de conflit, le Merge pousse vers le repo Git distant en utilisant git push.

Résoudre les conflits de Merge

Des conflits de fusion se produisent lorsque Git ne peut pas réconcilier automatiquement des modifications apportées aux mêmes lignes d’un fichier à partir de sources différentes, par exemple lors d’une opération de pull, de rebase ou de merge.

Pour résoudre un conflit de Merge, 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 Accepter toutes les modifications entrantes pour accepter une version entièrement.
• Annuler l'opération et annuler les modifications conflictuelles pour réessayer.

Résoudre manuellement les conflits

La résolution manuelle des conflits vous permet de déterminer les lignes conflictuelles à 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 supprimez tout le reste, y compris les marqueurs de conflit de merge Git. Lorsque vous avez terminé, sélectionnez **Marquer comme résolu**.

Si vous avez fait les mauvais choix lors de la résolution des conflits de Merge, cliquez sur Annuler pour annuler le processus et défaire toutes les modifications. Une fois tous les conflits résolus, cliquez sur Continue Merge ou sur Continuer le rebasage pour résoudre le conflit et terminer l'opération.

Baser à nouveau une Branch

La fonction de rebasage dans les dossiers Git de Databricks utilise git rebase pour intégrer les modifications d'une branch à une autre en réappliquant vos commits au-dessus de la branch cible, créant ainsi un historique linéaire.

Pour rebaser une Branch sur une autre Branch, cliquez sur le menu kebab et sélectionnez Rebase , puis sélectionnez la Branch cible.

• Après le rebase, les dossiers Git exécutent git commit et git push --force pour mettre à jour le dépôt distant.
• Le rebasage réécrit l'historique des commits, ce qui peut entraîner des problèmes de versionnement pour les collaborateurs travaillant dans le même référentiel.

Reset a Branch

Effectuez un Reset Git à partir de l'interface utilisateur des dossiers Git. Cette opération est équivalente à git reset --hard combinée avec git push --force.

Le Git Reset remplace le contenu et l'historique de la Branch par l'état le plus récent d'une autre Branch. Vous pouvez l'utiliser lorsque les modifications entrent en conflit avec la Branch en amont, et que vous ne craignez pas de perdre ces modifications lorsque vous Reset la Branch en amont. En savoir plus sur git reset --hard.

Reset to a remote Branch

Avec git reset dans ce scénario :

• Vous avez Reset votre Branch sélectionnée (par exemple, feature_a) vers une autre Branch (par exemple, main).
• Vous avez également Reset la Branch amont (distante) feature_a sur main.

important

When you Reset, vous perdez toutes les modifications non validées et validées dans les versions locale et distante de la Branch.

To Reset a Branch to a remote Branch:

1. Dans l’interface utilisateur des dossiers Git, à partir du menu **Branch**, choisissez la branche que vous voulez Reset.

2. Sélectionnez Reset dans le menu kebab .

   

3. Sélectionnez la Branch à Reset et cliquez sur Exécuter Git Reset .

Configurer le mode de récupération fragmentée

Le checkout sparse est un paramètre côté client qui vous permet de cloner et de travailler avec uniquement un sous-ensemble des répertoires du repository distant dans Databricks. Ceci est particulièrement utile si la taille de votre repository dépasse les limites prises en charge par Databricks.

Activez le mode de vérification éparse lorsque vous clonez un nouveau repository. Vous ne pouvez pas désactiver le mode de vérification éparse après l'avoir activé.

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

   

2. Dans la boîte Modèles de cônes , spécifiez les modèles de cônes de paiement que vous souhaitez. Séparez plusieurs modèles par des sauts de ligne.

Comment fonctionnent les modèles en cône

Pour comprendre comment les modèles de cône fonctionnent en mode de récupération fragmentée, consultez le diagramme suivant représentant la structure du repository distant.

Si vous sélectionnez le mode de récupération fragmentée , mais ne spécifiez pas de modèle de cône, le modèle de cône default s'applique. Cela inclut uniquement les fichiers à la racine et aucun sous-répertoire, ce qui donne une structure de dépôt comme suit :

Définir le motif de cône de sparse checkout comme parent/child/grandchild inclut de manière récursive tout le contenu du répertoire grandchild. Les fichiers qui se trouvent directement dans les répertoires /parent, /parent/child et racine sont également inclus. Voir la structure de répertoires dans le diagramme suivant :

remarque

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

Modifier les paramètres de récupération fragmentée

Après avoir créé un dépôt, modifiez le modèle de cône de récupération fragmentée à partir de Paramètres > Avancé > Modèles de cône .

Veuillez noter le comportement suivant :

• La suppression d'un dossier du modèle de cône le supprime de Databricks s'il n'y a pas de modifications non validées.

• L’ajout d’un dossier en modifiant le modèle de cône d’extraction clairsemé l’ajoute à Databricks sans nécessiter de pull supplémentaire.

• Les modèles de récupération fragmentée ne peuvent pas être modifiés pour supprimer un dossier lorsque des modifications non validées se trouvent dans ce dossier.

  Par exemple, si vous modifiez un fichier dans un dossier et ne commit pas les modifications, puis essayez de modifier le modèle d'extraction clairsemée 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, commit vos modifications, puis réappliquer le nouveau modèle.

Apporter des modifications avec la récupération fragmentée.

Modifiez les fichiers existants, puis commit-les et poussez-les depuis le dossier Git. Lors de la création de nouveaux dossiers de fichiers, incluez-les dans le modèle en cône que vous avez spécifié pour ce repo.

L'inclusion d'un nouveau dossier en dehors du motif de cône entraîne une erreur lors de l'opération de commit et push. Pour résoudre ce problème, modifiez le motif de cône pour inclure le nouveau dossier que vous essayez de commit et push.

Limites de la récupération fragmentée

• Le mode de récupération fragmenté ne fonctionne pas pour les repository Azure DevOps de plus de 4 Go.
• Vous ne pouvez pas désactiver la récupération fragmentée pour un dépôt qui a été créé avec la récupération fragmentée activée.

Gérer les dossiers Git par programme

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 workspace :

1. Faites un clic 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 Databricks à votre fournisseur Git. Voir Connecter votre fournisseur Git à Databricks.
• Renseignez-vous sur les limites de taille et les autres contraintes pour les dossiers Git. Consultez les limites et la référence des dossiers Git Databricks.
• Configurez les paramètres de niveau Workspace pour l’intégration Git. Consultez Configurer l'intégration Git pour les dossiers Git.