Questa pagina presuppone che il progetto sia già stato configurato per il controllo della versione. Se vedi un pulsante Configura Git anziché le opzioni 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 sviluppatore è correlato 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 della connessione Git.
Utilizzo dei rami Git
Uno dei principali vantaggi di Git è che uno sviluppatore di Looker può lavorare in un ramo, 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 sei in modalità di sviluppo.
Un'altra caratteristica importante di Git è la facilità di collaborazione con altri sviluppatori. Puoi creare un ramo e, se vuoi, apportare modifiche. In seguito, altri sviluppatori possono passare a quel ramo per esaminarlo o apportare modifiche. Se un altro sviluppatore ha eseguito il commit delle modifiche al ramo, Looker visualizza il pulsante Pull Remote changes (Esegui il pull delle modifiche remote). Devi eseguire il pull delle modifiche sottoposte a commit nel ramo prima di apportare ulteriori modifiche.
Puoi anche eliminare un ramo diverso da quello principale, il ramo attuale o il ramo personale di uno sviluppatore.
Rami personali
La prima volta che attivi la modalità di sviluppo, Looker crea automaticamente il tuo ramo Git personale. 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 gli altri possano passare a quel ramo e apportare modifiche.
Creazione di un nuovo ramo Git
Se stai lavorando a una correzione semplice e non collabori con altri sviluppatori, il tuo ramo personale è di solito un buon posto per lavorare. Puoi utilizzare il tuo ramo personale per apportare aggiornamenti rapidi, quindi eseguire il commit delle modifiche ed eseguirne il push in produzione.
Tuttavia, ti consigliamo di 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, riceverai gli ultimi aggiornamenti da tutti gli sviluppatori prima di continuare a lavorare.
- Stai lavorando su più insiemi di funzionalità contemporaneamente. A volte potresti essere nel bel mezzo di un progetto importante, ma voler risolvere un problema di minore entità o trovare una soluzione rapida. In questo caso, puoi eseguire il commit delle modifiche nel ramo in cui ti trovi e poi creare o passare a un altro ramo per lavorare su un insieme distinto di funzionalità. Puoi apportare la correzione nel nuovo ramo, quindi eseguire il deployment delle modifiche del 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 risolvere il conflitto prima di poter creare un nuovo ramo.
- Se esistono modifiche non impegnate nel ramo attuale, devi eseguire il commit delle modifiche nel ramo attuale prima di crearne uno nuovo.
- Se vuoi creare un ramo a partire da un ramo di sviluppo esistente (e non dal ramo di produzione), ottieni prima la versione più recente del ramo di sviluppo passando a quel ramo, quindi esegui il pull delle modifiche remote per sincronizzare la versione locale del ramo.
Per creare un nuovo ramo Git:
- Verifica di avere attivato la modalità di sviluppo.
Vai ai file di progetto nel menu Sviluppo.
Seleziona l'icona Git nel menu delle icone a sinistra per aprire il riquadro Azioni Git.
Seleziona il menu a discesa Visualizza rami.
Seleziona Nuovo ramo.
Nella finestra Nuovo ramo, inserisci un nome per la filiale. Tieni presente che esistono limitazioni per i nomi dei rami Git. Per i requisiti di denominazione, consulta le regole per la denominazione di un ramo Git in questa pagina.
Seleziona il menu a discesa Crea da e seleziona 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 dei rami delle impostazioni del progetto.
Regole per la denominazione di un ramo Git
Looker utilizza i requisiti della convenzione di denominazione dei rami specificati da Git.
I nomi dei rami Git non devono:
- Contenere uno spazio
- Contiene un doppio punto:
.. - Contiene una barra rovesciata:
\ - Contiene la sequenza:
@{ - Contengono un punto interrogativo:
? - Contiene una parentesi graffa aperta:
[ - Contiene un carattere di controllo ASCII:
~o\^o: - Inizia con un ciclo:
. - 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 esiste un conflitto di unione nel ramo attuale, devi risolverlo prima di poter passare a un ramo diverso.
Inoltre, se hai modifiche non committate nel ramo corrente, non puoi passare a un ramo esistente finché non committi le modifiche nel ramo corrente.
Per passare a un altro ramo Git:
- Nel progetto, vai al riquadro 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 della filiale non fa distinzione tra maiuscole e minuscole. Ad esempio, puoi cercare "DEV". e vedi 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 sedi, vai prima alle impostazioni del progetto selezionando l'icona Impostazioni dal menu delle icone a sinistra. Seleziona la scheda Gestione sedi.
Nella scheda Gestione rami 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 delle filiali 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. Looker Developers I rami personali 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, uno stato
3 commits behindindica che la versione locale del ramo è in ritardo rispetto alla versione remota del ramo di tre commit. Poiché Looker utilizza sempre la versione remota del master, la scheda Gestione dei branch non mostra lo stato della versione locale del branch master. Il ramo master può essere sempre considerato aggiornato. - Ultimo aggiornamento: tempo trascorso dall'ultimo commit eseguito da uno sviluppatore di Looker 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 sedi, puoi eliminare i reparti che hanno un pulsante Elimina nella tabella. Non puoi eliminare i seguenti rami:
- Il ramo master
- Il tuo ramo attuale
- Il ramo 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 averlo eliminato. Quando elimini un ramo, Looker rimuove sia la versione locale del ramo sia la versione remota del ramo.
Tuttavia, se il ramo è stato creato da un altro sviluppatore di Looker o se altri sviluppatori hanno eseguito il check-out del ramo, questi sviluppatori avranno comunque la propria versione locale del ramo. Se uno sviluppatore di Looker esegue il commit della propria versione locale del ramo e ne 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 di Looker devono eliminare lo stesso ramo per assicurarsi che non possa essere visualizzato accidentalmente da qualcuno che lo spinge in remoto.
Per eliminare uno o più rami Git dal tuo progetto, vai prima alle impostazioni del progetto selezionando l'icona Settings (Impostazioni) dal menu delle icone a sinistra. Poi seleziona la scheda Gestione rami. Nella scheda Gestione sedi, puoi eliminare i reparti in due modi:
- Elimina più rami selezionando prima le relative caselle di controllo, quindi Elimina rami selezionati.
- Elimina un singolo ramo selezionando Elimina accanto al nome del ramo.
Esecuzione dei comandi Git in Looker
Looker ha un'interfaccia integrata che si integra con il tuo servizio Git. Looker visualizza il pulsante Git nell'angolo in alto a destra dell'IDE LookML.
Il pulsante Git mostra opzioni diverse a seconda della fase di modifica e deployment in produzione. In genere, l'opzione mostrata sul pulsante è la guida migliore per la tua prossima azione.
Se il ramo sviluppatore è sincronizzato con il ramo di produzione, il pulsante Git mostra il messaggio Aggiornato e non è selezionabile.
Dopo che il progetto è configurato per Git, puoi selezionare il pulsante Azioni Git per aprire il riquadro Azioni Git.
I comandi disponibili nel riquadro Azioni Git dipendono da dove ti trovi nelle modifiche e nel deployment in produzione.
Apportare le modifiche in produzione
Con l'integrazione di Git di Looker predefinita, Looker guida gli sviluppatori attraverso il seguente flusso di lavoro Git:
- Eseguire il commit delle modifiche nel ramo di sviluppo corrente dello sviluppatore (e eseguire test sui dati se il progetto è configurato per richiedere test prima del deployment)
- Unione del ramo di sviluppo nel ramo di produzione, chiamato per impostazione predefinita
master - Deployment del ramo di produzione nell'ambiente di produzione Looker che verrà presentato agli utenti finali di Looker
Ciò significa che, con l'integrazione Git predefinita, tutti gli sviluppatori uniscono le proprie modifiche in un ramo denominato master e l'ultimo commit sul ramo master è quello utilizzato per l'ambiente di produzione di Looker.
Per implementazioni Git avanzate, puoi personalizzare questo flusso di lavoro:
- Puoi chiedere ai tuoi sviluppatori di inviare richieste di pull per il tuo ramo produzione Git, invece di consentire loro di unire le loro modifiche tramite l'IDE di Looker. Per maggiori dettagli, consulta la pagina della documentazione Configurazione delle impostazioni di controllo della versione del progetto.
- Puoi utilizzare il campo Nome ramo di produzione Git per specificare quale ramo del tuo repository Git deve essere utilizzato da Looker come ramo di destinazione in cui gli sviluppatori Looker i rami vengono uniti. Per maggiori dettagli, consulta la pagina della documentazione Configurare le impostazioni di controllo della versione del progetto.
- Puoi utilizzare la modalità di deployment avanzata per specificare un nome tag o SHA commit diverso da eseguire nel tuo ambiente di produzione di Looker, anziché utilizzare l'ultimo commit nel ramo di produzione. Se vuoi eseguire il deployment di un commit da un ramo diverso, puoi utilizzare la modalità di deployment avanzata webhook o endpoint API. Per maggiori dettagli, consulta la pagina della documentazione relativa alla 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 include diversi indicatori che vengono visualizzati quando sei in modalità di sviluppo e sono presenti modifiche non impegnate, come descritto nella sezione Contrassegnare aggiunte, modifiche ed eliminazioni della pagina della documentazione Panoramica dell'IDE Looker.
Puoi ottenere un riepilogo delle differenze per tutti i file selezionando l'opzione Visualizza modifiche di cui non è stato eseguito il commit dal riquadro Azioni Git.
Nella finestra Modifiche non committate al progetto, Looker mostra un riepilogo di tutte le modifiche salvate non committate 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 mostrate versioni diverse dello stesso file, con le revisioni identificate da--- a/e+++ b/. - I file eliminati vengono visualizzati come sostituti di un file nullo (
+++ /dev/null). - I file aggiunti vengono visualizzati come file che sostituiscono un file null (
--- /dev/null).
- Il nome del file sostituito (indicato con
- Il numero di riga in cui inizia la modifica.Ad esempio,
-101,4 +101,4indica che, nella riga 101 del file, sono state rimosse 4 righe e aggiunte 4 righe. Un file eliminato con 20 righe mostrerebbe-1,20 +0,0per indicare che, nella prima riga del file, 20 righe sono state rimosse e sostituite da zero righe. - Il testo che è stato aggiornato:
- Le righe eliminate vengono visualizzate in rosso.
- Le linee 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 eventuali modifiche al tuo progetto LookML, l'IDE potrebbe richiedere di convalidare il tuo LookML. In questo caso, il pulsante Git mostra il testo Convalida LookML.
La necessità di eseguire questa operazione dipende dall'impostazione della qualità del codice nel progetto. Per saperne di più sullo strumento di convalida dei contenuti, consulta la pagina della documentazione Convalida di LookML.
Se un altro sviluppatore ha apportato modifiche al ramo produzione dall'ultima volta che hai aggiornato il ramo locale, Looker richiede di eseguire il pull di questi aggiornamenti dal ramo produzione. In questo caso, il pulsante Git mostra il testo Esegui pull da produzione.
Se per il tuo progetto è attivata la modalità di deployment avanzato, il pulsante Git mostra invece il testo Pull from Primary Branch.
Dopo aver salvato le modifiche (e corretto eventuali avvisi o errori di LookML, se necessario) e aver eseguito il pull dalla produzione (se necessario), il pulsante Git mostra il testo Commit Changes & Push (Esegui commit delle modifiche e push).
Se vuoi, puoi esaminare le modifiche di cui non hai eseguito il commit prima di sottoscriverle.
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 che sono stati 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 Commit per applicare le modifiche.
Controllo della presenza di PDT non create
Se hai apportato modifiche a qualsiasi PDT nel tuo progetto, è ottimale che tutte le PDT vengano create al momento del deployment in 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 Project Health (Integrità progetto) per aprire il riquadro Project Health (Integrità del progetto), quindi seleziona il pulsante Convalida stato PDT.
Consulta la pagina della documentazione Tabelle derivate in Looker per saperne di più sul controllo delle PDT non create nel progetto LookML e sull'utilizzo delle tabelle derivate in modalità di sviluppo.
Esecuzione dei test dei dati
Il progetto può includere uno o più parametri test che definiscono i test dei dati per verificare la logica del modello LookML. Per informazioni sulla configurazione dei test dei dati nel progetto, consulta la pagina della documentazione del parametro test.
Se il progetto contiene test sui dati e ti trovi in modalità di sviluppo, puoi avviarli in diversi modi:
- Se le impostazioni del progetto sono configurate in modo da richiedere il superamento dei test sui dati prima di eseguire il deployment dei file in produzione, l'IDE mostrerà il pulsante Esegui test dopo che hai eseguito il commit delle modifiche al progetto per eseguire tutti i test per il tuo 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 Integrità del progetto. Looker eseguirà tutti i test sui dati nel progetto, indipendentemente dal file che li definisce.
- Seleziona l'opzione Esegui test LookML dal menu del file. Looker eseguirà solo i test definiti nel file attuale.
Una volta eseguiti i test dei dati, il riquadro Stato del progetto mostra l'avanzamento e i risultati.
- Un test di dati è superato quando l'affermazione del test è vera per ogni riga della query del test. Per informazioni dettagliate sulla configurazione di asserzioni e query di test, consulta la pagina della documentazione del parametro
test. - Se un test sui dati ha esito negativo, il riquadro Project Health fornisce informazioni sul motivo per cui il test non è riuscito, se il test ha rilevato errori nella logica del modello o se il test stesso non è valido.
- Dai risultati del test sui dati, puoi selezionare il nome di un test sui dati da accedere direttamente al LookML del test sui dati oppure puoi selezionare il pulsante Esplora query 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 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 di Looker con l'autorizzazione
deploypuò eseguire il deployment del commit in produzione utilizzando il deployment manager dell'IDE di Looker oppure un webhook o un endpoint API. - Se il tuo progetto è configurato per l'integrazione Git utilizzando le 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 predefinita di Looker Git, se disponi dell'autorizzazione
deploy, l'IDE di Looker ti chiederà di unire le modifiche al ramo di produzione e di eseguirne il deployment nella versione di produzione dell'istanza di Looker.
Modalità di deployment avanzata
Con l'integrazione di Git di Looker predefinita, gli sviluppatori di Looker eseguono il commit delle modifiche nel 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 sul ramo di produzione. Consulta la sezione Eseguire il push delle modifiche in produzione in questa pagina per il flusso di lavoro Git predefinito e altre opzioni per le implementazioni avanzate di Git.
Se non vuoi utilizzare sempre l'ultimo commit sul ramo di produzione per il tuo ambiente Looker, uno sviluppatore con autorizzazione deploy può utilizzare la modalità di deployment avanzata per specificare il commit esatto da utilizzare per il tuo ambiente Looker. Questa opzione è utile nei flussi di lavoro degli sviluppatori con più ambienti, in cui ogni ambiente punta a una versione diversa di una base di codice. Offre inoltre a uno o più sviluppatori o amministratori un maggiore controllo sulle modifiche di cui viene eseguito il deployment in produzione.
Quando la modalità di deployment avanzata è attivata, l'IDE di Looker non chiede agli sviluppatori di eseguire il deployment delle modifiche in produzione. L'IDE richiede invece agli sviluppatori di unire le modifiche nel ramo di produzione. Da qui, il deployment delle modifiche può essere eseguito solo nei seguenti modi:
- Uso di deployment Manager nell'IDE di Looker
- Attivazione di un webhook
Utilizzo di un endpoint API
Per maggiori dettagli, consulta la pagina della documentazione relativa alla modalità di deployment avanzata.
Verifica dell'impatto delle modifiche
Dopo aver reso disponibili le modifiche per l'organizzazione, puoi utilizzare la convalida dei contenuti per assicurarti di non aver invalidato nessuna dashboard o salvato i Look. Avrai la possibilità di correggerli, se possibile.
Gestione dei problemi tipici
Mentre lavori sul modello, potresti dover:
Ignora le modifiche
A volte potresti voler abbandonare le modifiche alla definizione del modello di dati. Se non sono ancora state salvate, puoi semplicemente aggiornare la pagina o uscire dalla pagina e accettare il messaggio di avviso. Se hai salvato le modifiche, puoi ripristinare quelle di cui non è stato eseguito il commit come descritto nella sezione Annullamento delle 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 di 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, come la modifica del nome di un campo, possono influire sulle dashboard e sui Look esistenti. Come indicato in precedenza, dopo aver reso disponibili le modifiche all'organizzazione, puoi utilizzare la convalida dei contenuti per controllare i contenuti e risolvere eventuali problemi.
Annullare le modifiche di cui non è stato eseguito il commit
Quando lavori sul ramo dello sviluppo personale, puoi annullare le modifiche non confermate che hai salvato se non vuoi eseguirne il deployment. Puoi annullare tutte le modifiche di cui non è stato eseguito il commit 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 annullare 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 annullate.
- Per annullare tutte le modifiche, incluse quelle non impegnate e di cui è stato eseguito il commit, seleziona Ripristina in produzione
- Per completare il processo di ripristino, seleziona Conferma.
Per annullare eventuali aggiunte o eliminazioni nei contenuti di un singolo file, seleziona l'opzione Ripristina modifiche dal menu del file:
Quando rinomini un file, sostanzialmente elimini il file originale e ne crei uno nuovo con un nuovo nome. Poiché ciò 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 di file IDE. Se vuoi ripristinare l'eliminazione di un file, utilizza l'opzione Ripristina in... nel riquadro Azioni Git.
Risoluzione dei conflitti di unione
In genere, Git può unire automaticamente le nuove modifiche con la versione di produzione dei file LookML. Un conflitto di unione si verifica quando Git rileva modifiche in conflitto e non è in grado di identificare quali modifiche devono essere conservate, in genere quando un altro sviluppatore ha apportato modifiche dall'ultima operazione di pull e tu hai apportato modifiche nella stessa area. Se nel codice si verifica un conflitto di unione, Looker mostra un avviso Conflitti di unione dopo aver eseguito il commit delle modifiche e aver eseguito 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. L'invio 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 l'invio delle modifiche, seleziona il pulsante Non risolvere.
Nel file LookML stesso, le righe con conflitti sono contrassegnate come segue:
<<<<<<< HEAD
Your code
=======
Production code
>>>>>>> branch 'master'
Looker mostra i seguenti indicatori di unione per indicare i conflitti di unione:
- <<<<<<<
HEADsegna l'inizio delle righe in conflitto. - >>>>>>>
branch 'master'indica la fine delle righe in conflitto. - ======= separa ogni versione del codice in modo da poterle confrontare.
Nell'esempio precedente, your code rappresenta le modifiche di cui hai eseguito il commit, mentre production code rappresenta il codice in cui Git non ha potuto 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 tuo progetto indicatori di unione, come <<<< o
HEAD, per trovare tutti i conflitti nel tuo progetto. Puoi trovare i file interessati anche selezionando il link file nell'avviso di unione visualizzato nel riquadro Azioni Git. - Nel file, vai alle righe che presentano conflitti di unione, elimina la versione del testo che NON vuoi conservare ed elimina tutti gli indicatori di conflitto di unione.
Salva il file e ripeti i passaggi precedenti per gli altri file contrassegnati da conflitti di unione.
Dopo aver risolto tutti i conflitti di unione ed eliminato tutti gli indicatori di unione dal progetto, esegui il commit delle modifiche e esegui il deployment in produzione.
Ora che hai risolto il conflitto di unione e trasferito la risoluzione in produzione, gli altri sviluppatori possono eseguire il pull dalla produzione e continuare a lavorare come di consueto.
Garbage collection di Git
La garbage collection di Git ripulisce i file non necessari e comprime le revisioni dei file per ottimizzare il repository Git. La garbage collection Git (git gc) viene eseguita automaticamente quando l'istanza di 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 riavvio successivo.
In rari casi, puoi provare a Esegui il push delle modifiche a remoto o Esegui il push del ramo a remoto mentre git gc è in esecuzione. Se Looker visualizza un errore, attendi un minuto o due e poi riprova a eseguire il push delle modifiche.