Eseguire operazioni Git nelle cartelle Git di Databricks

L'articolo descrive come eseguire operazioni Git comuni nell'area di lavoro di Databricks usando cartelle Git, tra cui clonazione, diramazione, commit e push.

Clonare un repository connesso a un repository Git remoto

È possibile creare cartelle Git usando l'interfaccia utente di Databricks o il terminale Web.

Nota

• È necessario disporre CAN MANAGE dell'autorizzazione per la cartella padre in cui si vuole creare la cartella Git.
• L'area di lavoro deve avere credenziali Git configurate. Vedi Configura le credenziali Git e & connetti un repository remoto ad Azure Databricks.

Clonare dall'interfaccia utente

1. Nella barra laterale selezionare Area di lavoro e quindi passare alla cartella in cui si vuole creare il clone del repository Git.

2. Fare clic su Crea>cartella Git.

   

3. Nella finestra di dialogo Crea cartella Git specificare le informazioni seguenti:

   Campo	Description
   URL del repository Git	URL del repository Git da clonare nel formato https://example.com/organization/project.git
   Fornitore Git	Provider Git per il repository da clonare. Le opzioni includono GitHub, GitHub Enterprise, GitLab e Azure DevOps (Azure Repos)
   Nome cartella Git	Nome della cartella nell'area di lavoro che conterrà il contenuto del repository clonato
   Checkout parziale	Scegliere se utilizzare il sparse checkout, in cui viene clonato solo un subset delle directory del repository, specificato usando un modello a cono. Ciò è utile se il tuo repository è più grande dei limiti supportati da Databricks .
   Usare il CLI di Git (Beta)	Abilitare per eseguire comandi Git standard direttamente da un terminale di Databricks. In questo modo è possibile accedere a operazioni avanzate come hook di pre-commit, submoduli Git e Archiviazione di grandi file (LFS). Consulta Utilizzare i comandi della CLI Git (Beta).

4. Cliccare Crea cartella Git. Il contenuto del repository remoto viene clonato nel repository Databricks ed è possibile iniziare a usarli usando le operazioni Git supportate tramite l'area di lavoro.

Clonare dal terminale web

È anche possibile creare cartelle Git con accesso all'interfaccia della riga di comando direttamente dal terminale Web:

1. Accedere al terminale Web. Vedere Eseguire i comandi della shell nel terminale Web di Azure Databricks.

2. Accedere alla directory padre in /Workspace:

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

   Nota

   Non è possibile creare cartelle Git con accesso all'interfaccia della riga di comando Git in o nelle /Repos cartelle Git esistenti.

3. Clonare il repository:

   git clone <remote-url>
   

   Il git clone comando usa le credenziali Git configurate nell'area di lavoro. Vedi Configura le credenziali Git e & connetti un repository remoto ad Azure Databricks.

4. Aggiornare il browser per visualizzare la nuova cartella nel browser dei file dell'area di lavoro.

Usare i comandi CLI di Git (Beta)

Importante

Questa funzionalità è in versione beta.

Le cartelle Git con accesso all'interfaccia della riga di comando git consentono di eseguire comandi Git standard direttamente da un terminale di Databricks. È possibile:

• Eseguire qualsiasi comando Git, tra cui git stash, git pull --forcee git rebase -i.
• Integrare l'analisi del codice con linting (controllo del codice) e la scansione del codice con hook di pre-commit.
• Usare i repository che superano i limiti di 2 GB di memoria e 4 GB di dischi delle cartelle Git standard.
• Usare i sottomoduli di Git e l'archiviazione di file di grandi dimensioni (LFS).
• Eseguire più commit in locale prima di eseguire il push nel repository remoto.

Per usare l'accesso all'interfaccia della riga di comando Git, l'area di lavoro deve avere un ambiente senza server abilitato con la versione 4 o successiva dell'ambiente.

Creare una cartella Git con accesso all'interfaccia della riga di comando git

Per creare una cartella Git con accesso all'interfaccia della riga di comando:

• Quando si usa il terminale Web, qualsiasi repository clonato ha accesso automatico all'interfaccia della riga di comando di Git.
• Quando si usa l'interfaccia utente, è necessario abilitare l'anteprima "Usa CLI Git" quando si crea la cartella Git.

Dopo aver creato una cartella Git con accesso all'interfaccia della riga di comando, eseguire qualsiasi comando Git standard dal terminale 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

Limitazioni dell'interfaccia della riga di comando di Git

Le cartelle Git con accesso all'interfaccia della riga di comando presentano le limitazioni seguenti:

• Le aree di lavoro con elenco di URL remoti ammessi abilitate non possono usare le funzionalità Git CLI.
• I comandi Git CLI ignorano l'impostazione dell'amministrazione che blocca il commit degli output del notebook.
• L'API Repos non è supportata per le cartelle Git con accesso all'interfaccia della riga di comando.
• Non è possibile abilitare l'accesso all'interfaccia della riga di comando Git per le cartelle Git esistenti.

Risoluzione dei problemi relativi alle operazioni CLI di Git

• Il terminale richiede le credenziali per ogni operazione: la funzionalità dell'interfaccia della riga di comando Git non è abilitata nell'area di lavoro. Contattare l'amministratore dell'area di lavoro per verificare che l'anteprima sia abilitata.
• Non è possibile abilitare l'accesso al CLI: le aree di lavoro con liste di autorizzazione per URL remoti non possono usare le funzionalità del CLI di Git. Contattare l'amministratore dell'area di lavoro per esaminare la configurazione di rete dell'area di lavoro.
• Le operazioni Git hanno esito negativo con errori di autorizzazione: verificare di disporre CAN MANAGE dell'autorizzazione per la cartella padre e che le credenziali Git dell'area di lavoro siano valide. Vedi Configura le credenziali Git e & connetti un repository remoto ad Azure Databricks.

Procedura consigliata: Collaborazione in cartelle Git

Le cartelle Git di Databricks si comportano come client Git incorporati nell'area di lavoro, consentendo di collaborare tramite il controllo del codice sorgente basato su Git e il controllo delle versioni. Per una collaborazione efficace del team:

• Ogni membro del team ha una propria cartella Git mappata al repository Git remoto, in cui lavora nel proprio ramo di sviluppo.
• Solo un utente esegue operazioni Git in ogni cartella Git. Più utenti che eseguono operazioni Git nella stessa cartella possono causare problemi di gestione dei rami, ad esempio un utente che cambia involontariamente rami per tutti.

Per condividere la configurazione della cartella Git con un collaboratore:

1. Fare clic su Copia collegamento per creare una cartella Git nel banner nella parte superiore dell'area di lavoro di Databricks.
2. Inviare l'URL al collaboratore.
3. Quando il collaboratore apre l'URL, viene visualizzata una finestra di dialogo Crea cartella Git prepopolato con la configurazione della cartella Git.
4. Fare clic su Crea cartella Git per clonare il repository nella propria area di lavoro nella cartella di lavoro corrente.

Per copiare una cartella Git da un altro utente:

1. Aprire la cartella Git dell'altro utente nell'area di lavoro condivisa.
2. Fare clic su Crea cartella Git nel banner nella parte superiore. Viene visualizzata la finestra di dialogo Crea cartella Git con la configurazione del repository Git prepopolato.
3. Fare clic su Crea cartella Git per clonare il repository nella propria area di lavoro.

Accedere alla finestra di dialogo Git

È possibile accedere alla finestra di dialogo Git da un notebook o dal browser delle cartelle Git di Databricks.

• Da un notebook fare clic sul pulsante accanto al nome del notebook che identifica il ramo Git corrente.

  

• Dal browser delle cartelle Git di Databricks fare clic sul pulsante a destra del nome del repository. È anche possibile fare clic con il pulsante destro del mouse sul nome del repository e scegliere Git... dal menu.

  

Verrà visualizzata una finestra di dialogo a schermo intero in cui è possibile eseguire operazioni Git.

1. Ramo di lavoro corrente. Qui è possibile selezionare altri rami. Se altri utenti hanno accesso a questa cartella Git, la modifica del ramo modificherà anche il ramo se condividono la stessa area di lavoro. Vedere una procedura consigliata per evitare questo problema.
2. Pulsante per creare un nuovo ramo.
3. L'elenco delle risorse di file e delle sottocartelle registrate nel tuo ramo attuale.
4. Pulsante che consente di accedere al provider Git e di visualizzare la cronologia current branch.
5. Pulsante per eseguire il pull del contenuto dal repository Git remoto.
6. Casella di testo in cui si aggiunge un messaggio di commit e una descrizione espansa facoltativa per le modifiche.
7. Pulsante per eseguire il commit del lavoro nel ramo di lavoro ed eseguire il push del ramo aggiornato nel repository Git remoto.

Fare clic in alto a destra per scegliere tra ulteriori operazioni di ramo Git, come un reset totale, un merge o un rebase.

Questa è la home page per l'esecuzione di operazioni Git nella cartella Git dell'area di lavoro. Le operazioni Git presentate nell'interfaccia utente sono limitate.

Creare un nuovo ramo

È possibile creare un nuovo ramo basato su un ramo esistente dalla finestra di dialogo Git:

Passare a un ramo diverso

È possibile passare a (checkout) a un ramo diverso usando l'elenco a discesa ramo nella finestra di dialogo Git:

Le modifiche di cui non è stato eseguito il commit nel ramo corrente verranno visualizzate come modifiche di cui non è stato eseguito il commit nel nuovo ramo, se le modifiche di cui non è stato eseguito il commit non sono in conflitto con il codice nel nuovo ramo. Rimuovere le modifiche prima o dopo il cambio di branch se non si desidera mantenere le modifiche non salvate.

La versione locale di un ramo può rimanere presente nella cartella Git associata per un massimo di 30 giorni dopo l'eliminazione del ramo remoto. Per rimuovere completamente un ramo locale in una cartella Git, eliminare il repository.

Importante

Il cambio di rami può eliminare gli asset dell'area di lavoro quando il nuovo ramo non contiene questi asset. Il passaggio a Current Branch ricrea gli asset eliminati con nuovi ID e URL. Questa modifica non può essere annullata.

Se hai condiviso o aggiunto segnalibri a degli asset da una cartella in un repository Git, assicurati che l'asset esista nel nuovo ramo prima di cambiare ramo.

Eseguire il commit e il push delle modifiche nel repository Git remoto

Quando sono stati aggiunti nuovi notebook o file o sono state apportate modifiche a notebook o file esistenti, l'interfaccia utente della cartella Git evidenzia le modifiche.

Aggiungere un messaggio di commit necessario per le modifiche e fare clic su Commit & Push per eseguire il push di queste modifiche nel repository Git remoto.

Se non si dispone dell'autorizzazione per eseguire il commit nel ramo predefinito (ad esempio il main ramo), creare un nuovo ramo e usare l'interfaccia del provider Git per creare una richiesta pull (PR) per unirla nel ramo predefinito.

Nota

• Gli output dei notebook non sono inclusi nei commit per impostazione predefinita quando i notebook vengono salvati nei formati di file di origine (.py, .scala, .sql, .r). Per informazioni sul commit degli output dei notebook con il formato IPYNB, vedere Controllare i commit degli artefatti di output del notebook IPYNB

Eseguire il pull delle modifiche dal repository Git remoto

Per eseguire il pull delle modifiche dal repository Git remoto, fare clic su Pull nella finestra di dialogo Operazioni Git. I notebook e gli altri file vengono aggiornati automaticamente alla versione più recente nel repository Git remoto. Se le modifiche estratte dal repository remoto sono in conflitto con le modifiche locali in Databricks, è necessario risolvere i conflitti di merge.

Importante

Le operazioni Git che estraggono upstream cancellano lo stato del notebook. Per altre informazioni, vedere Modifiche in ingresso cancellano lo stato del notebook.

Eseguire il merge dei rami

Accedere all'operazione Git Merge selezionandola dall'icona del in alto a destra nella finestra Operazioni Git.

La funzione di merge nelle cartelle Git di Databricks unisce un ramo a un altro usando git merge. Un'operazione di merge è un modo per combinare la cronologia dei commit da un ramo a un altro ramo; l'unica differenza è la strategia usata per ottenere questo risultato. Per i principianti di Git, è consigliabile usare merge (over rebase) perché non richiede il push forzato in un ramo e pertanto non riscrive la cronologia dei commit.

• Se si verifica un conflitto di merge, risolverlo nell'interfaccia utente delle cartelle Git.
• Se non è presente alcun conflitto, viene eseguito il push dell'unione nel repository Git remoto usando git push.

Rebase un ramo in un altro ramo

Accedere all'operazione Git Rebase selezionandola Menu kebab in alto a destra nella finestra di dialogo Operazioni Git.

La ribasatura modifica la cronologia dei commit di un ramo. Analogamente git mergea , git rebase integra le modifiche da un ramo a un altro. Rebase esegue le operazioni seguenti:

1. Salva i commit nel ramo corrente in un'area temporanea.
2. Reimposta il ramo corrente sul ramo scelto.
3. Riapplica ogni singolo commit salvato in precedenza nel ramo corrente, generando una cronologia lineare che combina le modifiche di entrambi i rami.

Avviso

L'uso della rebase può causare problemi di controllo delle versioni per i collaboratori che lavorano nello stesso repository.

Un flusso di lavoro comune consiste nel ribase di un ramo di funzionalità nel ramo principale.

Per ribasere un ramo in un altro ramo:

1. Dal menu ramo nell'interfaccia utente delle cartelle Git, selezionare il ramo da ribasare.

2. Selezionare Rebase dal menu kebab.

   

3. Seleziona il ramo su cui vuoi fare il rebase.

   L'operazione di ribase integra le modifiche dal ramo scelto qui nel ramo current branch.

Le esecuzioni git commit e git push --force delle cartelle Git di Databricks vengono effettuate per aggiornare il repository Git remoto.

Risolvere i conflitti di unione

I conflitti di merge si verificano quando 2 o più utenti Git tentano di unire le modifiche alle stesse righe di un file in un ramo comune e Git non può scegliere le modifiche "giuste" da applicare. I conflitti di merge possono verificarsi anche quando un utente tenta di eseguire il pull o l'unione di modifiche da un altro ramo in un ramo con modifiche di cui non è stato eseguito il commit.

Se un'operazione come pull, rebase o merge causa un conflitto di merge, l'interfaccia utente delle cartelle Git mostra un elenco di file con conflitti e opzioni per la risoluzione dei conflitti.

Sono disponibili due opzioni principali:

• Usare l'interfaccia utente delle cartelle Git per risolvere il conflitto.
• Interrompere l'operazione Git, rimuovere manualmente le modifiche nel file in conflitto e ritentare l'operazione Git.

Quando si risolve unisci conflitti con l'interfaccia utente delle cartelle Git, è necessario scegliere tra risolvere manualmente i conflitti nell'editor o mantenere tutte le modifiche in ingresso o correnti.

Mantenere tutte le modifiche correnti o apportare modifiche in ingresso

Se si è certi di solo si desidera mantenere tutte le modifiche correnti o in ingresso, fare clic sul kebab a destra del nome del file nel riquadro del notebook e selezionare Mantieni tutte le modifiche correnti o Accetta tutte le modifiche in ingresso. Fare clic sul pulsante con la stessa etichetta per eseguire il commit delle modifiche e risolvere il conflitto.

Suggerimento

Confusa su quale opzione scegliere? Il colore di ogni opzione corrisponde alle rispettive modifiche al codice che manterrà nel file.

Risoluzione manuale dei conflitti

La risoluzione manuale dei conflitti consente di determinare quali righe in conflitto devono essere accettate nell'unione. Per i conflitti di unione, è possibile risolvere il conflitto modificando direttamente il contenuto del file con i conflitti.

Per risolvere il conflitto, selezionare le righe di codice da conservare ed eliminare tutto il resto, inclusi i marcatori di conflitto di unione Git. Al termine, selezionare Contrassegna come risolto.

Se si decide di effettuare le scelte sbagliate durante la risoluzione dei conflitti di unione, fare clic sul pulsante Interrompi per interrompere il processo e annullare tutto. Dopo aver risolto tutti i conflitti, fare clic sull'opzione Continua unione o Continua rebase per risolvere il conflitto e completare l'operazione.

Git reset

Nelle cartelle Git di Databricks è possibile eseguire un git reset nell'interfaccia utente di Azure Databricks. La reimpostazione git nelle cartelle Git di Databricks equivale a git reset --hard combinata con git push --force.

La reimpostazione di Git sostituisce il contenuto e la cronologia dei rami con lo stato più recente di un altro ramo. È possibile usarlo quando le modifiche sono in conflitto con il ramo upstream e non è consigliabile perdere tali modifiche quando si reimposta il ramo upstream. Altre informazioni su git reset –hard.

Reimpostare un ramo di origine (remoto)

Con git reset in questo scenario:

• È possibile reimpostare il ramo selezionato ( ad esempio, feature_a) in un ramo diverso ( ad esempio, main).
• È anche possibile reimpostare il ramo upstream (remoto) feature_a su main.

Importante

Quando si reimposta, si perdono tutte le modifiche non confermate e confermate sia nella versione locale che remota del ramo.

Per reimpostare un ramo a un ramo remoto:

1. Nell'interfaccia delle cartelle Git dal menu ramo , scegli il ramo che vuoi reimpostare.

   

2. Selezionare Reimposta dal menu kebab.

   

3. Selezionare il ramo da reimpostare.

   

Configurare la modalità di estrazione di tipo sparse

L'opzione di estrazione selettiva è una configurazione lato client che permette di clonare e lavorare solo su un sottoinsieme delle directory dei repository remoti in Databricks. Ciò è particolarmente utile se le dimensioni del repository superano i limiti supportati da Databricks.

È possibile usare la modalità Estrazione sparse quando si aggiunge (clonazione) un nuovo repository.

1. Nella finestra di dialogo Aggiungi cartella Git aprire Avanzate.

2. Selezionare modalità sparse di estrazione.

   

3. Nella casella Modelli coni specificare i modelli di estrazione dei coni desiderati. Separare più modelli per interruzioni di riga.

Al momento, non è possibile disabilitare il checkout sparse per un repository in Azure Databricks.

Funzionamento dei modelli coni

Per comprendere il funzionamento del modello cono nella modalità di estrazione di tipo sparse, vedere il diagramma seguente che rappresenta la struttura del repository remoto.

Se si seleziona modalità di estrazione sparse, ma non si specifica un modello cono, viene applicato il modello di cono predefinito. Sono inclusi solo i file nella radice e nessuna sottodirectory, con conseguente struttura di repository come indicato di seguito:

L'impostazione del modello di cono di estrazione di tipo sparse comporta parent/child/grandchild l'inserimento ricorsivo di tutti i contenuti della grandchild directory. Sono inclusi anche i file immediatamente nella /parentdirectory radice /parent/child e . Vedere la struttura di directory nel diagramma seguente:

È possibile aggiungere più modelli separati da interruzioni di riga.

Nota

I comportamenti di esclusione (!) non sono supportati nella sintassi del modello di cono Git.

Modificare le impostazioni di estrazione di tipo sparse

Dopo aver creato un repository, il modello di cono di estrazione sparse può essere modificato da > avanzati>.

Nota il seguente comportamento:

• La rimozione di una cartella dal modello cono lo rimuove da Databricks se non sono presenti modifiche di cui non è stato eseguito il commit.

• L'aggiunta di una cartella tramite la modifica del modello di cono di estrazione sparse lo aggiunge a Databricks senza richiedere un pull aggiuntivo.

• I modelli di estrazione di tipo sparse non possono essere modificati per rimuovere una cartella quando sono presenti modifiche di cui non è stato eseguito il commit in tale cartella.

  Ad esempio, un utente modifica un file in una cartella e non esegue il commit delle modifiche. Tenta quindi di modificare il modello di estrazione sparse in modo da non includere questa cartella. In questo caso, il modello viene accettato, ma la cartella effettiva non viene eliminata. Deve ripristinare il modello per includere tale cartella, eseguire il commit delle modifiche e quindi riapplicare il nuovo modello.

Nota

Non è possibile disabilitare il checkout sparse per un repository creato con la modalità Sparse Checkout abilitata.

Apportare ed eseguire il push delle modifiche con estrazione di tipo sparse

È possibile modificare i file esistenti ed eseguirne il commit ed eseguirne il push dalla cartella Git. Quando si creano nuove cartelle di file, includerli nel modello cono specificato per tale repository.

L'inclusione di una nuova cartella all'esterno del modello cono genera un errore durante l'operazione di commit e push. Per correggerlo, modificare il modello di cono per includere la nuova cartella che si sta tentando di eseguire il commit e il push.

Criteri per un file config del repository

Il file di configurazione degli output commit usa modelli simili ai modelli gitignore ed esegue le operazioni seguenti:

• I criteri positivi consentono l'inclusione degli output per i notebook corrispondenti.
• I criteri negativi disabilitano l'inclusione degli output per i notebook corrispondenti.
• I criteri vengono valutati in ordine per tutti i notebook.
• I percorsi o i percorsi non validi che non risolvono ai notebook .ipynb vengono ignorati.

Modello positivo: per includere output da un percorso folder/innerfolder/notebook.ipynbdel notebook, usare i modelli seguenti:

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

Modello negativo: per escludere gli output per un notebook, verificare che nessuno dei modelli positivi corrisponda o aggiungere un criterio negativo in un punto corretto del file di configurazione. I criteri negativi (escludi) iniziano con !:

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

Limitazione di estrazione di tipo sparse

Il checkout di tipo sparse attualmente non funziona per i repository di Azure DevOps di dimensioni superiori a 4 GB.

Aggiungere un repository e connettersi in remoto in un secondo momento

Per gestire e usare cartelle Git a livello di codice, usare l'API REST delle cartelle Git.

Eliminare una cartella Git

Per rimuovere una cartella Git dall'area di lavoro:

1. Fare clic con il pulsante destro del mouse sulla cartella Git e scegliere Sposta nel cestino.
2. Digitare il nome della cartella Git da confermare.
3. Fare clic su Conferma e sposta nel cestino.