Questa pagina presuppone che il progetto sia già stato configurato per il controllo 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 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 sei 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. Gli altri sviluppatori possono quindi passare a quel ramo per esaminarlo o apportare modifiche. Se un altro sviluppatore ha eseguito il commit delle modifiche al branch, Looker mostra il pulsante Esegui il pull delle modifiche remote. Devi eseguire il pull delle modifiche committate nel branch prima di apportare ulteriori modifiche.
Puoi anche eliminare un ramo diverso dal ramo principale, dal ramo corrente o dal ramo personale di uno sviluppatore.
Branch 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 e inviarle 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, avrai gli ultimi aggiornamenti di 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 minore o apportare una correzione 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 ci sono modifiche non committate nel ramo corrente, devi eseguire il commit delle modifiche nel ramo corrente 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 aver attivato la modalità di sviluppo.
Vai ai file del 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 raggruppamenti.
Seleziona Nuovo ramo.
Nella finestra Nuovo ramo, inserisci un nome per il ramo. 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 branch Git non devono:
- Contiene un carattere di spazio
- Contiene un doppio periodo:
.. - Contiene una barra rovesciata:
\ - Contiene la sequenza:
@{ - Contengono un punto interrogativo:
? - Contiene una parentesi quadra aperta:
[ - Contiene un carattere di controllo ASCII:
~o\^o: - Inizia con un periodo:
. - Inizia con il prefisso:
dev-(riservato per i branch 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 del ramo effettivo.
Passaggio a un altro ramo Git
Se si verifica un conflitto di unione nel ramo corrente, devi risolvere il conflitto prima di poter passare a un altro ramo.
Inoltre, se hai modifiche non committate nel branch corrente, non puoi passare a un branch esistente finché non committi le modifiche nel branch 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 del ramo non è sensibile alle maiuscole. Ad esempio, puoi cercare "DEV" e visualizzare tutti i rami con nomi che includono "dev", "DEV", "Dev" e così via.
Gestione dei branch 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. Quindi, seleziona la scheda Gestione sedi.
Nella scheda Gestione sedi, 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 reparti 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, 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 principale può sempre essere 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 branch 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 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 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 lo hanno sottoposto a checkout, questi sviluppatori avranno comunque la propria versione locale del ramo. Se uno sviluppatore di Looker esegue commit nella versione locale del ramo e lo esegue 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 progetto, vai prima alle impostazioni del progetto selezionando l'icona Impostazioni dal menu delle icone a sinistra. Quindi, seleziona la scheda Gestione sedi. Nella scheda Gestione sedi, puoi eliminare i reparti in due modi:
- Per eliminare più rami, seleziona 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 ha 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 del punto in cui ti trovi nel processo di apportare modifiche e di eseguire il 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.
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 dal punto in cui ti trovi nel processo di apportare modifiche e di eseguire il 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)
- Unisci il ramo di sviluppo al ramo di produzione, che per impostazione predefinita si chiama
master - Eseguire il 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 proprie modifiche in un ramo denominato master e l'ultimo commit sul ramo master è quello utilizzato per l'ambiente di produzione di Looker.
Per le implementazioni avanzate di Git, puoi personalizzare questo flusso di lavoro:
- Invece di consentire agli sviluppatori di unire le modifiche tramite l'IDE di Looker, puoi chiedere loro di inviare pull request per il ramo di produzione Git. Per maggiori dettagli, consulta la pagina della documentazione Configurare le impostazioni di controllo della versione del progetto.
- Puoi utilizzare il campo Nome del ramo di produzione Git per specificare quale ramo del tuo repository Git deve essere utilizzato da Looker come ramo di destinazione in cui vengono uniti i rami degli sviluppatori di Looker. 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 invece del pulsante Configura Git vedi le opzioni descritte in questa sezione, devi prima configurare Git per il tuo progetto.
Visualizzazione delle modifiche non committate
L'IDE LookML ha diversi indicatori che vengono visualizzati quando sei in modalità di sviluppo e hai modifiche non committate, come descritto nella sezione Marcare 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 non committate dal riquadro Azioni Git.
Nella finestra Modifiche non committate al progetto, Looker mostra un riepilogo di tutte le modifiche non committate e salvate 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 sostituti 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,4indica che, nella riga 101 del file, sono state rimosse 4 righe e aggiunte 4 righe. Un file eliminato con 20 righe mostrerà-1,20 +0,0per indicare che, nella prima riga del file, 20 righe sono state rimosse e sostituite da zero righe. - Il testo 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 le modifiche al progetto LookML, l'IDE potrebbe chiederti di convalidare il codice LookML. In questo caso, il pulsante Git mostra il testo Convalida LookML.
La necessità di questa operazione dipende dall'impostazione della qualità del codice del progetto. Per ulteriori informazioni su Content Validator, consulta la pagina della documentazione Convalida del 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 caso, il pulsante Git mostra il testo Esegui pull dalla produzione.
Se per il progetto è attiva la modalità di deployment avanzata, il pulsante Git mostra il testo Esegui il pull dal ramo principale.
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 prima esaminare le modifiche non committate prima di eseguire il commit.
Quando è tutto pronto per eseguire il commit delle modifiche, utilizza il pulsante Git per eseguire il commit delle modifiche nel branch 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 progetto, è ottimale che tutte le PDT vengano create durante il 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 Integrità del progetto per aprire il pannello Integrità del progetto, quindi seleziona il pulsante Convalida stato PDT.
Per ulteriori informazioni su come verificare la presenza di PDT non compilate nel progetto LookML e sull'utilizzo delle tabelle derivate in modalità di sviluppo, consulta la pagina della documentazione dedicata alle tabelle derivate in Looker.
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 modello LookML. Per informazioni sulla configurazione dei test dei dati nel progetto, consulta la pagina della documentazione del parametro test.
Se il tuo progetto contiene test dei dati e sei in modalità di 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 aver effettuato il commit delle 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 li definisce.
- 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, il riquadro Integrità 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 dei dati non va a buon fine, il riquadro Stato del progetto fornisce informazioni sul motivo del mancato superamento del test, se il test 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 passare direttamente al codice LookML del test oppure puoi selezionare il pulsante Query esplorazione 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 richiesta che vedrai 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 branch 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 progetto è configurato per l'integrazione di 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 di Git di Looker predefinita, 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 di Git avanzate.
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. Inoltre, offre a uno o più sviluppatori o amministratori un maggiore controllo sulle modifiche implementate 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 chiede invece agli sviluppatori di unire le modifiche nel branch 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 maggiori dettagli, consulta la pagina della documentazione relativa alla modalità di deployment avanzata.
Controllare 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 dashboard o look salvati. Avrai la possibilità di correggerli, se presenti.
Gestione di problemi tipici
Mentre lavori al modello, potresti dover:
Ignorare le modifiche
A volte potresti voler abbandonare le modifiche alla definizione del modello di dati. Se non sono ancora stati salvati, puoi semplicemente aggiornare la pagina o uscirne e accettare la richiesta 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 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, 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 per l'organizzazione, puoi utilizzare la convalida dei contenuti per controllare i contenuti e risolvere eventuali problemi.
Ripristino delle modifiche di cui non è stato eseguito il commit
Quando lavori sul tuo branch di sviluppo personale, puoi annullare le modifiche non committate che hai salvato se non vuoi eseguirne il deployment. Puoi ripristinare tutte le modifiche non committate 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 ripristinare tutte le modifiche, incluse 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 annullare eventuali aggiunte o eliminazioni nei contenuti di un singolo file, seleziona l'opzione Ripristina modifiche dal menu del file:
Quando rinomini un file, essenzialmente elimini il file originale e ne crei uno nuovo con un nuovo nome. Poiché sono coinvolti più 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 a… nel riquadro Azioni Git.
Risolvere i 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 riesce a 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:
- <<<<<<<
HEADindica 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 che hai eseguito il commit 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 gli indicatori di unione, come <<<< o
HEAD, per trovare tutti i conflitti nel progetto. Puoi anche trovare i file interessati selezionando il link files 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 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 hai eseguito il push della risoluzione in produzione, gli altri sviluppatori possono eseguire il pull dalla produzione e continuare a lavorare come al solito.
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 raccolta dei rifiuti di 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 ed 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 mostra un errore, attendi un paio di minuti e riprova a inviare le modifiche.