Concetti di base nell'integrazione Git

Questo articolo illustra i concetti di base di Git e il processo di integrazione di Git con l'area di lavoro di Microsoft Fabric.

Autorizzazioni

• L'amministratore dell'organizzazione deve abilitare l'integrazione con Git.
• L'amministratore tenant deve abilitare l'esportazione tra aree geografiche se l'area di lavoro e il repository di Azure si trovano in due aree diverse. Questa restrizione non si applica a GitHub.
• Le autorizzazioni disponibili sia nell'area di lavoro che in Git, come elencato nelle sezioni successive, determinano le azioni che è possibile eseguire.

Autorizzazioni di Git necessarie per le azioni più diffuse

L'elenco seguente mostra cosa possono fare i ruoli dell'area di lavoro a seconda delle relative autorizzazioni nel repository Git:

• Amministratore: può eseguire qualsiasi operazione nell'area di lavoro, limitata solo dal ruolo Git.
• Membro/Collaboratore: dopo la connessione a un'area di lavoro, un membro/collaboratore può eseguire il commit e aggiornare le modifiche, a seconda del proprio ruolo Git. Per le azioni correlate alla connessione all'area di lavoro (ad esempio, connessione, disconnessione o modifica dei rami), chiedere aiuto a un amministratore.
• Visualizzatore: non è possibile eseguire alcuna azione. Il visualizzatore non può vedere informazioni correlate a Git nell'area di lavoro.

Autorizzazioni di Fabric necessarie per le azioni più diffuse

Ruoli dell'area di lavoro

Nella tabella seguente vengono descritte le autorizzazioni necessarie nell'area di lavoro di Fabric per eseguire varie operazioni comuni:

Ruoli Git

Nella tabella seguente vengono descritte le autorizzazioni Git necessarie per eseguire varie operazioni comuni:

Connetti e sincronizza

Solo un amministratore dell'area di lavoro può connettere un'area di lavoro a repository Git, ma una volta effettuata la connessione, chiunque abbia le autorizzazioni può lavorare nell'area di lavoro. Se non si è un amministratore, chiedere assistenza all'amministratore per la connessione.

Quando si connette un'area di lavoro a Git, Fabric esegue la sincronizzazione tra le due posizioni in modo che abbiano lo stesso contenuto. Durante la sincronizzazione iniziale, se l'area di lavoro o il ramo Git è vuoto mentre l'altro dispone di contenuto, il contenuto viene copiato dalla posizione non vuota a quella vuota. Se sia l'area di lavoro che il ramo Git hanno contenuto, occorre decidere in quale direzione deve andare la sincronizzazione.

• Se si esegue il commit dell'area di lavoro nel ramo Git, tutto il contenuto supportato dell'area di lavoro viene esportato in Git e sovrascrive il contenuto Git corrente.
• Se si aggiorna l'area di lavoro con il contenuto Git, il contenuto dell'area di lavoro viene sovrascritto e si perde il contenuto dell'area di lavoro. Poiché un ramo Git può sempre essere ripristinato a una fase precedente, mentre non si può fare per un'area di lavoro, se si sceglie questa opzione, viene richiesta la conferma.

Se non si seleziona il contenuto da sincronizzare, non è possibile continuare a lavorare.

Cartelle

Quando si è connessi e sincronizzati, la struttura dell'area di lavoro viene sottoposta a mirroring nel repository Git, inclusa la struttura delle cartelle. Gli elementi dell'area di lavoro nelle cartelle vengono esportati in cartelle con lo stesso nome nel repository Git. Viceversa, gli elementi nelle cartelle Git vengono importati in cartelle con lo stesso nome nell'area di lavoro.

• Le cartelle vuote non vengono copiate in Git. Quando si creano o si spostano elementi in una cartella, la cartella viene creata in Git.
• Le cartelle vuote in Git vengono eliminate automaticamente.
• Le cartelle vuote nell'area di lavoro non vengono eliminate automaticamente anche se tutti gli elementi vengono spostati in cartelle diverse.
• La struttura delle cartelle viene mantenuta fino a 10 livelli di profondità.

Gestione delle modifiche alle cartelle in modo sicuro

Se l'area di lavoro contiene cartelle e la cartella Git connessa non include ancora sottocartelle, vengono considerate diverse perché la struttura delle cartelle è diversa. Quando si connette a Git un'area di lavoro con cartelle, nel pannello di controllo del codice sorgente viene visualizzato lo stato di modifiche non salvate, ed è necessario eseguire il commit delle modifiche in Git prima di aggiornare l'area di lavoro.

Se non è possibile apportare modifiche direttamente al ramo connesso, a causa di criteri di ramo o autorizzazioni, è consigliabile usare l'opzione Checkout Branch :

1. Check-out di un nuovo ramo: Utilizza la funzione di check-out del ramo per creare un ramo con lo stato aggiornato della tua area di lavoro Fabric.
2. Commit delle modifiche alle cartelle: qualsiasi modifica alle cartelle dell'area di lavoro può quindi essere sottoposta a commit in questo nuovo ramo.
3. Modifiche di merge: usare la normale richiesta pull e i processi di merge per integrare nuovamente questi aggiornamenti nel ramo originale.

Connettersi a un'area di lavoro condivisa

Se si tenta di connettersi a un'area di lavoro già connessa a Git, è possibile che venga visualizzato il messaggio seguente:

Passare alla scheda Account sul lato destro del pannello di controllo Origine, scegliere un account e connettersi.

Stato di Git

Dopo la connessione, l'area di lavoro visualizza una colonna di stato Git che indica lo stato di sincronizzazione di ogni elemento nell'area di lavoro in relazione agli elementi nel ramo remoto.

Ogni elemento ha uno degli stati seguenti:

• Sincronizzato (l'elemento è lo stesso nell'area di lavoro e nel ramo Git)
• Conflitto (l'elemento è stato modificato sia nell'area di lavoro che nel ramo Git)
• Elemento non supportato
• Modifiche non sottoposte a commit nell'area di lavoro
• Aggiornamento obbligatorio da Git
• L'elemento è identico in entrambe le posizioni, ma deve essere aggiornato all'ultimo commit

Informazioni di sincronizzazione

Purché sia stata effettuata la connessione, nella parte inferiore della schermata appaiono le informazioni seguenti:

• Filiale connessa
• Ora dell'ultima sincronizzazione
• Collegamento all'ultimo commit a cui è sincronizzata l'area di lavoro

Pannello di controllo del codice sorgente

Nella parte superiore della schermata è presente l'icona controllo del codice sorgente . Mostra il numero di elementi diversi nell'area di lavoro e nel ramo Git. Quando vengono apportate modifiche all'area di lavoro o al ramo Git, il numero viene aggiornato. Quando l'area di lavoro viene sincronizzata con il ramo Git, l'icona controllo del codice sorgente visualizza un valore 0.

Selezionare l'icona Controllo del codice sorgente per aprire il pannello di controllo Del codice sorgente .

Il riquadro di controllo del codice sorgente ha tre schede sul lato:

• Commit e aggiornamenti
• Rami
• I dettagli dell'account

Salvataggi e aggiornamenti

Quando vengono apportate modifiche all'area di lavoro o al ramo Git, l'icona del controllo del codice sorgente mostra il numero di elementi diversi. Selezionare l'icona del Controllo del codice sorgente per aprire il pannello di controllo del codice sorgente.

Il pannello Commit e aggiornamento include due sezioni.

Le modifiche mostrano il numero di elementi modificati nell'area di lavoro ed è necessario eseguire il commit in Git.
Gli aggiornamenti mostrano il numero di elementi modificati nel ramo Git e devono essere aggiornati all'area di lavoro.

In ogni sezione, gli elementi modificati sono elencati con un'icona che indica lo stato:

• nuovo
• modificato
• eliminato
• conflitto
• stesse modifiche

Il pulsante Aggiorna, situato nella parte superiore del pannello, aggiorna l'elenco delle modifiche e degli aggiornamenti.

Eseguire il commit

• Gli elementi nell'area di lavoro modificati sono elencati nella sezione Modifiche . Quando sono presenti più elementi modificati, è possibile selezionare gli elementi di cui eseguire il commit nel ramo Git.
• Se sono stati apportati aggiornamenti al ramo Git, i commit vengono disabilitati fino a quando non si aggiorna l'area di lavoro.

Aggiornamento

• A differenza del commit e del undo, il comando Update aggiorna sempre l'intero ramo e sincronizza con il commit più recente. Non è possibile selezionare elementi specifici da aggiornare.
• Se sono state apportate modifiche nell'area di lavoro e nel ramo Git nello stesso elemento, gli aggiornamenti vengono disabilitati fino a quando il conflitto non viene risolto.

Altre informazioni su come eseguire il commit e l'aggiornamento. Altre informazioni sul processo di aggiornamento e su come risolvere i conflitti.

Filiali

La scheda Rami del pannello di controllo del codice sorgente consente di gestire i rami ed eseguire azioni correlate ai rami. Ha due sezioni principali:

• Azioni che è possibile eseguire nel ramo corrente:

  • Passa a un'altra area di lavoro (collaboratore e superiori): crea una nuova area di lavoro o passa a un'area di lavoro esistente a seconda dell'ultimo commit nell'area di lavoro corrente. Si connette quindi all'area di lavoro e al ramo di destinazione.
  • Controlla nuovo ramo (devi essere amministratore dell'area di lavoro): crea un nuovo ramo basato sull'ultimo commit sincronizzato nell'area di lavoro e aggiorna la connessione Git nell'area di lavoro corrente. Non modifica il contenuto dell'area di lavoro.
  • Ramo switch (deve essere amministratore dell'area di lavoro): sincronizza l'area di lavoro con un altro ramo nuovo o esistente ed esegue l'override di tutti gli elementi nell'area di lavoro con il contenuto del ramo selezionato.

  

• Rami correlati.
  La scheda Rami include anche un elenco di aree di lavoro correlate a cui è possibile selezionare e passare. Un'area di lavoro correlata è una con le stesse proprietà di connessione del ramo attuale, ad esempio la stessa organizzazione, progetto, repository e cartella Git.
  Questa funzionalità consente di passare alle aree di lavoro connesse ad altri rami correlati al contesto del lavoro corrente, senza doverli cercare nell'elenco di aree di lavoro di Fabric.
  Per aprire l'area di lavoro pertinente, selezionare l'elemento nell'elenco.

  

Per altre informazioni, vedere Diramazione delle limitazioni.

Dettagli dell'account

La scheda Dettagli dell'account mostra i dettagli dell'account GitHub a cui l'utente è connesso. Ha due sezioni. La sezione superiore mostra il provider Git e il nome dell'account. La sezione inferiore mostra il repository e il ramo a cui è connessa l'area di lavoro. Attualmente, questa scheda è disponibile solo per le aree di lavoro connesse a GitHub.

I dettagli dell'account GitHub includono:

• Dettagli dell'account Git

  • Fornitore
  • Nome dell'account

• Repository Git

• Ramo

Considerazioni e limitazioni

Limitazioni generali per l'integrazione di Git

• Il metodo di autenticazione in Fabric deve essere almeno sicuro come il metodo di autenticazione per Git. Ad esempio, se Git richiede l'autenticazione a più fattori, anche Fabric deve richiedere l'autenticazione a più fattori.
• I set di dati di Power BI connessi ad Analysis Services non sono attualmente supportati.
• Se si utilizza un'identità dell'area di lavoro in un artefatto e lo si committa su Git, può essere aggiornato (ritornando a un'area di lavoro tessile) solo in un'area di lavoro connessa alla stessa identità. Prestare attenzione, poiché ciò influisce anche su funzionalità come il ramificare.
• I moduli secondari non sono supportati.
• I cloud sovrani non sono supportati.

Limitazioni di GitHub Enterprise

Alcune versioni e impostazioni di GitHub Enterprise non sono supportate. Ad esempio:

• GitHub Enterprise Cloud con residenza dei dati (ghe.com)
• GitHub Enterprise Server con un dominio personalizzato non è supportato, anche se l'istanza è accessibile pubblicamente
• Github Enterprise Server ospitato in una rete privata
• Elenco IP consentiti

Limitazioni dell'area di lavoro

• Solo l'amministratore dell'area di lavoro può gestire le connessioni al repository Git , ad esempio la connessione, la disconnessione o l'aggiunta di un ramo.
  Dopo la connessione, chiunque disponga dell'autorizzazione può funzionare nell'area di lavoro.
• Le aree di lavoro con app modello installate non possono essere connesse a Git.
• MyWorkspace non è in grado di connettersi a un provider Git.

Limitazioni dei rami e delle cartelle

• La lunghezza massima del nome del ramo è di 244 caratteri.
• La lunghezza massima del percorso completo per i nomi dei file è di 250 caratteri. I nomi più lunghi falliscono.
• La dimensione massima del file è di 25 MB.
• La struttura delle cartelle viene mantenuta fino a una profondità di 10 livelli.
• Non è consigliabile scaricare un report o un set di dati come pbix dal servizio dopo la distribuzione con l'integrazione Git, perché i risultati non sono affidabili. È consigliabile usare PowerBI Desktop per scaricare report/set di dati come file con estensione pbix.
• Se il nome visualizzato dell'elemento presenta una di queste caratteristiche, la cartella Git viene rinominata con l'ID logico (Guid) e il tipo:
  • Ha più di 256 caratteri
  • Termina con un . o uno spazio
  • Contiene qualsiasi carattere non consentito, come descritto nelle limitazioni del nome della directory
• Quando si connette un'area di lavoro con cartelle a Git, è necessario eseguire il commit delle modifiche al repository Git se tale struttura di cartelle è diversa.

Limitazioni sui nomi delle directory

• Il nome della directory che si connette al repository Git presenta le restrizioni di denominazione seguenti:

  • Il nome della directory non può iniziare o terminare con uno spazio o una scheda.
  • Il nome della directory non può contenere uno dei caratteri seguenti: "/:<>\*|

• La cartella dell'elemento (la cartella che contiene i file di elementi) non può contenere uno dei caratteri seguenti: ":<>\*?|. Se si rinomina la cartella in un elemento che include uno di questi caratteri, Git non può connettersi o sincronizzare con l'area di lavoro e si verifica un errore.

Limitazioni sull'espansione

• Per la diramazione sono necessarie autorizzazioni elencate nella tabella delle autorizzazioni.
• Per questa azione deve esserci una capacità disponibile.
• Tutte le limitazioni di denominazionedell'area di lavoro e dei rami si applicano quando si esegue la diramazione in una nuova area di lavoro.
• Nella nuova area di lavoro sono disponibili solo gli elementi supportati da Git .
• L'elenco dei rami correlati mostra solo rami e aree di lavoro per cui si dispone dell'autorizzazione per la visualizzazione.
• L'integrazione git deve essere abilitata.
• Quando si esegue la diramazione, viene creato un nuovo ramo e le impostazioni del ramo originale non vengono copiate. Modificare le impostazioni o le definizioni per assicurarsi che il nuovo soddisfi i criteri dell'organizzazione.
• Quando si esegue la diramazione in un'area di lavoro esistente:
  • L'area di lavoro di destinazione deve supportare una connessione Git.
  • L'utente deve essere un amministratore dell'area di lavoro di destinazione.
  • L'area di lavoro di destinazione deve avere capacità.
  • L'area di lavoro non può avere applicazioni modello.
• Si noti che quando si apre un nuovo ramo in un'area di lavoro, eventuali elementi che non vengono salvati in Git rischiano di andare persi. È consigliabile eseguire il commit di tutti gli elementi che si desidera mantenere prima della diramazione.

Limitazioni di sincronizzazione e completamento

• È possibile eseguire la sincronizzazione in una sola direzione alla volta. Non è possibile eseguire il commit e l'aggiornamento contemporaneamente.
• Le etichette di riservatezza non sono supportate e l'esportazione di elementi con etichette di riservatezza potrebbe essere disabilitata. Per eseguire il commit di elementi che di solito hanno etichette di riservatezza ma ne sono privi, chiedi aiuto al tuo amministratore.
• Funziona con elementi limitati. Gli elementi non supportati nella cartella vengono ignorati.
• La duplicazione dei nomi non è consentita. Anche se Power BI consente la duplicazione dei nomi, l'azione di aggiornamento, commit o annullamento ha esito negativo.
• B2B non è supportato.
• La risoluzione dei conflitti viene eseguita parzialmente in Git.
• Durante il processo Commit in Git , il servizio Fabric elimina i file all'interno della cartella dell'elemento che non fanno parte della definizione dell'elemento. I file non correlati non presenti in una cartella di elementi non vengono eliminati.
• Dopo aver confermato le modifiche, potresti notare alcune modifiche impreviste all'elemento che non hai apportato. Queste modifiche sono semanticamente insignificanti e possono verificarsi per diversi motivi. Ad esempio:
  • Modificare manualmente il file di definizione dell'elemento. Queste modifiche sono valide, ma potrebbero essere diverse da quelle eseguite tramite gli editor. Ad esempio, se si rinomina una colonna del modello semantico in Git e si importa questa modifica nell'area di lavoro, al successivo commit delle modifiche apportate al modello semantico, il file bim verrà registrato come modificato e la colonna modificata viene inserita nella parte posteriore della columns matrice. Questo perché il motore AS che genera i file bim spinge le colonne rinominate alla fine della matrice. Questa modifica non influisce sul funzionamento dell'elemento.
  • Eseguire il commit di un file che utilizza interruzioni di riga CRLF. Il servizio usa interruzioni di riga LF (avanzamento riga). Se nel repository Git sono presenti file di elementi con interruzioni di riga CRLF , quando si esegue il commit dal servizio questi file vengono modificati in LF. Ad esempio, se si apre un report sul desktop, salvare il file di progetto (con estensione pbip) e caricarlo in Git usando CRLF.
• L'aggiornamento di un modello semantico tramite l'API di aggiornamento avanzato causa un diff Git dopo ogni aggiornamento.

Contenuto correlato

• Gestire i rami
• Risolvere errori e conflitti