Questa pagina presuppone che il progetto sia già stato configurato per il controllo della versione. Se visualizzi 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 sviluppatori è 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 Configurare e testare una connessione Git.
Utilizzo dei rami Git
Uno dei principali vantaggi di Git è che uno sviluppatore Looker può lavorare in un ramo, una versione isolata di un repository di file. Puoi sviluppare ed eseguire test 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 gli altri sviluppatori che fornisce. Puoi creare un ramo e, se vuoi, apportare modifiche, dopodiché gli altri sviluppatori possono passare a quel ramo per esaminarlo o modificarlo. Se un altro sviluppatore ha eseguito il commit delle modifiche al ramo, Looker mostra il pulsante Esegui il pull delle modifiche remote. Devi eseguire il pull delle modifiche di cui hai eseguito il commit al ramo prima di apportarne altre.
Puoi anche eliminare un ramo diverso dal ramo principale, dal ramo attuale o dal ramo personale di uno sviluppatore.
Rami personali
La prima volta che accedi alla modalità di sviluppo, Looker crea automaticamente il 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 stai collaborando con altri sviluppatori a un progetto, potresti voler creare un nuovo ramo in modo che anche altri utenti possano passare a quel ramo e contribuire alle modifiche.
Creazione di un nuovo ramo Git in corso...
Se stai lavorando a una soluzione semplice e non collabori con altri sviluppatori, il tuo ramo personale di solito è un buon posto di lavoro. Puoi utilizzare il tuo ramo personale per apportare aggiornamenti rapidi, quindi eseguire il commit delle modifiche ed eseguirne il push in produzione.
Tuttavia, potresti voler creare nuovi rami Git oltre al tuo ramo personale. Un nuovo ramo Git ha senso in queste situazioni:
- Stai collaborando 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 altri sviluppatori possano scrivere nel ramo. Quando collabori con gli altri, assicurati di apportare 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 grande progetto, ma vuoi risolvere un problema di minore entità o apportare una soluzione rapida. In questo caso, puoi eseguire il commit delle modifiche nel ramo in cui ti trovi, quindi crearne o passare a un altro ramo per lavorare su un insieme di caratteristiche separato. Puoi apportare la correzione nel nuovo ramo e 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 esiste un conflitto di unione nel ramo attuale, devi risolvere il conflitto prima di poter creare un nuovo ramo.
- Se sono presenti modifiche di cui non è stato eseguito il commit nel ramo attuale, devi eseguire il commit delle modifiche nel ramo attuale 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), prima ottieni l'ultima versione del ramo passando a quel ramo, quindi esegui il pull delle modifiche remote per sincronizzare la tua 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 dell'icona 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, vedi 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 della pagina Impostazioni 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:
.. - Contenere una barra rovesciata:
\ - Contenere la sequenza:
@{ - Contenere un punto interrogativo:
? - Contenere una parentesi quadra aperta:
[ - Contenere un carattere di controllo ASCII:
~,\^o: - Inizia con un punto:
. - Inizia con il prefisso:
dev-(riservato ai rami personali degli sviluppatori Looker) - Termina con una barra:
/ - Termina con l'estensione:
.lock
Inoltre, il nome del ramo può contenere solo un asterisco (*) 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 risolvere il conflitto prima di poter passare a un ramo diverso.
Inoltre, se hai modifiche di cui non è stato eseguito il commit nel ramo attuale, non puoi passare a un ramo esistente finché non esegui il commit delle modifiche nel ramo attuale.
Per passare a un ramo Git diverso, segui questi passaggi:
- Nel progetto, vai al riquadro Azioni Git selezionando l'icona Git nel menu dell'icona 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 dei nomi dei rami non fa distinzione 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 rami della pagina Impostazioni progetto mostra una tabella di tutti i rami Git del progetto Looker. Per aprire la scheda Gestione rami, passa prima alla pagina Impostazioni progetto selezionando l'icona Impostazioni dal menu dell'icona a sinistra. Quindi, seleziona la scheda Gestione rami.
Nella scheda Gestione rami puoi:
- Crea un nuovo ramo selezionando il pulsante Nuovo ramo. Per ulteriori informazioni, consulta la sezione Creazione di un nuovo ramo Git in questa pagina.
- Cerca i nomi dei rami 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: nome del ramo Git. I rami personali degli sviluppatori di Looker iniziano con
dev-e includono nome e cognome dello sviluppatore. - Stato: la differenza tra la versione locale del ramo e la versione remota del ramo. Ad esempio, lo stato
3 commits behindsignifica che la tua versione locale del ramo si trova dietro alla versione remota del ramo di tre commit. Poiché Looker utilizza sempre la versione remota del ramo principale, la scheda Gestione rami non mostra lo stato della versione locale del ramo principale. Il ramo principale può essere sempre considerato aggiornato. - Ultimo aggiornamento: periodo di tempo trascorso da quando uno sviluppatore Looker ha effettuato l'impegno nel ramo.
- Azioni: un pulsante per eliminare il ramo o il motivo per cui il ramo non è idoneo per l'eliminazione.
Eliminazione dei rami Git
Dalla scheda Gestione rami puoi eliminare i rami che hanno un pulsante Elimina nella tabella. Non puoi eliminare i rami seguenti:
- Il ramo master
- Il tuo ramo attuale
- Un ramo personale di uno sviluppatore Looker
Nella tabella, questi rami non dispongono di un pulsante Elimina. La colonna Azione della tabella mostra il motivo per cui non è possibile eliminare il ramo.
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 controllato il ramo, questi disporranno comunque della loro versione locale. Se uno sviluppatore Looker esegue commit alla versione locale del ramo e ne esegue il push in produzione, vedrai di nuovo una versione remota del ramo. Questo può essere utile se vuoi ripristinare il ramo. Altrimenti, quando elimini un ramo, tutti gli altri sviluppatori di Looker devono eliminarlo per garantire che non possa essere visualizzato accidentalmente da qualcuno che ne esegue il push.
Per eliminare uno o più rami Git dal tuo progetto, vai prima alla pagina Impostazioni progetto selezionando l'icona Impostazioni dal menu dell'icona a sinistra. Quindi, seleziona la scheda Gestione rami. Nella scheda Gestione rami puoi eliminare i rami 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 in cui ti trovi nel processo di modifica e deployment in produzione. In generale, l'opzione mostrata sul pulsante è la migliore guida per l'azione successiva.
Se il ramo degli sviluppatori è sincronizzato con il ramo di produzione, il pulsante Git mostra il messaggio Aggiornato e non è selezionabile.
Dopo aver 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 da dove ti trovi nel processo di modifica e deployment in produzione.
Trasferimento delle modifiche in produzione
Con l'integrazione predefinita di Looker per Git, Looker chiede agli sviluppatori di utilizzare il seguente flusso di lavoro Git:
- Eseguire il commit delle modifiche nel ramo di sviluppo attuale dello sviluppatore (ed eseguire test sui dati se il progetto è configurato in modo da richiedere i test prima del deployment)
- Fusione del ramo di sviluppo nel ramo di produzione, chiamato per impostazione predefinita
master - Deployment del ramo di produzione nell'ambiente di produzione di Looker che sarà 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 le implementazioni Git avanzate, puoi personalizzare questo flusso di lavoro:
- Puoi chiedere agli sviluppatori di inviare richieste di pull per il ramo di produzione Git, invece di consentire loro di unire le modifiche tramite l'IDE Looker. Per maggiori dettagli, consulta la pagina della documentazione Configurazione delle impostazioni del controllo della versione del progetto.
- Puoi utilizzare il campo Nome ramo di produzione Git per specificare il ramo del repository Git che deve essere utilizzato 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 della versione del progetto.
- Puoi utilizzare la modalità di deployment avanzata per specificare una SHA o un nome di tag diverso per il deployment nell'ambiente di produzione di Looker, anziché utilizzare il commit più recente nel ramo di produzione. (se vuoi eseguire il deployment di un commit da un ramo diverso, puoi utilizzare il webhook o l'endpoint API in modalità di deployment avanzata). Per maggiori dettagli, consulta la pagina della documentazione Modalità di deployment avanzata.
Se visualizzi 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 sono presenti modifiche di cui non è stato eseguito il commit, come descritto nella sezione Contrassegnare aggiunte, modifiche ed eliminazioni della pagina della documentazione Modifica e convalida di LookML.
Puoi visualizzare 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 impegnate al progetto, Looker visualizza un riepilogo di tutte le modifiche salvate e di cui non è stato eseguito il commit 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, potrebbe essere visualizzata una versione diversa dello stesso file, con revisioni identificate da--- a/e+++ b/. - I file eliminati vengono visualizzati come sostituzione di un file null (
+++ /dev/null). - I file aggiunti vengono visualizzati in sostituzione di 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, alla 101a riga del file, sono state rimosse 4 righe e ne sono state aggiunte 4. 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. - Il testo che è stato 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.
Esegui il commit delle modifiche
Dopo aver apportato e salvato eventuali modifiche al progetto LookML, l'IDE potrebbe richiedere la convalida del tuo progetto LookML. In questo scenario, il pulsante Git mostra il testo Convalida LookML.
La necessità di questo requisito dipende dall'impostazione della qualità del codice nel progetto. Per saperne di più sullo strumento di convalida dei contenuti, consulta la pagina della documentazione relativa alla convalida di LookML.
Se un altro sviluppatore ha apportato modifiche al ramo di produzione dall'ultimo aggiornamento del ramo locale, Looker richiede di eseguire il pull di questi aggiornamenti dal ramo di produzione. In questo scenario, il pulsante Git mostra il testo Pull da produzione.
Se il progetto è abilitato per la modalità di deployment avanzata, il pulsante Git mostra il testo Pull dal ramo principale.
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 il commit delle modifiche e il push.
Se vuoi, puoi esaminare le modifiche di cui non hai eseguito il commit prima di accettarle.
Quando è tutto pronto per eseguire il commit delle modifiche, utilizza il pulsante Git per eseguire il commit di queste modifiche nel ramo attuale. Looker visualizza la finestra di dialogo Commit, in cui sono elencati 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 Esegui il commit per eseguire il commit delle modifiche.
Controllo delle PDT non create
Se hai apportato modifiche a qualsiasi PDT nel tuo progetto, è consigliabile 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 verificare lo stato delle PDT nel progetto, seleziona l'icona Integrità del progetto per aprire il riquadro 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 di test sui dati
Il progetto può includere uno o più parametri test che definiscono i test dei dati per verificare la logica del tuo modello LookML. Consulta la pagina della documentazione relativa al parametro test per informazioni su come configurare i test dei dati nel tuo progetto.
Se il progetto contiene test sui dati e sei in modalità di sviluppo, puoi avviare i test sui dati del progetto 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 in modo che eseguano 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 Integrità del progetto. Looker eseguirà tutti i test sui dati nel tuo 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 sui dati, nel riquadro Stato del progetto verranno visualizzati l'avanzamento e i risultati.
- Un test dei dati ha esito positivo quando l'asserzione del test è vera per ogni riga nella query del test. Per informazioni dettagliate sulla configurazione di asserzioni e query di test, consulta la pagina della documentazione relativa al parametro
test. - Se un test dei dati ha esito negativo, il riquadro Stato del progetto fornirà informazioni sul motivo per cui il test non è riuscito, se il test ha rilevato errori nella logica del modello o se il test non è valido.
- Dai risultati del test sui dati, puoi selezionare il nome di un test dei dati per andare direttamente a LookML per il test dei dati oppure il pulsante Esplora query per aprire un'esplorazione con la query definita nel test dei dati.
Esegui il deployment in produzione
Dopo aver 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 dipenderà dalla configurazione del progetto:
- Se il progetto è configurato per la modalità di deployment avanzata, l'IDE ti chiederà di unire le modifiche nel ramo principale. Dopo aver unito il commit, uno sviluppatore Looker con l'autorizzazione
deploypuò eseguire il deployment del commit in produzione utilizzando il gestore di deployment dell'IDE Looker oppure un webhook o un endpoint API. - Se il 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.
- Altrimenti, con l'integrazione predefinita di Git di Looker, se hai l'autorizzazione
deploy, l'IDE di Looker ti chiederà di unire le modifiche al ramo di produzione e di eseguire il deployment delle modifiche alla versione di produzione dell'istanza di Looker.
Modalità di deployment avanzata
Con l'integrazione predefinita di Looker Git, gli sviluppatori di Looker eseguono il commit delle modifiche nel ramo di sviluppo, quindi uniscono il ramo di sviluppo a quello della produzione. Quindi, quando esegui il deployment nell'ambiente Looker, Looker utilizza il commit più recente nel ramo di produzione. Consulta la sezione Introduzione delle modifiche alla produzione in questa pagina per conoscere il flusso di lavoro Git predefinito e altre opzioni per le implementazioni Git avanzate.
Per i casi in cui non vuoi che utilizzi sempre il commit più recente nel ramo di produzione per il tuo ambiente Looker, uno sviluppatore con autorizzazione deploy può utilizzare la modalità di deployment avanzata per specificare l'impegno esatto da utilizzare per l'ambiente Looker. Ciò è utile nei flussi di lavoro degli sviluppatori multi-ambiente, in cui ogni ambiente rimanda a una versione diversa di un codebase. Offre inoltre a uno o più sviluppatori o amministratori un maggiore controllo sulle modifiche di cui viene eseguito il deployment in produzione.
Quando è abilitata la modalità di deployment avanzata, l'IDE Looker non richiede agli sviluppatori di eseguire il deployment delle modifiche in produzione. Invece, l'IDE chiede agli sviluppatori di unire le modifiche al ramo di produzione. Da qui, è possibile eseguire il deployment delle modifiche solo nei seguenti modi:
- Utilizzo di deployment manager nell'IDE Looker
- Attivare un webhook
Utilizzo di un endpoint API
Per maggiori dettagli, consulta la pagina della documentazione Modalità di deployment avanzata.
Verificare l'impatto delle modifiche
Dopo aver reso disponibili le modifiche per l'organizzazione, puoi utilizzare la convalida dei contenuti per assicurarti di non aver invalidato alcuna dashboard o salvato i Look. Avrai la possibilità di correggerli, se necessario.
Gestione dei problemi tipici
Mentre lavori al modello, potresti dover:
Abbandona le modifiche
A volte potresti voler abbandonare le modifiche alla definizione del modello di dati. Se non sono ancora state salvate, puoi semplicemente aggiornare o uscire dalla pagina e accettare l'avviso. Se hai salvato le modifiche di cui non è stato eseguito il commit, come descritto nella sezione Annullare le modifiche di cui non è stato eseguito il commit.
Gestire i conflitti di unione con il lavoro di altri sviluppatori
Se più sviluppatori stanno lavorando sul tuo modello dei dati, in genere è Git a gestire la situazione. Tuttavia, a volte Git ha bisogno di un operatore per risolvere i conflitti di unione.
Alcune modifiche, ad esempio la modifica del nome di un campo, possono influire sulle 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 tuoi contenuti e risolvere eventuali problemi.
Annullamento delle modifiche di cui non è stato eseguito il commit
Quando lavori nel ramo di sviluppo personale, puoi annullare le modifiche di cui non è stato eseguito il commit 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 per 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 vengono annullate.
- Per ripristinare tutte le modifiche, incluse quelle di cui non è stato eseguito il commit, seleziona Ripristina in produzione
- Per completare la procedura 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 crei un nuovo file con un nuovo nome. Poiché le modifiche riguardano 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... 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. Un conflitto di unione si verifica quando Git rileva modifiche in conflitto e non può identificare le modifiche da conservare, in genere quando un altro sviluppatore ha apportato modifiche dall'ultima volta che hai eseguito il pull e hai apportato modifiche nella stessa area. In caso di conflitto di unione nel codice, Looker mostra un avviso Conflitti di unione dopo che hai eseguito il commit delle modifiche ed 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. 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 come segue:
<<<<<<< HEAD
Your code
=======
Production code
>>>>>>> branch 'master'
Looker mostra i seguenti indicatori di unione per indicare i conflitti di unione:
- <<<<<<<
HEADindica l'inizio delle righe in conflitto. - >>>>>>>
branch 'master'segna la fine delle righe in conflitto. - ======= separa ogni versione del codice per consentirti di confrontarle.
Nell'esempio precedente, your code rappresenta le modifiche di cui hai eseguito il commit e 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 cercare nel progetto gli indicatori di unione, come <<<< o
HEAD, per trovare tutti i conflitti nel 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 con conflitti di unione ed elimina la versione del testo che NON vuoi conservare, oltre a eliminare tutti gli indicatori 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 gli indicatori di unione dal tuo progetto, esegui il commit delle modifiche ed esegui il deployment in produzione.
Ora che hai risolto il conflitto di unione e hai trasferito la risoluzione in produzione, gli altri sviluppatori possono abbandonare la produzione e continuare a lavorare come al solito.
Garbage collection Git
La garbage collection Git pulisce i file superflui e comprime le revisioni dei file per ottimizzare il repository Git. La garbage collection Git (git gc) viene eseguita automaticamente quando la tua 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, potresti provare a eseguire il push delle modifiche a remoto o a eseguire il push del ramo a remoto mentre git gc è in esecuzione. Se Looker visualizza un errore, attendi un minuto o due e riprova a eseguire il push delle modifiche.