Questa pagina presuppone che il tuo progetto sia già stato configurato per il controllo delle versioni. Se vedi un pulsante Configura Git anziché le scelte descritte in questa pagina, devi prima configurare Git per il tuo progetto.
Looker utilizza Git per registrare le modifiche e gestire le versioni dei file. Ogni progetto LookML corrisponde a un repository Git e ogni ramo di sviluppo corrisponde a un ramo Git.
Looker può essere configurato per funzionare con molti provider Git, come GitHub, GitLab e Bitbucket. Per informazioni sulla configurazione di Git per il tuo progetto Looker, consulta la pagina della documentazione Configurazione e test di una connessione Git.
Utilizzo dei rami Git
Uno dei principali vantaggi di Git è che uno sviluppatore Looker può lavorare in un branch, una versione isolata di un repository di file. Puoi sviluppare e testare senza influire sugli altri utenti. In qualità di sviluppatore in Looker, utilizzi un ramo Git ogni volta che ti trovi in modalità di sviluppo.
Un'altra funzionalità importante di Git è la facilità di collaborazione con altri sviluppatori. Puoi creare un ramo e (se vuoi) apportare modifiche, quindi altri sviluppatori possono passare a quel ramo per rivederlo o apportarvi modifiche. Se un altro sviluppatore ha eseguito il commit delle modifiche al ramo, Looker mostra il pulsante Pull Remote Changes (Estrai modifiche remote). Prima di apportare ulteriori modifiche, devi eseguire il pull di quelle di cui è stato eseguito il commit nel branch.
Puoi anche eliminare un ramo diverso dal ramo principale, dal ramo corrente o dal ramo personale di uno sviluppatore.
Branch personali
Per migliorare le prestazioni, la prima volta che apri un progetto LookML in modalità di sviluppo, l'IDE Looker mostra la versione del progetto in modalità di produzione, insieme al pulsante Crea copia sviluppatore. Dopo aver fatto clic sul pulsante Crea copia sviluppatore per il progetto, l'IDE di Looker crea il tuo ramo Git personale e carica il progetto LookML in modalità di sviluppo.
Il tuo ramo personale inizia con dev-
e include il tuo nome.
Il tuo ramo personale è specifico per te e non può essere eliminato. Il tuo ramo personale è di sola lettura per tutti gli altri sviluppatori. Se collabori con altri sviluppatori a un progetto, ti consigliamo di creare un nuovo ramo in modo che anche gli altri possano passare a quel ramo e contribuire con le modifiche.
Creazione di un nuovo ramo Git
Se stai lavorando a una correzione semplice e non collabori con altri sviluppatori, il tuo ramo personale è in genere un buon punto di partenza. Puoi utilizzare il ramo personale per apportare aggiornamenti rapidi, quindi eseguire il commit delle modifiche e inviarle alla produzione.
Tuttavia, potresti anche voler creare nuovi rami Git oltre al tuo ramo personale. Un nuovo ramo Git è utile in queste situazioni:
- Collabori con altri sviluppatori. Poiché il tuo ramo personale è di sola lettura per gli altri sviluppatori, se vuoi collaborare con altri, devi creare un nuovo ramo Git in modo che gli altri sviluppatori possano scrivere nel ramo. Quando collabori con altre persone, assicurati di recuperare le modifiche ogni volta che riprendi il lavoro. In questo modo, avrai gli ultimi aggiornamenti di tutti gli sviluppatori prima di continuare a lavorare.
- Stai lavorando su più set di funzionalità contemporaneamente. A volte potresti essere nel bel mezzo di un progetto importante, ma vuoi risolvere un problema minore o apportare una correzione rapida. In questo caso, puoi eseguire il commit delle modifiche al ramo su cui ti trovi e poi creare o passare a un altro ramo per lavorare su un insieme separato di funzionalità. Puoi apportare la correzione nel nuovo ramo, quindi eseguire il deployment delle modifiche di questo ramo in produzione prima di riprendere il lavoro nel ramo originale.
Prima di creare un nuovo ramo:
- Se si verifica un conflitto di unione nel ramo corrente, devi risolverlo prima di poter creare un nuovo ramo.
- Se hai modifiche non eseguite nel ramo corrente, devi eseguire il commit delle modifiche nel ramo corrente prima di creare un nuovo ramo.
- Se vuoi creare un ramo a partire da un ramo di sviluppo esistente (e non dal ramo di produzione), recupera prima l'ultima versione del ramo di sviluppo passando a quel ramo di sviluppo, quindi recupera le modifiche remote per sincronizzare la versione locale del ramo.
Per creare un nuovo ramo Git:
- Verifica di aver attivato la modalità sviluppatore.
Vai ai file di progetto nel menu Sviluppo.
Seleziona l'icona Git nel menu delle icone a sinistra per aprire il pannello Azioni Git.
Seleziona il menu a discesa Visualizza filiali.
Seleziona Nuova filiale.
Nella finestra Nuova filiale, inserisci un nome per la filiale. Tieni presente che esistono limitazioni per i nomi dei rami Git. Per i requisiti di denominazione, consulta la sezione Regole per la denominazione di un ramo Git in questa pagina.
Seleziona il menu a discesa Crea da e scegli un ramo esistente da utilizzare come punto di partenza per il nuovo ramo.
Seleziona Crea per creare il ramo.
In alternativa, puoi creare rami Git dalla scheda Gestione rami delle impostazioni del progetto.
Regole per la denominazione di un branch Git
Looker utilizza i requisiti della convenzione di denominazione dei rami specificati da Git.
I nomi dei branch Git non devono:
- Contenere un carattere di spazio
- Contiene un doppio punto:
..
- Contiene una barra rovesciata:
\
- Contiene la sequenza:
@{
- Contenere un punto interrogativo:
?
- Contenere una parentesi quadra aperta:
[
- Contenere un carattere di controllo ASCII:
~
o\^
o:
- Inizia con un punto:
.
- Inizia con il prefisso:
dev-
(riservato ai rami personali degli sviluppatori di Looker) - Termina con una barra:
/
- Termina con l'estensione:
.lock
Inoltre, il nome del ramo può contenere un asterisco (*
) solo se rappresenta un intero componente del percorso (ad esempio foo/*
o bar/*/baz
), nel qual caso viene interpretato come carattere jolly e non come parte del nome effettivo del ramo.
Passaggio a un altro ramo Git
Se si verifica un conflitto di unione nel ramo attuale, devi risolverlo prima di poter passare a un altro ramo.
Inoltre, se hai modifiche non eseguite nel branch corrente, non puoi passare a un branch esistente finché non esegui il commit delle modifiche nel branch corrente.
Per passare a un altro ramo Git:
- Nel progetto, vai al pannello Azioni Git selezionando l'icona Git nel menu delle icone a sinistra.
- Nel riquadro Azioni Git, seleziona il menu a discesa del ramo Git a destra del nome del ramo Git corrente.
- Seleziona il ramo a cui vuoi passare selezionandolo nel menu o digitando il nome del ramo nella casella di ricerca. La ricerca del nome del ramo non distingue tra maiuscole e minuscole. Ad esempio, puoi cercare "DEV" e visualizzare tutti i rami con nomi che includono "dev", "DEV", "Dev" e così via.
Gestione dei rami Git
La scheda Gestione dei rami delle impostazioni del progetto mostra una tabella di tutti i rami Git per il progetto Looker. Per aprire la scheda Gestione filiali, vai prima alle impostazioni del progetto selezionando l'icona Impostazioni dal menu delle icone a sinistra. Quindi, seleziona la scheda Gestione filiali.
Nella scheda Gestione filiali puoi:
- Crea un nuovo ramo selezionando il pulsante Nuovo ramo. Per ulteriori informazioni, consulta la sezione Creare un nuovo ramo Git in questa pagina.
- Cerca i nomi dei branch nella barra di ricerca.
- Aggiorna la tabella selezionando il pulsante Aggiorna.
- Ordina la tabella selezionando il nome di una colonna.
La tabella include le seguenti informazioni:
- Nome: il nome del ramo Git. I rami personali degli sviluppatori di Looker iniziano con
dev-
e includono il nome e il cognome dello sviluppatore. - Stato: la differenza tra la versione locale del ramo e la versione remota del ramo. Ad esempio, lo stato
3 commits behind
indica che la tua versione locale del ramo è indietro rispetto alla versione remota del ramo di tre commit. Poiché Looker utilizza sempre la versione remota di master, la scheda Gestione rami non mostra lo stato della versione locale del ramo master. Il ramo principale può essere sempre considerato aggiornato. - Ultimo aggiornamento: la quantità di tempo trascorsa da quando uno sviluppatore Looker ha eseguito un commit nel ramo.
- Azioni: un pulsante per eliminare il ramo o il motivo per cui il ramo non è idoneo all'eliminazione.
Eliminazione dei rami Git
Nella scheda Gestione filiali, puoi eliminare le filiali che hanno un pulsante Elimina nella tabella. Non puoi eliminare i seguenti rami:
- Il ramo master
- Il tuo ramo attuale
- Il branch personale di uno sviluppatore Looker
Nella tabella, questi rami non hanno un pulsante Elimina. La colonna Azione della tabella mostra invece il motivo per cui il ramo non può essere eliminato.
Non puoi ripristinare un ramo dopo che è stato eliminato. Quando elimini un ramo, Looker rimuove sia la versione locale che quella remota.
Tuttavia, se il ramo è stato creato da un altro sviluppatore Looker o se altri sviluppatori hanno estratto il ramo, questi sviluppatori avranno comunque la loro versione locale del ramo. Se uno sviluppatore Looker esegue commit alla versione locale del ramo e lo esegue il push in produzione, vedrai di nuovo una versione remota del ramo. Questa opzione può essere utile se vuoi ripristinare il ramo. In caso contrario, quando elimini un ramo, tutti gli altri sviluppatori Looker devono eliminare lo stesso ramo per assicurarsi che non possa essere ripristinato accidentalmente da qualcuno che lo invia al repository remoto.
Per eliminare uno o più rami Git dal progetto, vai innanzitutto alle impostazioni del progetto selezionando l'icona Impostazioni dal menu delle icone a sinistra. Quindi, seleziona la scheda Gestione filiali. Nella scheda Gestione filiali, puoi eliminare le filiali in due modi:
- Elimina più rami selezionando prima le caselle di controllo dei rami e poi Elimina rami selezionati.
- Elimina un singolo ramo selezionando Elimina accanto al nome del ramo.
Esecuzione dei comandi Git in Looker
Looker dispone di un'interfaccia integrata che si integra con il tuo servizio Git. Looker mostra il pulsante Git nell'angolo in alto a destra dell'IDE LookML.
Il pulsante Git mostra opzioni diverse a seconda della fase del processo di modifica e deployment in produzione. In generale, l'opzione mostrata sul pulsante è la guida migliore per la tua prossima azione.
Se il ramo dello sviluppatore è sincronizzato con il ramo di produzione, il pulsante Git mostra il messaggio Aggiornato e non è selezionabile.
Una volta configurato il progetto per Git, puoi selezionare il pulsante Azioni Git per aprire il riquadro Azioni Git.
I comandi disponibili nel riquadro Azioni Git dipendono dalla fase del processo di apporto delle modifiche e di deployment in produzione.
Portare le modifiche in produzione
Con l'integrazione Git di Looker predefinita, Looker guida gli sviluppatori attraverso il seguente flusso di lavoro Git:
- Eseguire il commit delle modifiche nel ramo di sviluppo attuale dello sviluppatore (e eseguire test sui dati se il progetto è configurato per richiedere i test prima del deployment)
- Unione del ramo di sviluppo nel ramo di produzione, che per impostazione predefinita si chiama
master
- Deployment del ramo di produzione nell'ambiente di produzione di Looker che verrà presentato agli utenti finali di Looker
Ciò significa che, con l'integrazione Git predefinita, tutti gli sviluppatori uniscono le modifiche in un ramo denominato master
e l'ultimo commit nel ramo master
viene utilizzato per l'ambiente di produzione di Looker.
Per implementazioni Git avanzate, puoi personalizzare questo flusso di lavoro:
- Puoi chiedere agli sviluppatori di inviare richieste di pull per il ramo di produzione Git, anziché consentire loro di unire le modifiche tramite l'IDE Looker. Per maggiori dettagli, consulta la pagina della documentazione Configurazione delle impostazioni del controllo delle versioni del progetto.
- Puoi utilizzare il campo Nome ramo di produzione Git per specificare quale ramo del repository Git deve essere utilizzato da Looker come ramo di destinazione in cui vengono uniti i rami degli sviluppatori Looker. Per maggiori dettagli, consulta la pagina della documentazione Configurazione delle impostazioni del controllo delle versioni del progetto.
- Puoi utilizzare la modalità di deployment avanzata per specificare un nome di tag o SHA di commit diverso da eseguire il deployment nell'ambiente di produzione di Looker, anziché utilizzare l'ultimo commit nel ramo di produzione. Se vuoi eseguire il deployment di un commit da un altro ramo, puoi utilizzare la webhook o l'endpoint API della modalità di deployment avanzata. Per ulteriori dettagli, consulta la pagina della documentazione Modalità di deployment avanzata.
Se vedi un pulsante Configura Git anziché le scelte descritte in questa sezione, devi prima configurare Git per il tuo progetto.
Visualizzazione delle modifiche di cui non è stato eseguito il commit
L'IDE LookML ha diversi indicatori che vengono visualizzati quando sei in modalità di sviluppo e hai modifiche non commit, come descritto nella sezione Contrassegnare aggiunte, modifiche ed eliminazioni della pagina di documentazione Panoramica dell'IDE Looker.
Puoi ottenere un riepilogo delle differenze per tutti i file selezionando l'opzione Visualizza modifiche non sottoposte a commit nel riquadro Azioni Git.
Nella finestra Modifiche non eseguite al progetto, Looker mostra un riepilogo di tutte le modifiche salvate e non eseguite in tutti i file del progetto. Per ogni modifica, Looker mostra quanto segue:
- Il nome del file sostituito e il nome del file aggiunto.
- Il nome del file sostituito (indicato con
---
) e il nome del file aggiunto (indicato con+++
). In molti casi, potrebbero essere visualizzate versioni diverse dello stesso file, con revisioni identificate da--- a/
e+++ b/
. - I file eliminati vengono visualizzati come sostituzione di un file nullo (
+++ /dev/null
). - I file aggiunti vengono visualizzati come sostituzione di un file nullo (
--- /dev/null
).
- Il nome del file sostituito (indicato con
- Il numero di riga in cui inizia la modifica.Ad esempio,
-101,4 +101,4
indica che alla 101ª riga del file sono state rimosse 4 righe e ne sono state aggiunte 4. Un file eliminato con 20 righe mostrerà-1,20 +0,0
per indicare che, nella prima riga del file, sono state rimosse 20 righe e sostituite da zero righe. - Il testo aggiornato:
- Le righe eliminate vengono visualizzate in rosso.
- Le righe aggiunte vengono visualizzate in verde.
Per visualizzare un riepilogo delle differenze per un singolo file, seleziona l'opzione Visualizza modifiche dal menu del file.
Eseguire il commit delle modifiche
Dopo aver apportato e salvato le modifiche al progetto LookML, l'IDE potrebbe richiedere di convalidare il codice LookML. In questo scenario, il pulsante Git mostra il testo Convalida LookML.
Se questo è necessario dipende dall'impostazione del progetto per la qualità del codice. Per ulteriori informazioni sul validatore dei contenuti, consulta la pagina della documentazione Convalida di LookML.
Se un altro sviluppatore ha apportato modifiche al ramo di produzione dall'ultimo aggiornamento del ramo locale, Looker richiede di estrarre questi aggiornamenti dal ramo di produzione. In questo scenario, il pulsante Git mostra il testo Pull from Production.
Se il tuo progetto è abilitato per la modalità di deployment avanzata, il pulsante Git mostra invece il testo Pull from Primary Branch.
Dopo aver salvato le modifiche (e corretto eventuali avvisi o errori LookML, se necessario) ed eseguito il pull dalla produzione (se necessario), il pulsante Git mostra il testo Esegui commit delle modifiche e push.
Se vuoi, puoi prima rivedere le modifiche non confermate prima di confermarle.
Quando è tutto pronto per eseguire il commit delle modifiche, utilizza il pulsante Git per eseguire il commit delle modifiche nel ramo corrente. Looker mostra la finestra di dialogo Commit, che elenca i file aggiunti, modificati o eliminati.
Inserisci un messaggio che descriva brevemente le modifiche e deseleziona le caselle di controllo accanto ai file che non vuoi includere nella sincronizzazione. Quindi, seleziona Esegui commit per eseguire il commit delle modifiche.
Controllo delle PDT non create
Se hai apportato modifiche a qualsiasi PDT nel tuo progetto, è ottimale che tutte le PDT vengano create quando esegui il deployment nella versione di produzione, in modo che le tabelle possano essere utilizzate immediatamente come versioni di produzione. Per controllare lo stato delle PDT nel progetto, seleziona l'icona Integrità progetto per aprire il pannello Integrità progetto, quindi seleziona il pulsante Convalida stato PDT.
Per ulteriori informazioni sul controllo delle PDT non create nel progetto LookML e sull'utilizzo delle tabelle derivate in modalità di sviluppo, consulta la pagina della documentazione Tabelle derivate in Looker.
Esecuzione dei test sui dati
Il tuo progetto può includere uno o più parametri test
che definiscono i test sui dati per verificare la logica del tuo modello LookML. Per informazioni sulla configurazione dei test dei dati nel tuo progetto, consulta la pagina della documentazione del parametro test
.
Se il tuo progetto contiene test dei dati e ti trovi in modalità Development (Sviluppo), puoi avviare i test dei dati del progetto in diversi modi:
- Se le impostazioni del progetto sono configurate in modo da richiedere il superamento dei test sui dati prima del deployment dei file in produzione, l'IDE mostrerà il pulsante Esegui test dopo che avrai commitato le modifiche al progetto per eseguire tutti i test per il progetto, indipendentemente dal file che definisce il test. Devi superare i test sui dati prima di poter eseguire il deployment delle modifiche in produzione.
- Seleziona il pulsante Esegui test sui dati nel riquadro Stato del progetto. Looker eseguirà tutti i test sui dati nel progetto, indipendentemente dal file che definisce il test.
- Seleziona l'opzione Esegui test LookML dal menu del file. Looker eseguirà solo i test definiti nel file corrente.
Una volta eseguiti i test dei dati, nel riquadro Integrità del progetto vengono visualizzati l'avanzamento e i risultati.
- Un test sui dati viene superato quando l'asserzione del test è vera per ogni riga della query del test. Consulta la pagina di documentazione dei parametri
test
per informazioni dettagliate sulla configurazione di asserzioni e query di test. - Se un test dei dati non va a buon fine, il riquadro Stato del progetto fornisce informazioni sul motivo per cui il test non è riuscito, se ha rilevato errori nella logica del modello o se il test stesso non era valido.
- Dai risultati del test dei dati, puoi selezionare il nome di un test dei dati per andare direttamente al LookML per il test dei dati oppure puoi selezionare il pulsante Query di esplorazione per aprire un'esplorazione con la query definita nel test dei dati.
Esegui il deployment in produzione
Una volta eseguito il commit delle modifiche al ramo, l'IDE di Looker ti chiederà di unire le modifiche al ramo principale. Il tipo di prompt visualizzato nell'IDE dipende dalla configurazione del progetto:
- Se il tuo progetto è configurato per la modalità di deployment avanzata, l'IDE ti chiederà di unire le modifiche al ramo principale. Una volta unito il commit, uno sviluppatore Looker con l'autorizzazione
deploy
può eseguirne il deployment in produzione utilizzando Deployment Manager di Looker IDE oppure un webhook o un endpoint API. - Se il tuo progetto è configurato per l'integrazione Git tramite richieste di pull, ti verrà chiesto di aprire una richiesta di pull utilizzando l'interfaccia del tuo provider Git.
- In caso contrario, con l'integrazione Git di Looker predefinita, se disponi dell'autorizzazione
deploy
, l'IDE di Looker ti chiederà di unire le modifiche al branch di produzione e di implementarle nella versione di produzione della tua istanza di Looker.
Modalità di deployment avanzata
Con l'integrazione Git predefinita di Looker, gli sviluppatori di Looker eseguono il commit delle modifiche al ramo di sviluppo, quindi uniscono il ramo di sviluppo al ramo di produzione. Poi, quando esegui il deployment nell'ambiente Looker, Looker utilizza l'ultimo commit nel ramo di produzione. Per il flusso di lavoro Git predefinito e altre opzioni per implementazioni Git avanzate, consulta la sezione Trasferire le modifiche in produzione in questa pagina.
Nei casi in cui non vuoi che venga sempre utilizzato l'ultimo commit nel ramo di produzione per il tuo ambiente Looker, uno sviluppatore con l'autorizzazione deploy
può utilizzare la modalità di deployment avanzata per specificare il commit esatto da utilizzare per il tuo ambiente Looker. Ciò è utile nei flussi di lavoro degli sviluppatori multi-ambiente, in cui ogni ambiente punta a una versione diversa di una codebase. Inoltre, consente a uno o più sviluppatori o amministratori di avere un maggiore controllo sulle modifiche di cui viene eseguito il deployment in produzione.
Quando la modalità di deployment avanzata è abilitata, l'IDE di Looker non chiede agli sviluppatori di eseguire il deployment delle modifiche in produzione. L'IDE chiede invece agli sviluppatori di unire le modifiche nel ramo di produzione. Da qui, le modifiche possono essere implementate solo nei seguenti modi:
- Utilizzare Deployment Manager nell'IDE di Looker
- Attivazione di un webhook
Utilizzo di un endpoint API
Per ulteriori dettagli, consulta la pagina della documentazione Modalità di deployment avanzata.
Controllare l'impatto delle modifiche
Dopo aver reso disponibili le modifiche all'organizzazione, puoi utilizzare la convalida dei contenuti per assicurarti di non aver invalidato dashboard o Look salvati. Se hai commesso errori, avrai l'opportunità di correggerli.
Gestione dei problemi tipici
Mentre lavori al modello, potresti dover:
Ignora le modifiche
A volte potresti voler abbandonare le modifiche alla modellazione dei dati. Se non sono ancora stati salvati, puoi semplicemente aggiornare o uscire dalla pagina e accettare il prompt di avviso. Se hai salvato le modifiche, puoi ripristinare quelle di cui non è stato eseguito il commit come descritto nella sezione Ripristinare le modifiche di cui non è stato eseguito il commit.
Gestire i conflitti di unione con il lavoro di altri sviluppatori
Se più sviluppatori lavorano al tuo modello dei dati, in genere Git gestisce la situazione. Tuttavia, a volte Git ha bisogno di un intervento umano per risolvere i conflitti di unione.
Alcune modifiche, ad esempio quella del nome di un campo, possono influire sui dashboard e sui Look esistenti. Come accennato in precedenza, dopo aver reso disponibili le modifiche all'organizzazione, puoi utilizzare la convalida dei contenuti per controllare i contenuti e risolvere eventuali problemi.
Annullamento delle modifiche di cui non è stato eseguito il commit
Quando lavori sul tuo ramo di sviluppo personale, puoi ripristinare le modifiche salvate che non hai eseguito il commit se non vuoi eseguirne il deployment. Puoi ripristinare tutte le modifiche non eseguite per tutti i file del progetto o solo le modifiche in un singolo file.
Per annullare le modifiche di cui non è stato eseguito il commit per tutti i file:
- Seleziona l'opzione Ripristina… nel riquadro Azioni Git.
- Seleziona un'opzione di ripristino:
- Per ripristinare solo le modifiche di cui non è stato eseguito il commit, seleziona Annulla modifiche di cui non è stato eseguito il commit. Puoi anche selezionare il link Visualizza modifiche per visualizzare le modifiche che verranno ripristinate.
- Per ripristinare tutte le modifiche, comprese quelle di cui non è stato eseguito il commit e quelle di cui è stato eseguito il commit, seleziona Ripristina produzione.
- Per completare la procedura di ripristino, seleziona Conferma.
Per ripristinare eventuali aggiunte o eliminazioni nei contenuti di un singolo file, seleziona l'opzione Ripristina modifiche dal menu del file:
Quando rinomini un file, elimini essenzialmente il file originale e ne crei uno nuovo con un nuovo nome. Poiché l'operazione riguarda più di un file, non puoi utilizzare l'opzione Ripristina file per annullare la ridenominazione di un file. Se vuoi annullare la ridenominazione di un file, utilizza l'opzione Ripristina... nel riquadro Azioni Git.
Inoltre, se hai eliminato un file, questo non viene più visualizzato nel browser dei file dell'IDE. Se vuoi annullare l'eliminazione di un file, utilizza l'opzione Ripristina... nel riquadro Azioni Git.
Risoluzione dei conflitti di unione
In genere, Git può unire automaticamente le nuove modifiche alla versione di produzione dei file LookML. Si verifica un conflitto di unione quando Git rileva modifiche in conflitto e non riesce a identificare quali modifiche devono essere mantenute, in genere quando un altro sviluppatore ha apportato modifiche dall'ultima volta che hai eseguito il pull e hai apportato modifiche nella stessa area. Se si verifica un conflitto di unione nel codice, Looker mostra un avviso Conflitti di unione dopo il commit delle modifiche e il pull dalla produzione.
Quando Looker mostra l'avviso di conflitto di unione, ti consigliamo di risolvere il conflitto di unione prima di apportare ulteriori modifiche. Il push di un conflitto di unione in produzione causerà errori di analisi che potrebbero impedire l'esplorazione dei dati. Se sei un utente Git avanzato e vuoi procedere con il push delle modifiche, seleziona il pulsante Non risolvere.
Nel file LookML stesso, le righe con conflitti sono contrassegnate nel seguente modo:
<<<<<<< HEAD
Your code
=======
Production code
>>>>>>> branch 'master'
Looker mostra i seguenti indicatori di unione per indicare i conflitti di unione:
- <<<<<<<
HEAD
segna l'inizio delle righe in conflitto. - >>>>>>>
branch 'master'
indica la fine delle righe in conflitto. - ======= separa ogni versione del codice per consentirti di confrontarle.
Nell'esempio precedente, your code
rappresenta le modifiche che hai eseguito e production code
rappresenta il codice in cui Git non è riuscito a unire automaticamente le modifiche.
Per risolvere un conflitto di unione:
- Trova i file con conflitti di unione. Looker contrassegna questi file in rosso oppure puoi anche cercare nel progetto i marcatori di unione, ad esempio <<<< o
HEAD
, per trovare tutti i conflitti nel progetto. Puoi anche trovare i file interessati selezionando il link file nell'avviso di unione visualizzato nel riquadro Azioni Git. - Nel file, vai alle righe con conflitti di unione ed elimina la versione del testo che NON vuoi conservare, nonché tutti i marcatori di conflitti di unione.
Salva il file e ripeti i passaggi precedenti per tutti gli altri file contrassegnati con conflitti di unione.
Dopo aver risolto tutti i conflitti di unione ed eliminato tutti i marcatori di unione dal progetto, esegui il commit delle modifiche ed esegui il deployment in produzione.
Ora che hai risolto il conflitto di unione e hai eseguito il push della soluzione in produzione, gli altri sviluppatori possono eseguire il pull dalla produzione e continuare a lavorare come di consueto.
Garbage collection di Git
La raccolta dei rifiuti di Git pulisce i file non necessari e comprime le revisioni dei file per ottimizzare il repository Git. La garbage collection di Git (git gc
) viene eseguita automaticamente quando l'istanza Looker viene aggiornata o riavviata. Per evitare di eseguire git gc
troppo spesso, Looker attende 30 giorni dall'ultimo git gc
, quindi esegue git gc
al successivo riavvio.
In rari casi, potresti provare a Esegui il push delle modifiche a remoto o Esegui il push del ramo a remoto mentre è in esecuzione git gc
. Se Looker mostra un errore, attendi un minuto o due e riprova a eseguire il push delle modifiche.