Abbiamo visto un insieme di funzionalità base per quanto riguarda l’uso di GIT, il minimo indispensabile per sopravvivere. Prendi per esempio un REBASE che rispetto al MERGE lavora per costruire binari unici, il fatto che ci sia da approfondire quello che fa un REBASE RICORSIVO fa parte di un percorso di approfondimento ancora da fare. Il Rebase come il Merge include le modifiche di un ramo in un altro ramo ma la rappresentazione grafica per il merge rimane parallela mentre nel rebase tutti i commits ono unificati.

Con il rebase ricorsivo hai la possibilità di intervenire sui singoli commits secondari in modo da riunificarli in unico ramo. Per esempio ho dei refusi di testo da sistemare in vari commits e allora posso correggerli con un rebase ricorsivo che presenta varie opzioni sottoforma di lettera. Oppure per quanto riguarda ulteriori approfondimenti come non aggirare l’ostacolo dei comandi complessi mettendo in gioco gli ALIAS che possono con il dono della sintesi richiamare lunghe istruzioni di codice ma anche semplici comandi abbreviandoli. Per fare questa operazione necessità intervenire sul file di configurazione messo a disposizione da GIT denominato config. Si aggiunge alla sezione ALIAS tra parentesi quadre il comando desiderato seguito da uguale e dall’ istruzione da sostituire.

E come non approfondire ad esempio la questione dei conflitti tra file che contemporaneamente vengono toccati su rami paralleli? SourceTree per esempio mette a disposizione sui file segnalati in basso a sinistra dopo i merge un tasto destro dove possiamo decidere quale file tenere buono, se quello del branch principale Master o quello secondario. In ogni caso possiamo anche editare il testo e mettere ordine a mano visto che GIT sottolinea le anomali tra blocchi di codici delimitati che si possono rimuovere per lasciare una unica istruzione! Insomma l’universo GIT è molto complesso e non si limita solo ai vari fork, push, clone, add, status, log, merge, branch, commit ec etc. Certo è che abbiamo adesso integrato nel nostro CV uno strumento CHE SAPPIAMO GESTIRE A LIVELLO BASE AUTONOMAMENTE, grazie a un pò di smanettamento reale dove siamo andati a curiosare anche su GIT HUB per pushare e pullare! GIT è un TOOL INDISPENSABILE da conoscere quando si vuole crescere come sviluppatori, ma non è obbligatorio quando si lavora autonomamente su piccoli progetti che non hanno bisogno di un TEAM a sostegno per implementare in gruppo nuove funzionalità. Di nuovo i comandi non vanno imparati a memoria è più importante capire la logica e ciè i processi che ne stanno alla base: tu addizioni i file che vuoi fotografare nello stage area dopo aver creato un repository, li congeli con i commits e li rendi memorabili, dopodichè puoi anche fare lavorazioni parallele (comando branch) e fondere i rami con il comando merge, in modo da avere un unica storia generale delle modifiche effettuate sul progetto.

fwd

Ma lavorare in locale perderebbe di intensità senza portare tutto su un sito di servizi in rete come GItHub (ma ce ne sono anche altri) che ci consente di spingere i nostri file nel nostro repository o anche di forkare progetti condivisi per fare cloni e PULL. Insomma vedere gli ingranaggi e sapere che ci sono delle dinamiche base da conoscere è più importante che imparare un comando a memoria perché ci consente di trovare subito quello che necessità! Grazie GIT quindi per aver arricchito il nostro curriculum, ma per favore come aspiranti professionisti non andiamo in giro a dire che conosciamo GIT come tecnologia. Sappiamo però che la conoscenza dei controlli di versione oggi è fondamentale e la parola magica GIT deve comunque comparire sul CV, ben sapendo che abbiamo assimilato solo le basi per operare successivi approfondimenti!