Utilizzo del controllo della versione e del deployment

Questa pagina presuppone che il progetto sia già stato configurato per il controllo della versione. Se vedi il pulsante Configura Git invece delle scelte descritte in questa pagina, devi prima configurare Git per il tuo progetto.

Integrazione Git per il controllo delle versioni

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. I repository Git sono spesso chiamati repos.

In genere Looker utilizza GitHub per la gestione dei file sorgente di LookML. Tuttavia, Looker può essere configurato per essere compatibile anche con altri provider Git come GitLab, Bitbucket o qualsiasi server Git che può usare una chiave SSH per l'autenticazione.

GitHub non accetta password di account per l'autenticazione delle operazioni Git su github.com. Consulta il post del blog di GitHub per ulteriori informazioni. Per connettere un progetto Looker a GitHub tramite HTTPS, utilizza le impostazioni sviluppatore in GitHub per creare un token di accesso personale. Per i progetti Looker esistenti che si connettono a GitHub tramite HTTPS, reimposta la connessione Git utilizzando un token di accesso personale da GitHub.

Un progetto Looker utilizza un solo account con il provider Git per tutte le interazioni Git (per informazioni sulla configurazione di Git), consulta la pagina della documentazione relativa all'integrazione di Looker con Git. Per ogni progetto Looker, tutto lo sviluppo di tutti gli sviluppatori Looker avviene attraverso questo account Git. Questo significa che gli sviluppatori di Looker non devono avere i propri account con il tuo provider Git, a meno che la tua istanza di Looker non configuri una delle opzioni di integrazione Git aggiuntive. In questo caso, uno sviluppatore Looker deve avere un account Git per aprire i link esterni al provider Git o creare una richiesta di pull.

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 ed eseguire test 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 importante caratteristica di Git è la facilità di collaborazione con altri sviluppatori che fornisce. Puoi creare un ramo e, se vuoi, apportare modifiche, mentre altri sviluppatori possono passare a quel ramo per esaminarlo o modificarlo. Se un altro sviluppatore ha eseguito modifiche al ramo, Looker visualizza il pulsante Pull Remote Changes (Avvia modifiche remote). Devi rimuovere le modifiche impegnate nel ramo prima di apportare ulteriori modifiche.

Puoi anche eliminare un ramo diverso dal ramo master, dal ramo attuale o dal ramo personale di uno sviluppatore.

Rami personali

La prima volta che passi alla modalità di sviluppo, Looker crea automaticamente il ramo Git personale. La tua filiale personale inizia con dev- e include il tuo nome:

Il 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 creare un nuovo ramo in modo che altri possano passare a quel ramo e contribuire anche con le modifiche.

SUGGERIMENTO: non puoi apportare modifiche al ramo personale di un altro sviluppatore. Per lavorare al ramo personale di qualcun altro, crea un nuovo ramo a partire dal suo ramo.

Creazione di un nuovo ramo Git

Se stai lavorando a una soluzione semplice e non stai collaborando con altri sviluppatori, il tuo ramo personale è in genere un buon posto per lavorare. Puoi utilizzare il ramo personale per eseguire aggiornamenti rapidi, quindi eseguire il commit delle modifiche ed eseguirne il push in produzione.

Tuttavia, potresti anche creare nuovi rami Git oltre al ramo personale. Un nuovo ramo Git ha senso in queste situazioni:

  • Stai collaborando con altri sviluppatori. Poiché il ramo personale è di sola lettura per 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 altri, assicurati di eseguire il pull delle modifiche ogni volta che riprendi il lavoro. In questo modo, riceverai gli ultimi aggiornamenti da tutti gli sviluppatori prima di continuare il lavoro.
  • Stai lavorando a più insiemi di funzionalità contemporaneamente. Potresti essere nel corso di un progetto importante, ma vuoi risolvere un problema di minore entità o risolvere rapidamente il problema. In questo caso, puoi eseguire il commit delle modifiche nel ramo in cui ti trovi e quindi creare o passare a un altro ramo per lavorare su un set separato di funzionalità. Puoi apportare la correzione nel nuovo ramo e quindi eseguire il deployment delle modifiche al ramo in produzione, prima di riprendere il lavoro nel ramo originale.

Prima di creare un nuovo ramo:

  • In caso di conflitto di unione nel ramo attuale, devi risolvere il conflitto prima di poter creare un nuovo ramo.
  • Se sono presenti modifiche non confermate 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 il ramo di produzione), per prima cosa scarica la versione più recente del ramo di sviluppo passando al ramo di sviluppo, quindi esegui il pull delle modifiche remote per sincronizzare la versione locale del ramo.

Per creare un nuovo ramo Git:

  1. Verifica di aver attivato la modalità di sviluppo.

  2. Vai ai file di progetto nel menu Sviluppo.

  3. Fai clic sull'icona Git nel menu a sinistra per aprire il riquadro Azioni Git.

  4. Fai clic sul menu a discesa Visualizza rami.

  5. Seleziona New Branch (Nuovo ramo).

  6. Nella finestra Nuovo ramo, inserisci un nome per il ramo. Tieni presente che ci sono limitazioni per i nomi dei rami Git; per i requisiti di denominazione, vedi Regole per la denominazione di un ramo Git in questa pagina.

  7. Fai clic sul menu a discesa Crea da e seleziona un ramo esistente da utilizzare come punto di partenza per il tuo nuovo ramo.

  8. Fai clic su Crea per creare il ramo.

In alternativa, puoi creare rami Git dalla scheda Gestione rami della pagina Impostazioni progetto.

Regole per la denominazione di un ramo Git

Looker utilizza i requisiti di convenzione di denominazione dei rami specificati da Git.

I nomi dei rami Git non devono:

  • Contenere un carattere spazio
  • Contenere un doppio periodo: ..
  • Contiene una barra rovesciata: \
  • Contenere la sequenza: @{
  • Contiene un punto interrogativo: ?
  • Contengono una parentesi quadrata di apertura: [
  • Contengono un carattere di controllo ASCII: ~ o \^ o :
  • Inizia con un punto: .
  • Inizia con il prefisso: dev- (riservato per i 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 è presente un conflitto di unione nel ramo attuale, devi risolvere il conflitto prima di poter passare a un ramo diverso.

Inoltre, se il ramo attuale contiene modifiche non confermate, non puoi passare a un ramo esistente fino a quando non hai eseguito il commit delle modifiche nel ramo attuale.

Per passare a un altro ramo Git:

  1. Nel progetto, vai al riquadro Git Actions facendo clic sull'icona Git nel menu a sinistra dell'icona.
  2. Nel riquadro Git Actions, fai clic sul menu a discesa del ramo Git in base al nome del ramo Git corrente.
  3. 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 vedere tutti i rami con nomi che includono "dev", "DEV", "Dev" e così via.

Gestione dei rami Git

La scheda Branch Management (Gestione rami) della pagina Impostazioni progetto mostra una tabella di tutti i rami Git per il progetto Looker. Per aprire la scheda Gestione rami, vai alla pagina Impostazioni progetto facendo clic sull'icona Impostazioni nel menu icona a sinistra e selezionando la scheda Gestione rami.

Nella scheda Branch Management:

  1. Crea un nuovo ramo facendo clic sul pulsante Nuovo ramo. Per ulteriori informazioni, consulta la sezione Creazione di un nuovo ramo Git in questa pagina.
  2. Cerca i nomi delle filiali nella barra di ricerca.
  3. Aggiorna la tabella facendo clic sul pulsante Aggiorna.
  4. Ordina la tabella facendo clic sul nome di una colonna.

La tabella include le seguenti informazioni:

  • Nome: nome del ramo Git. Gli sviluppatori di Looker' 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, lo stato di 3 commits behind indica che la versione locale del ramo è indietro rispetto alla versione remota del ramo di tre commit. Poiché Looker utilizza sempre la versione remota del master, la scheda Branch Management non mostra lo stato della versione locale del ramo master. Il ramo master può sempre essere considerato aggiornato.
  • Last Update (Ultimo aggiornamento): periodo di tempo dall'impegno di uno sviluppatore Looker per il ramo.
  • Azioni: un pulsante per eliminare il ramo o il motivo per cui il ramo non è idoneo per l'eliminazione.

Eliminazione dei rami Git

Nella scheda Branch Management, puoi eliminare i rami con un pulsante Delete (Elimina). 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 che è stato eliminato. Quando elimini un ramo, Looker rimuove sia la versione locale del ramo che la versione remota del ramo.

Tuttavia, se il ramo è stato creato da un altro sviluppatore Looker o se altri sviluppatori hanno eseguito il check-out del ramo, questi continueranno ad avere la propria versione locale del ramo. Se uno sviluppatore di Looker esegue il commit della sua versione locale del ramo e lo esegue il push in produzione, vedrai di nuovo una versione remota del ramo. Questo 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 garantire che non possa essere ritrovato accidentalmente da qualcuno che lo spinge a remoto.

Per eliminare uno o più rami Git dal progetto, vai alla pagina Impostazioni progetto facendo clic sull'icona Impostazioni nel menu a sinistra e selezionando la scheda Gestione rami. Nella scheda Ramo Management, puoi eliminare i rami in due modi:

  1. Per eliminare più rami, seleziona le caselle di controllo dei rami e fai clic su Elimina rami selezionati.
  2. Elimina un singolo ramo facendo clic su Elimina accanto al nome del ramo.

Esecuzione di comandi Git in Looker

Looker ha un'interfaccia integrata che si integra con il tuo servizio Git. Nell'IDE LookML, vedrai un pulsante in alto a destra per Git:

Il pulsante Git mostra opzioni diverse a seconda del punto in cui ti trovi in fase di apportare modifiche ed eseguire il deployment in produzione. In generale, l'opzione visualizzata sul pulsante è la guida migliore per l'azione successiva.

Se il ramo sviluppatore è sincronizzato con il ramo production, verrà visualizzato il messaggio Up-to-date:

Una volta che il progetto è configurato per Git, l'IDE mostrerà il riquadro Azioni Git con comandi Git aggiuntivi:

I comandi disponibili nel riquadro Git Actions dipendono dalla fase del processo in cui devi apportare le modifiche ed eseguire il deployment in production.

Ricevere le modifiche in produzione

Con l'integrazione Git predefinita di Looker, gli sviluppatori vengono invitati a utilizzare il seguente flusso di lavoro Git:

Ciò significa che, con l'integrazione Git predefinita, tutti gli sviluppatori uniscono le modifiche in un ramo chiamato master e l'ultimo commit nel ramo master è quello 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 production di Git, invece di consentire agli sviluppatori di unire le modifiche tramite l'IDE di Looker. Per informazioni dettagliate, consulta la pagina della documentazione relativa alla configurazione delle impostazioni di controllo della versione del progetto.
  • Puoi utilizzare il campo Git Production Branch Name (Nome ramo di produzione Git) per specificare quale ramo del tuo repository Git deve essere utilizzato come ramo target in cui vengono uniti i rami degli sviluppatori Looker. Per informazioni dettagliate, consulta la pagina della documentazione relativa alla configurazione delle impostazioni di controllo della versione del progetto.
  • Puoi utilizzare la modalità di deployment avanzato per specificare un SHA o un nome tag diverso da implementare nell'ambiente di produzione di Looker, anziché utilizzare il commit più recente nel ramo production. Se vuoi eseguire il deployment di un commit da un ramo diverso, puoi utilizzare la modalità di deployment avanzato webhook o endpoint API. Per informazioni dettagliate, consulta la pagina della documentazione relativa alla modalità di deployment avanzata.

Se vedi il pulsante Configura Git invece delle opzioni descritte in questa sezione, devi prima configurare Git per il tuo progetto.

Visualizzazione delle modifiche non impegnate

L'IDE LookML presenta diversi indicatori che vengono visualizzati in modalità di sviluppo e sono soggetti a modifiche non confermate, come descritto nella sezione Contrassegnare aggiunte, modifiche ed eliminazioni della pagina della documentazione Modifica e convalida di LookML.

Puoi ottenere un riepilogo delle differenze per tutti i file utilizzando l'opzione Visualizza modifiche non applicate dal riquadro Azioni Git:

Nella finestra Modifiche non confermate al progetto puoi visualizzare un riepilogo di tutte le modifiche non salvate 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, possono essere visualizzate versioni diverse 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 sostituiti con un file null (--- /dev/null).
  • Il numero di riga in cui inizia la modifica.
    Ad esempio, -101,4 +101,4 indica che, alla 101a riga del file, sono state rimosse 4 righe e 4 sono state aggiunte. Un file eliminato con 20 righe mostrerà -1,20 +0,0 per indicare che, nella prima riga del file, sono state rimosse e sostituite da 20 righe.
  • Il testo aggiornato:
    • Le righe eliminate vengono visualizzate in rosso.
    • Le righe aggiunte vengono visualizzate in verde.

Puoi anche ottenere un riepilogo delle differenze per un singolo file selezionando l'opzione Visualizza modifiche dal menu del file:

Esegui il commit delle modifiche

Dopo aver apportato e salvato le modifiche al progetto LookML, l'IDE può richiedere la convalida del progetto LookML:

Questa operazione dipende dall'impostazione del progetto sulla qualità del codice. Per ulteriori informazioni sullo Strumento di convalida dei contenuti, consulta la pagina Convalida del codice LookML.

Se un altro sviluppatore ha apportato modifiche al ramo production dall'ultimo aggiornamento del ramo locale, Looker richiede di eseguire il pull di questi aggiornamenti dal ramo production.

Se il progetto è abilitato per la modalità di deployment avanzato, questo pulsante dirà Pull from Primary Branch (Estrai dal ramo principale).

Una volta salvate le modifiche (e corretto eventuali avvisi o errori LookML, se richiesto) ed eseguito il pull da produzione (se richiesto), il pulsante Git mostra il seguente messaggio:

Se vuoi, puoi esaminare le modifiche non impegnate prima di impegnarti.

Quando tutto è pronto per eseguire il commit delle modifiche, utilizza il pulsante Commit changes & per eseguire il commit di queste modifiche nel ramo attuale. Viene visualizzata la finestra seguente, in cui sono elencati i file aggiunti, modificati o eliminati.

Inserisci un messaggio che descrive brevemente le modifiche e deseleziona i file che non vuoi includere nella sincronizzazione. Quindi, fai clic su Commit per eseguire il commit delle modifiche.

Controllo delle PDT non create

Se hai apportato modifiche alle 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. Prima di eseguire il deployment delle modifiche, puoi verificare la presenza di PDT non create nel progetto nel riquadro Stato del progetto. Fai clic sull'icona Project Health, quindi fai clic sul pulsante Convalida stato PDT:

Consulta la pagina della documentazione sulle tabelle derivate in Looker per ulteriori informazioni 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 tuo progetto potrebbe includere test dei dati per verificare la logica del tuo modello LookML. Consulta la pagina della documentazione relativa al parametro test per informazioni sulla configurazione dei test dei dati nel tuo progetto.

Per eseguire test sui dati devi essere in modalità di sviluppo. Una volta in modalità Sviluppo, esistono diversi modi per avviare i test di dati per un progetto:

  1. Se le impostazioni del progetto sono configurate in modo da richiedere il test dei dati prima di eseguire il deployment dei file in produzione, l'IDE mostrerà il pulsante Esegui test dopo che hai commesso le modifiche al progetto. Verranno eseguiti tutti i test per il tuo progetto, indipendentemente dal file che li definisce. Devi superare i test dei dati prima di poter eseguire il deployment delle modifiche in produzione.
  2. Fai clic sul pulsante Esegui test dei dati nel riquadro Stato del progetto. Verranno eseguiti tutti i test di dati nel progetto, indipendentemente dal file che definisce il test.
  3. Seleziona l'opzione Esegui test LookML dal menu del file. Verranno eseguiti solo i test definiti nel file corrente.

Una volta eseguiti i test sui dati, il riquadro Stato del progetto mostrerà l'avanzamento e i risultati:

  • Un test di dati supera il momento in cui l'asserzione del test è vera per ogni riga nella query del test. Per dettagli sulla configurazione delle asserzioni e delle query di test, consulta la pagina della documentazione relativa al parametro test.
  • Se un test con dati non riesce, il riquadro Stato del progetto fornirà informazioni sul motivo dell'esito negativo del test, se il test ha rilevato errori nella logica del modello o se si tratta di un test non valido.
  • Dai risultati del test dati, puoi fare clic sul nome di un test dati per passare direttamente a LookML per il test dati oppure puoi fare clic sul pulsante Esplora query per aprire un'esplorazione con la query definita nel test dati.

Esegui il deployment in produzione

Una volta apportate modifiche al ramo, l'IDE di Looker ti chiederà di unirle al ramo principale. Il tipo di prompt che vedrai nell'IDE dipenderà dalla configurazione del tuo progetto:

  • Se il progetto è configurato per la modalità di deployment avanzato, l'IDE ti chiederà di unire le modifiche nel ramo principale. Dopo aver unito il commit, uno sviluppatore Looker con l'autorizzazione deploy può eseguire il deployment del commit nel canale di produzione utilizzando lo strumento Deployment Manager di IDE di Looker o utilizzando 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 usando l'interfaccia del provider Git.
  • In caso contrario, con l'integrazione Git predefinita di Looker, se hai l'autorizzazione deploy, l'IDE di Looker ti chiederà di unire le modifiche nel ramo production e di eseguire il deployment delle modifiche nella versione di produzione dell'istanza di Looker.

Modalità di deployment avanzato

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 al ramo production. Quindi, quando esegui il deployment nell'ambiente Looker, Looker utilizza il commit più recente nel ramo production. Per informazioni sul flusso di lavoro Git predefinito e su altre opzioni per le implementazioni Git avanzate, consulta la sezione Ricezione delle modifiche in produzione.

Nei casi in cui non vuoi che utilizzi sempre l'ultimo commit nel ramo production per il tuo ambiente Looker, uno sviluppatore con autorizzazione deploy può utilizzare la modalità di deployment avanzata per specificare l'esatto commit da utilizzare per il tuo ambiente Looker. Ciò è utile nei flussi di lavoro per sviluppatori multiambiente, in cui ogni ambiente punta a una versione diversa di un codebase. Fornisce inoltre a uno o più sviluppatori o amministratori un maggiore controllo sulle modifiche di cui viene eseguito il deployment in produzione.

Quando è attivata la modalità di deployment avanzato, l'IDE di Looker non richiede agli sviluppatori di eseguire il deployment delle modifiche in produzione. Invece, l'IDE richiede agli sviluppatori di unire le modifiche nel ramo production. In seguito, è possibile implementare le modifiche solo nei seguenti modi:

Per informazioni dettagliate, consulta la pagina della documentazione relativa alla modalità di deployment avanzata.

Verifica dell'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. Avrai la possibilità di correggerli, se possibile.

Gestire i problemi tipici

Durante il lavoro sul modello, potrebbe essere necessario:

  • Ignora le modifiche

    A volte potresti voler abbandonare le modifiche della modellazione dei dati. Se non sono ancora salvati, puoi semplicemente aggiornarli o uscire dalla pagina, quindi accettare la richiesta di avviso. Se hai salvato le modifiche, puoi annullare le modifiche non impegnate come descritto nella sezione Ripristino delle modifiche non impegnate.

  • Gestire i conflitti di unione con gli altri sviluppatori' lavoro

    Se più sviluppatori lavorano sul modello dei dati, generalmente la situazione è gestita da Git. Tuttavia, di tanto in tanto Git ha bisogno di un essere umano per risolvere i conflitti di unione.

Alcune modifiche, come la modifica del nome di un campo, possono interessare le dashboard e i look esistenti. Come accennato sopra, 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 non applicate

Quando lavori al tuo ramo di sviluppo personale, puoi annullare le modifiche non confermate che hai salvato se non vuoi eseguirne il deployment. Puoi annullare tutte le modifiche non confermate per tutti i file del progetto o solo le modifiche in un singolo file.

Per annullare le modifiche non impegnate per tutti i file:

  1. Fai clic sull'opzione Ripristina a... nel riquadro Azioni Git.
  2. Seleziona un'opzione di ripristino:
    • Per annullare solo le modifiche non impegnate, seleziona Annulla modifiche non impegnate. Puoi anche fare clic sul link Visualizza modifiche per visualizzare le modifiche che verranno annullate.
    • Per annullare tutte le modifiche, incluse quelle non impegnate e impegnate, seleziona Ripristina produzione.
  3. Per completare il ripristino, fai clic su 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é 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 a... nel riquadro Azioni Git.

Inoltre, se hai eliminato un file, questo non viene più visualizzato nel browser dei file IDE. Se vuoi annullare l'eliminazione di un file, utilizza l'opzione Ripristina a... del 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 non riesce a determinare quali modifiche conservare. In genere questo problema si verifica quando un altro sviluppatore ha apportato modifiche dall'ultimo pull e tu hai apportato modifiche nella stessa area. Se si verifica un conflitto di unione nel tuo codice, riceverai un avviso in Looker dopo il commit delle modifiche e il pull dalla produzione:

Quando Looker mostra l'avviso sul conflitto di unione, è consigliabile risolvere il conflitto di unione prima di apportare ulteriori modifiche. Il push di un conflitto di unione alla produzione comporterà errori di analisi che potrebbero impedire l'esplorazione dei dati. Se sei un utente Git avanzato e vuoi proseguire con il push delle modifiche, fai clic sul pulsante Non risolvere.

Nel file LookML stesso, le righe con conflitti sono contrassegnate in questo modo:

<<<<<<< HEAD
Your code
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
Production code
>>>>>>> branch 'master'

Looker mostra i seguenti indicatori di unione a indicare i conflitti di unione:

  • <<<<<<< HEAD segna l’inizio delle righe in conflitto.
  • >>>>>>> branch 'master' segna la fine delle righe in conflitto.
  • ======= separa ogni versione del codice in modo da poterli confrontare.

Nell'esempio precedente, your code rappresenta le modifiche che hai confermato e production code rappresenta il codice in cui Git non è stato in grado di unire automaticamente le modifiche.

Risoluzione di un conflitto di unione:

  1. Trova i file con conflitti di unione. Looker contrassegna questi file in rosso. In alternativa, puoi cercare nel progetto degli indicatori di unione, come <<<< o HEAD, per trovare tutti i conflitti nel tuo progetto. Puoi anche trovare i file interessati facendo clic sul link file nell'avviso di unione visualizzato nel riquadro Azioni Git.
  2. Nel file, vai alle righe con conflitti di unione ed elimina la versione del testo che NON vuoi conservare, quindi elimina tutti gli indicatori di conflitto di unione.

  3. Salva il file e ripeti i passaggi precedenti per qualsiasi altro file contrassegnato con conflitti di unione.

    SUGGERIMENTO: cerca nel progetto tutti gli indicatori di unione per verificare di aver risolto tutti i conflitti e di aver eliminato tutti gli indicatori di unione. Assicurati di rimuovere tutte le istanze di indicatori di unione nei file LookML. Questi indicatori comporteranno errori di analisi che possono impedire agli utenti di esplorare i dati.

  4. Dopo aver risolto tutti i conflitti di unione ed eliminato tutti gli indicatori di unione dal progetto, esegui il commit delle modifiche ed eseguine il deployment in produzione.

Ora che hai risolto il conflitto di join e raggiunto la risoluzione per il canale di produzione, gli altri sviluppatori possono proseguire con il processo di produzione e continuare come al solito.

Git garbage collection

Git garbage collection ripulisce i file non necessari e comprime le revisioni dei file per ottimizzare il tuo repository Git. La garbage collection (git gc) di Git 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 e poi esegue git gc al successivo riavvio.

In alcuni rari casi, puoi provare a eseguire il push delle modifiche al telecomando o al invio del ramo al telecomando mentre git gc è in esecuzione. Se Looker mostra un errore, attendi un minuto o due, quindi riprova ad applicare le modifiche.