Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

225 febbraio
, anno 2017

Git, the stupid content tracker

IV parte: La struttura di un commit

Avatar

Ferdinando Santacroce

Ferdinando Santacroce lavora come programmatore presso Intré.
Cominciò tutto quando, all’età di 13 anni, ricevette in regalo il suo primo computer, un Commodore64. Capì che la cosa era seria quando invece che giocare come tutti i suoi amici ai soliti giochini comprati in edicola, si divertiva a scrivere piccoli programmi che facevano emettere suoni allo speaker.
Dopo il diploma, diventa insegnante tecnico pratico, ruolo grazie al quale impara molto. Per anni svolge un doppio incarico, in veste di insegnante e di web master — ai tempi, i full-stack developer si chiamavano così — togliendosi anche qualche piccola soddisfazione.
Da una dozzina d’anni si occupa esclusivamente di sviluppo software; ha lavorato per anni nel mercato farmaceutico italiano, passando poi all’e-commerce e giungendo infine ad occuparsi di industria.
Trascorre le sue giornate facendosi spazio tra dettagli e peculiarità delle ultime tecnologie e l'affascinante mondo delle discipline agili, per i quali nutre un profondo interesse.
Nel 2015 ha pubblicato un libro per Packt, “Git Essentials” (http://www.amazon.it/dp/B00WX1CWIC), ed è entrato a far parte dell'Italian Agile Movement, organizzazione senza scopo di lucro che ogni anno organizza gli Italian Agile Days (http://www.agileday.it/front/).

MokaByte

Git, the stupid content tracker

IV parte: La struttura di un commit

Ferdinando Santacroce

Ferdinando Santacroce

  • Questo articolo parla di: Frameworks & Tools, Programmazione & Linguaggi

Introduzione

Nella parte 3 di questa serie abbiamo fatto la conoscenza di alcune caratteristiche fondamentali di Git, tra cui le tre aree in cui i files vengono a trovarsi durante le operazioni che su di essi andiamo normalmente a effettuare.

In questa puntata andremo ancora più a fondo, analizzando nel dettaglio la struttura di un commit e degli elementi che lo compongono.

 

Configuriamo nome ed email

Prima di tornare a parlare di commit, è necessario fare una precisazione relativa a quanto scritto nel precedente articolo. Se i lettori hanno provato per la prima volta l’esecuzione di un commit all’interno di un repository Git, potrebbero essere incappati in un messaggio come questo:

[ 1 ] /c/temp/es01 (master)
$ git commit -m "File 01"
*** Please tell me who you are.
Run
git config --global user.email "you@example.com"
 git config --global user.name "Your Name"
to set your account's default identity.
 Omit --global to set the identity only in this repository.
fatal: unable to auto-detect email address (got 'nando@computer.(none)')

Git pretende che ogni commit sia “firmato” dalla persona che lo ha eseguito, e ne vuole conoscere anche un recapito email. Questa imposizione è stata voluta sin dall’inizio per far sì che, per ogni modifica apportata a un progetto, se ne potesse rintracciare l’autore, da contattare in caso di necessità.

Firmare il commit

Se non diciamo a Git chi siamo, esso cerca di desumerlo dalle configurazioni del sistema; tenta quindi di andare a leggere le informazioni dell’utente e la relativa email dal sistema operativo; nel caso non riuscisse a “capirlo”, presenta il messaggio che vediamo sopra, pretendendo che si proceda a opportuna configurazione di queste informazioni prima di continuare con il commit.

Senza lasciarci distrarre troppo, per il momento procediamo come suggerito; nelle prossime puntate approfondiremo meglio il sistema di configurazione di Git.

Procediamo quindi digitando questi due comandi:

[ 1 ] /c/temp/es01 (master)
 $ git config --global user.email "jesus_was_rasta@yahoo.it"
[ 2 ] /c/temp/es01 (master)
 $ git config --global user.name "Ferdinando Santacroce"

Git non darà alcun messaggio di risposta ma semplicemente andrà a settare nella sua configurazione globale queste informazioni: d’ora in poi, in ogni repository nel quale andrete a eseguire dei commit, questi saranno “intestati” a vostro nome.

E ora torniamo all’argomento principale di questa puntata.

 

I commit

Nelle scorse puntate abbiamo realizzato un semplice commit, senza però indugiare troppo sulla sua struttura. Ora invece è giunto il momento di osservare più da vicino questi “mattoncini” che danno forma al nostro repository.

Se avete ancora sotto mano il repository creato alla scorsa occasione bene, altrimenti vi rimando al precedente articolo per le istruzioni sulla sua creazione ex-novo.

Una volta dentro alla cartella del repository, proviamo a digitare git log, un nuovo comando che andiamo a conoscere:

[ 1 ] /c/temp/es01 (master)
$ git log
 commit 4004a1197c9078a8a39e92734e939631926360fc
 Author: Ferdinando Santacroce <jesus_was_rasta@yahoo.it>
 Date:   Sat Feb 4 09:48:21 2017 +0100
First commit, file01

Il comando git log consente di vedere la history del nostro repository; digitato senza alcuna altra opzione, restituisce la lista dei commit effettuati, in ordine cronologico inverso. Quello che vediamo, infatti, è il primo ed unico commit che abbiamo effettuato nella scorsa puntata, contenente un file di testo.

Una nota sulla configurazione del prompt

Piccola parentesi: come avrete notato, il prompt della console attualmente in uso è leggermente diverso da quello standard; ho eliminato informazioni che ritengo poco utili, ossia la parte che riporta utente@computer — so già chi sono… — e l’ambiente di utilizzo (MINGW64); al loro posto ho aggiunto un numerino tra parentesi quadre, che si incrementa ad ogni comando: questo mi permetterà di descrivere con maggiore facilità i passaggi che compiremo durante i nostri esperimenti.

Se volete personalizzare anche voi la vostra shell MinTTY [1], vi rimando a un mio articolo [2] che ne parla diffusamente.

 

L’hash

Passiamo ora ad analizzare ora un po’ le informazioni che ci vengono fornite. La prima riga riporta lo SHA-1 [3] del commit, una sequenza alfanumerica di ben 40 caratteri. Questo “codice”, o hash come si è soliti chiamarlo, identifica univocamente il commit all’interno del repository, ed è grazie ad esso che d’ora in poi si potrà far riferimento nel compiere determinate azioni che fra poco andremo a testare.

Giusto per fare una prova, facciamo un secondo commit sul nostro repository e poi andiamo a rieseguire git log, per verificare quanto detto in precedenza; creiamo quindi un file02.txt e modifichiamolo a piacere:

[ 2 ] /c/temp/es01 (master)
 $ vim file02.txt

Subito dopo, procediamo all’aggiunta del file alla staging area, effettuando poi il suo successivo commit:

[ 3 ] /c/temp/es01 (master)
 $ git add file02.txt
[ 4 ] /c/temp/es01 (master)
 $ git commit -m "Add a 2nd file"
 [master 0763bf3] Add a 2nd file
 1 file changed, 1 insertion(+)
 create mode 100644 file02.txt

Ora riproviamo a digitare il comando git log:

[ 5 ] /c/temp/es01 (master)
 $ git log
 commit 0763bf3adfe5699ff890d535b69299e5db39b737
 Author: Ferdinando Santacroce <jesus_was_rasta@yahoo.it>
 Date:   Sat Feb 4 10:03:44 2017 +0100
Add a 2nd file
commit 4004a1197c9078a8a39e92734e939631926360fc
 Author: Ferdinando Santacroce <jesus_was_rasta@yahoo.it>
 Date:   Sat Feb 4 09:48:21 2017 +0100
First commit, file01

Adesso compaiono due commit, con due hash distinti, ordinati in ordine cronologico inverso.

Ora proviamo a usare git log chiedendo di mostrarci solo un particolare commit, il primo, indicando i primi caratteri dell’hash:

[ 6 ] /c/temp/es01 (master)
 $ git log 4004a11
 commit 4004a1197c9078a8a39e92734e939631926360fc
 Author: Ferdinando Santacroce <jesus_was_rasta@yahoo.it>
 Date:   Sat Feb 4 09:48:21 2017 +0100
First commit, file01

Con questo piccolo esperimento abbiamo imparato due cose nuove: che git log può essere chiamato specificando l’hash del commit che si vuole vedere, ma soprattutto che non è necessario scrivere sempre tutto l’hash, ma basta indicarne i primi caratteri. Il numero minimo di caratteri che è possibile digitare è in genere 4, ed è regolato da una particolare voce di configurazione, la core.abbrev [4]; come potrete immaginare però, con l’andare del tempo è possibile che 4 caratteri non siano più sufficienti a discriminare un determinato commit: il tutto dipende da quanto grosso è il repository in cui ci stiamo muovendo: più è grosso, e più elevato è il rischio di “collisioni” fra i primi caratteri di un hash.

Ulteriori considerazioni sullo hash

Ad ogni modo, si tenga presente questa considerazione: Il kernel Linux è ad oggi uno dei progetti più grossi gestiti tramite Git, con i suoi oltre seicentomila commit. Eppure, in quel repository, sono comunque sufficienti solo 12 caratteri per identificare univocamente un commit.

Il default di Git prevede l’utilizzo dei primi 7 caratteri: se tornate indietro e ci fate caso, quando eseguiamo un commit, Git stesso riporta fra parentesi quadre i primi 7 caratteri del commit creato. Comunque non preoccupatevi: se durante l’esecuzione di qualche comando impartito Git non riesce a identificare univocamente un commit con il set di caratteri che gli avete fornito, non mancherà di avvisarvi.

Se invece siete curiosi di sapere con esattezza qual è il numero minimo di caratteri necessario per identificare un commit — anzi un qualsiasi oggetto Git, come vedremo più avanti — potete provare questo comando:

[ 7 ] /c/temp/es01 (master)
 $ git rev-parse --short=3 4004a1197c9078a8a39e92734e939631926360fc
 4004

Il comando git rev-parse con l’opzione –short=<numero caratteri> è in grado di dirci, rispetto al numero minimo di caratteri desiderato, qual è la sequenza minima di caratteri da indicare per essere certi allo stato attuale del repository di identificare univocamente il commit in oggetto. In questo caso abbiamo provato a vedere se 3 caratteri sarebbero bastati, ma di tutto punto Git ci ha comunicato che la sequenza minima da indicare è formata dai primi 4 caratteri, 4004.

Ho divagato e introdotto questo comando per soddisfare una possibile curiosità del lettore; e a questo punto, ne approfitto per introdurre un’altra peculiarità di Git, ovvero la suddivisione fra comandi porcelain e comandi plumbing.

 

Comandi porcelain e plumbing

Git, come sappiamo, prevede una miriade di comandi, alcuni dei quali non sono praticamente mai usati dall’utente medio, come da esempio il succitato git rev-parse. Questi comandi prendono il nome di plumbing commands, mentre quelli che abbiamo già imparato a conoscere, tipo git add, git commit e via discorrendo sono annoverati fra i cosiddetti porcelain commands.

La metafora ha origine direttamente dalla fervida immaginazione di Linus Torvalds, papà di Git, e ha a che fare con gli idraulici. Essi, com’è noto, si occupano anche della manutenzione dei servizi igienici; prendiamo a riferimento “il trono”, la tazza dove espletiamo i nostri bisogni. Questo è formato da un manufatto in porcellana, in grado di consentirci una seduta confortevole, e da una serie di tubi e condutture (in inglese, plumbing) che permettono invece lo scarico di quanto prodotto fin giù nella rete fognaria.

Linus si è servito di questa aulica metafora per suddividere i comandi di Git in due famiglie, quelli di più alto livello, confortevoli a un utilizzatore interessato alle operazioni più comuni (porcelain), e quelli utilizzabili a discrezione dagli utenti più esperti per compiere operazioni di più basso livello (plumbing).

Possiamo dunque considerare i comandi porcelain come comandi “di interfaccia” verso l’utente, mentre quelli plumbing lavorano “a basso livello”. Questo significa anche che i comandi porcelain rimangono più “stabili” nel tempo — modalità d’uso e opzioni variano con più cautela ed in tempi dilatati —in quanto usati direttamente ma implementati anche in numerosi tool grafici, editor e così via; quelli plumbing, invece, di uso meno comune, evolvono con meno restrizioni.

Non esiste una suddivisione precisa fra queste due categorie di comandi, in quanto il confine è spesso piuttosto labile; ci serviremo comunque ancora di essi, per poter meglio osservare e capire il funzionamento interno di Git.

Ritorniamo ora direttamente sul tema della puntata, e riprendiamo l’analisi dei commit.

 

Anatomia di un commit

Riportiamo qui per comodità l’output del comando git log digitato all’inizio:

[ 1 ] /c/temp/es01 (master)
 $ git log
 commit 4004a1197c9078a8a39e92734e939631926360fc
 Author: Ferdinando Santacroce <jesus_was_rasta@yahoo.it>
 Date:   Sat Feb 4 09:48:21 2017 +0100
First commit, file01

Oltre al già citato hash, osserviamo le altre informazioni presenti. Troviamo innanzitutto le informazioni riguardanti l’autore del commit, e successivamente la data e l’ora in cui esso risulta essere stato effettuato; per ultimo invece viene riportato il messaggio di commit, così come l’abbiamo inserito.

Le informazioni sull’autore servono per rendere rintracciabile la persona che ha eseguito le modifiche all’interno del commit; tenuto conto che Git e i sistemi di versionamento nascono anche per permettere alle persone di collaborare, la presenza di un riferimento esplicito non è certo cosa sgradita, anzi.

Ma come viene salvato un commit? E soprattutto, dove? È giunto il momento di “aprire il cofano” e mettere il naso dentro al “motore” di Git.

 

La .git folder

Quando creiamo un nuovo repository Git con il comando git init, avviene praticamente la creazione di una dotfolder di nome .git all’interno della cartella nella quale digitiamo il comando. Proviamo a vedere cosa c’è dentro: digitiamo il comando ll (alias del comando ls -l) nella nostra shell:

[ 2 ] /c/temp/es01 (master)
 $ ll .git/
 total 21
 drwxr-xr-x 1 san 1049089   0 Feb 4 10:03 ./
 drwxr-xr-x 1 san 1049089   0 Feb 4 10:03 ../
 -rw-r--r-- 1 san 1049089 15 Feb 4 10:03 COMMIT_EDITMSG
 -rw-r--r-- 1 san 1049089 201 Feb 4 09:48 config
 -rw-r--r-- 1 san 1049089 73 Feb 4 09:44 description
 -rw-r--r-- 1 san 1049089 23 Feb 4 09:44 HEAD
 drwxr-xr-x 1 san 1049089   0 Feb 4 09:44 hooks/
 -rw-r--r-- 1 san 1049089 225 Feb 4 10:03 index
 drwxr-xr-x 1 san 1049089   0 Feb 4 09:44 info/
 drwxr-xr-x 1 san 1049089   0 Feb 4 09:48 logs/
 drwxr-xr-x 1 san 1049089   0 Feb 4 10:03 objects/ #cartella objects
 drwxr-xr-x 1 san 1049089   0 Feb 4 09:44 refs/

Concentriamoci per un attimo sulla cartella objects, e ignoriamo il resto; entriamo a vedere cosa contiene:

[ 3 ] /c/temp/es01 (master)
 $ ll .git/objects/
 total 8
 drwxr-xr-x 1 san 1049089 0 Feb 4 10:03 ./
 drwxr-xr-x 1 san 1049089 0 Feb 4 10:03 ../
 drwxr-xr-x 1 san 1049089 0 Feb 4 10:03 07/
 drwxr-xr-x 1 san 1049089 0 Feb 4 10:03 30/
 drwxr-xr-x 1 san 1049089 0 Feb 4 09:48 40/ #cartella 40
 drwxr-xr-x 1 san 1049089 0 Feb 4 09:48 4b/
 drwxr-xr-x 1 san 1049089 0 Feb 4 09:45 a9/
 drwxr-xr-x 1 san 1049089 0 Feb 4 09:48 c2/
 drwxr-xr-x 1 san 1049089 0 Feb 4 09:45 f5/
 drwxr-xr-x 1 san 1049089 0 Feb 4 09:44 info/
 drwxr-xr-x 1 san 1049089 0 Feb 4 09:44 pack/

Noterete che è presente una cartella chiamata “40”; vediamo dentro cosa c’è:

[ 4 ] /c/temp/es01 (master)
 $ ll .git/objects/40
 total 5
 drwxr-xr-x 1 san 1049089   0 Feb 4 09:48 ./
 drwxr-xr-x 1 san 1049089   0 Feb 4 10:03 ../
 -r--r--r-- 1 san 1049089 145 Feb 4 09:48 04a1197c9078a8a39e92734e939631926360fc

Mmm… C’è un file senza estensione che si chiama

04a1197c9078a8a39e92734e939631926360fc

Se però faccio:

40 + 04a1197c9078a8a39e92734e939631926360fc

ottengo

4004a1197c9078a8a39e92734e939631926360fc

ossia l’hash del primo commit che abbiamo effettuato!

Semplici cartelle organizzate

Sospetto abbiate già capito: Git salva i commit come file in semplici cartelle, organizzando queste ultime in una struttura di sotto-cartelle per renderne più rapido l’accesso dal file system.

Se proviamo ad aprire quel file con un editor, il risultato sarà un fallimento: vedremo solo una sfilza di caratteri inintelligibili. C’è però un comando plumbing che ci può dare una mano, git cat-file; proviamo a digitarlo seguito dai primi 7 caratteri dell’hash del commit, utilizzando l’opzione -p come indicato qui sotto:

[ 7 ] /c/temp/es01 (master)
 $ git cat-file -p 4004a11
 tree c24e325c8a82a3750bc7853552a08735ae5d494c
 author Ferdinando Santacroce <jesus_was_rasta@yahoo.it> 1486198101 +0100
 committer Ferdinando Santacroce <jesus_was_rasta@yahoo.it> 1486198101 +0100
First commit, file01

Questo comando consente di andare a sbirciare dentro gli objects di Git — di cui parleremo diffusamente nella prossima puntata — e i commit rientrano a far parte di questi objects. Con l’opzione -p abbiamo chiesto di mostrare in una forma più facile da leggere quale fosse il contenuto il del suddetto object, e Git di tutto punto ci ha mostrato quanto vedete sopra.

Il contenuto del commit

È facilmente comprensibile la riga che indica l’author, che infatti riporta le informazioni indicate e già discusse in precedenza; il committer, che in questo caso coincide con l’author, rappresenta invece il soggetto che ha eseguito il commit. Ora vi starete chiedendo: ma perché due nomi diversi? Non sono sempre la stessa persona? In effetti il 99% delle volte lo sono, ma è possibile che in alcuni casi in fase di commit si voglia indicare un author diverso per qualche motivo, per esempio se stiamo per committare le modifiche passateci “offline” da qualcun altro, utilizzando l’apposita opzione –author=<author>. In casi come questi, il commit avrebbe un autore diverso dal committer, che invece non è possibile alterare.

In ultimo, troviamo una riga che dice:

tree c24e325c8a82a3750bc7853552a08735ae5d494c

Cosa vuol dire? Il tree è un altro degli objects gestiti da Git, e rappresenta un contenitore di file: immaginiamolo come se fosse una cartella.

Il contenuto del tree

Utilizzando la stessa procedura di prima, possiamo verificare che nella cartella /objects di Git esiste una sottocartella denominata c2, e al suo interno contiene un file

4e325c8a82a3750bc7853552a08735ae5d494c

Proviamo a vedere cosa contiene questo ulteriore object di Git usando sempre il comando git cat-file -p:

[ 8 ] /c/temp/es01 (master)
 $ git cat-file -p c24e325
 100644 blob 4bc92d99949138eb83452d857e5c504471e30805   file01.txt

Questo tree, che abbiamo detto essere un qualcosa che Git usa per identificare una cartella, contiene a suo volta un ulteriore object, denominato blob: a destra è indicato però “file01.txt”, il che ci fa intuire che i blob per Git rappresentano i file. Come prima, possiamo verificare che questo blob sia salvato in una sottocartella chiamata “4b”, e possiamo di nuovo andare a vederne il contenuto:

[ 9 ] /c/temp/es01 (master)
 $ git cat-file -p 4bc92d9
 File 01

Quel che appare sotto, “File 01”, è esattamente il testo contenuto del mio file .txt: con poca fantasia, quando l’ho creato ho scritto solo queste due parole al suo interno.

Per conferma, possiamo usare il comando cat, che in sistemi Unix consente di vedere il contenuto di un file:

[ 10 ] /c/temp/es01 (master)
 $ cat file01.txt
 File 01

Come vedete, il risultato è lo stesso.

 

Conclusioni

Abbiamo ancora tanto da dire per concludere questo discorso, ma lo spazio a nostra disposizione termina qui.

Nella prossima puntata vedremo in dettaglio quanto anticipato in questa ultima parte dell’articolo, ossia il sistema con cui Git organizza e salva le informazioni al suo interno (objects store). Una volta capito il modo in cui Git conserva i nostri dati, i comandi che andremo a utilizzare risulteranno un po’ meno astrusi di quanto non lo sarebbero altrimenti.

 

Facebook
Twitter
LinkedIn
Avatar

Ferdinando Santacroce

Ferdinando Santacroce lavora come programmatore presso Intré.
Cominciò tutto quando, all’età di 13 anni, ricevette in regalo il suo primo computer, un Commodore64. Capì che la cosa era seria quando invece che giocare come tutti i suoi amici ai soliti giochini comprati in edicola, si divertiva a scrivere piccoli programmi che facevano emettere suoni allo speaker.
Dopo il diploma, diventa insegnante tecnico pratico, ruolo grazie al quale impara molto. Per anni svolge un doppio incarico, in veste di insegnante e di web master — ai tempi, i full-stack developer si chiamavano così — togliendosi anche qualche piccola soddisfazione.
Da una dozzina d’anni si occupa esclusivamente di sviluppo software; ha lavorato per anni nel mercato farmaceutico italiano, passando poi all’e-commerce e giungendo infine ad occuparsi di industria.
Trascorre le sue giornate facendosi spazio tra dettagli e peculiarità delle ultime tecnologie e l'affascinante mondo delle discipline agili, per i quali nutre un profondo interesse.
Nel 2015 ha pubblicato un libro per Packt, “Git Essentials” (http://www.amazon.it/dp/B00WX1CWIC), ed è entrato a far parte dell'Italian Agile Movement, organizzazione senza scopo di lucro che ogni anno organizza gli Italian Agile Days (http://www.agileday.it/front/).

Ferdinando Santacroce

Ferdinando Santacroce

Ferdinando Santacroce lavora come programmatore presso Intré. Cominciò tutto quando, all’età di 13 anni, ricevette in regalo il suo primo computer, un Commodore64. Capì che la cosa era seria quando invece che giocare come tutti i suoi amici ai soliti giochini comprati in edicola, si divertiva a scrivere piccoli programmi che facevano emettere suoni allo speaker. Dopo il diploma, diventa insegnante tecnico pratico, ruolo grazie al quale impara molto. Per anni svolge un doppio incarico, in veste di insegnante e di web master — ai tempi, i full-stack developer si chiamavano così — togliendosi anche qualche piccola soddisfazione. Da una dozzina d’anni si occupa esclusivamente di sviluppo software; ha lavorato per anni nel mercato farmaceutico italiano, passando poi all’e-commerce e giungendo infine ad occuparsi di industria. Trascorre le sue giornate facendosi spazio tra dettagli e peculiarità delle ultime tecnologie e l'affascinante mondo delle discipline agili, per i quali nutre un profondo interesse. Nel 2015 ha pubblicato un libro per Packt, “Git Essentials” (http://www.amazon.it/dp/B00WX1CWIC), ed è entrato a far parte dell'Italian Agile Movement, organizzazione senza scopo di lucro che ogni anno organizza gli Italian Agile Days (http://www.agileday.it/front/).
Tutti gli articoli
Nello stesso numero
Loading...

Uno sguardo ai microservizi

III parte: Suddividere il monolite

Appunti di System Thinking

I parte: Quali errori impediscono alle organizzazioni di apprendere?

Accidenti! Non è command & control!

Stili di leadership in un contesto agile

Nella stessa serie
Loading...

Git, the stupid content tracker

XI parte: Il “viaggio” dei file e delle loro modifiche

Git, the stupid content tracker

X parte: Gestire i file, in pratica

Git, the stupid content tracker

IX parte: Un’occhiata ai tag

Git, the stupid content tracker

VIII parte: References

Git, the stupid content tracker

VII parte: Dalle foglie alla radice

Git, the stupid content tracker

VI parte: I commit

Git, the stupid content tracker

V parte: blob e tree

Git, the stupid content tracker

III parte: Concetti fondamentali per l’uso di Git

Git, the stupid content tracker

II parte: Installare Git e creare un repository

Git, the stupid content tracker

I parte: Conosciamo la storia di Git

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte