web design umbria
rappresentazione grafica e simbolica di stazioni e commits!

Per quanto strano possa sembrare le linee metropolitane romane A e B, spiegano bene quello che succede con le tecniche flash forward e il 3way-forward di GIT quando si fa il merge. Graficamente la metro romana é una rappresentazione di una linea che ha al suo interno dei cerchi grafici che simboleggiano le stazioni mentre per GIT rispetto al branch principale chiamato MASTER questi cerchi rappresentano i COMMITS, ossia le istantanee scattate per copiare le nostre modifiche nella stage area. Ma torniamo a bomba come dicono alcuni fenomeni di Gotham e dintorni. Il merge è una parte molto importante di GIT perché rappresenta la sintesi di tutto un processo di monitoraggio che il COMMIT da solo non potrebbe sopperire solo scattando fotografie con la descrizione delle modifiche effettuate sulle copie.

il merge questo sconosciuto

Con il Merge il tecnico si eleva a vette spirituali che nemmeno Michelangelo sulla Sistina, vabbè questa la cambiamo in “con il merge é possibile semplificare le diramazioni secondarie in termini di visualizzazione e di praticità di gestione del software, riportando tutto sul ramo principale o master”, che a quel punto dopo il merge avrà una curiosa caratteristica: si chiamerà in due modi diversi! Ok adesso proviamo a immaginare la linea B romana con tutta la folla che la ghernisce ogni giorno (questo almeno in tempi preistorici) e immaginiamo che parallelamente il collega che sta lavorando al LOGIN decida di correre con il suo flusso di sviluppo sul binario C. Traslato nella rappresentazione grafica di GIT significa che mentre io lavoro sul branch master principale, il collega sta sviluppando altri commits su una linea divergente parallela. A questo punto se volessi far correre tutti gli snapshot su un unica retta lineare come faccio? Ci sono due tecniche, tutte a due gestite con riconoscimento automatico da GIT:

il flash forward
il 3way forward

la prima si applica quando la linea divergente si sviluppa mentre l’ultimo nodo della linea master è fermo, ossia con commits che non vengono sviluppate in parallelo sulla linea principale. A quel punto il merge fonde tutto in unica azione lineare di circoletti o stazioni della metro che rappresentano una semplificazione dell’ intero software, SENZA RISCHI! Ma se lo sviluppatore della linea master continua a sviluppare quando inizia la linea divergente secondaria? Niente paura interviene il 3way forward ossia un meccanismo che prende le unicità di ciascun binario e li assembla per riunire tutti i commits in qualcosa di coerente e di organico. Ok ma quale è il rischio di questo meccamismo se il MERGE si fa molto di rado?

E’ che possono esserci sovrapposizioni di contenuti così potrebbe accadere che magari un documento testo viene modificato sulla linea master e sotto sulla linea secondaria si verifica invece un conflitto in quanto lo sviluppatore facendo il merge dello stesso file che era stato modificato a sua insaputa non riesce a ottimizzare il 3way forward. Fortunatamente ci viene in soccorso il software che sa riconoscere il pericolo di una perdita di dati e piuttosto blocca tutto annunciando una anomalia in un segmento specifico che solo l’umano deve risolvere! Bellissimo questo GIT!

errori sempre possibili quando si lavora contemporaneamente su due binari paralleli

A questo punto tra linee divergente e linee B romane vediamo nella pratica come gestire da CLI questi comandi che sembrerebbero complicati ma che invece non lo sono (è più facile da fare che da spiegare questo merge!).

Per quanto riguarda come al solito SOURCETREE c’è ben poco da dire visto che le rappresentazioni grafiche proposte dal software sono chiare e di facile gestione, nel senso che fa tutto il software lasciando un semplice segno di spunta sull’ opzione 3w, per cui in automatico il cliente che si appoggia al corebase di git vede tutto e tutto risolve: quando serve un semplice merge basato su un flash forward si fa il flash forward e quando ci sono più commits che corrono in parallelo allora subentra un inevitabile 3way forward. Info dettagliate soprattutto in rete: https://support.atlassian.com/bitbucket-cloud/docs/use-sourcetree-brances-to-merge-an-update/ . Ma come si fa a effettuare un merge da terminale? Conosciamo già un comando come:

git log

che ci fa vedere un commit sulla HEAD MASTER (significa, in cima al treno che corre sopra il binario principale) e:

git checkout -b "fast_forward_branch"

che darà un riscontro Switched to a new branch “fast_forward_branch” ossia grazie all’ opzione -b (b sta per branch) si crea con un solo comando una nuova diversione o sottolivello che corre parallelo al binario MASTER e ci si sposta sopra. A questo punto diciamo che abbiamo una serie di file committati dentro la linea B secondaria e il nostro problema è quello di riportare queste modifiche all’ interno della linea MASTER come si fa? Prima ci si sposta sulla linea A MASTER con:

git checkout

e dopo si digita il comando:

git merge fast_forward_branch

comparirà un riscontro di updating con il tipo di merge che é un FAST-FORWARD seguito da una serie di commit che prima erano della linea B che ora sono stati inclusi in unica HEAD MASTER che però al suo fianco dopo la virgola avrà anche la dicitura fast_forward_branch

checkout per spostarsi

Il 3way_branch è più complesso perchè contempla l’ipotesi che le due linee corrano parallele sullo sviluppo delle commits, mentre un fast forward semplice non produrrà mai conflitti in quanto comune catena lineare di stazioni metropolitane che sulla linea principale subiscono una interruzione mentre si evolve l’altra (commits ossia istantanee, cloni di file lavorati); qui se NON SI MERGIA spesso, in italiano se non si fa il merge in modo frequente, si rischia una sovrapposizione di lavorazioni con conflitti che poi vanno risolti a mano intervenendo sulle descrizioni per dire al software cosa deve o non deve lasciare tra i due. Il comando è sempre lo stesso, dopo essersi spostati sulla linea A MASTER e abbiamo seguito la procedura precedente per creare un livello inferiore parallelo con dentro degli snapshot, ci spostiamo sulla linea principale con il solito

git checkout

e si dà il comando:

git merge 3way_branch (che è il nome della linea B)

A questo punto rispetto a prima verrà generato un nuovo nodo (commit) che ha bisogno di una descrizione che dobbiamo inserire, questa nuova stazione viene aggiunta alla fine ed la sintesi tra tutto ciò che si trovava sulla MASTER + tutto ciò che si trova sulla linea B! Questo tipo di MERGE va fatto spesso quando si lavora in squadra perché così si evita il rischio di toccare lo stesso file in due rami diversi.

Conclusioni: la rappresentazione metaforica delle linee A e B della metro romana con le loro fermate spiegano molto bene quello che accade a livello software sui flussi di lavoro di git. Possiamo definire il merge come l’apoteosi del controllo di versione, ma ci attendono ancora molte gradevoli sorprese dopo aver generato dei cloni di file con il commit e averli portati in distilleria con il merge, come il FORK, il PULL e il PUSH e tanto altro!