Passa ai contenuti principali

Git concetti base

Git concetti base

Introduzione

Git è un sistema di versionamento inventato ed implementato inizialmente da Linus Torvalds (si proprio lui, l'inventore di Linux) come alternativa a SVN.

Architettura

Uno schema di massima di git che ci aiuterà a capire i passaggi descritti sotto è questo:


da: https://www.claudiobattaglino.it/2020/01/07/git-schema-di-funzionamento/

Uso base


Git lavora a livello di filesystem (Working Directory). I comandi che seguono vanno lanciati nella specifica directory che è destinata a contenere i file del progetto da versionare, la "Working Directory". Inoltre git può lavorare sia con un repository locale che anche uno "Remote".

Inizializzazione del repository

$ git init
Questo crea un file nascosto ".git" con la configurazione dello specifico repository.

Definizione degli utenti del repository

$ git config --local user.name "fchiri"
Se al posto di "local" ci mettete "global" la definizione varrà per tutti i repository.

$ git config --local user.email "fchiri@mail.com"


Comandi base

Con lo status otteniamo un report sulla situazione del nostro repository:
$ git status
Sul branch master

Non ci sono ancora commit

non c'è nulla di cui eseguire il commit (crea/copia dei file e usa "git add" per tracciarli)
Da notare il riferimento al branch principale e di default "master".

Aggiungo dei file alla directory e rilancio status:

Sul branch master

Non ci sono ancora commit

File non tracciati:
  (usa "git add <file>..." per includere l'elemento fra quelli di cui verrà eseguito il commit)
	index.html
	stile.css

non è stato aggiunto nulla al commit ma sono presenti file non tracciati (usa "git add" per tracciarli)
Da qui si vede che il repository git ha un branch che si chiama "master", nella directory ci sono due file (index.html e stile.css)  "non tracciati" cioè non sottoposti al controllo di git perchè vanno aggiunti.

Aggiunta dei file alla "Staging Area" del repository appena creato:

$ git add *
Rifacendo lo status:
$ git status
Sul branch master

Non ci sono ancora commit

Modifiche di cui verrà eseguito il commit:
  (usa "git rm --cached <file>..." per rimuovere gli elementi dall'area di staging)
	nuovo file:             index.html
	nuovo file:             stile.css

Lo status ora ci avvisa che ci sono due nuovi file che sono stati aggiungi alla "Staging Area" e ci propone di fare il "commit" per spostare i file aggiunti alla "Staging Area" al vero e proprio Repository (locale).
L'operazione contraria all'add è il "remove". Quindi se volessimo togliere un file dalla staging area dovremmo fare:

$ git rm --cached stile.css

Facciamo la "commit" per conservare nel repository locale con un commento

$ git commit -m "primo commit"
[master (commit radice) b526cc8] primo commit
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 index.html
 create mode 100644 stile.css
Le informazioni che riporta la risposta del commit ci dice che il commit è avvenuto sul branch master, riporta il messaggio "primo commit" che abbiamo inserito al commit, ci dice che sono stati committati due file.

Ora proviamo a modificare uno dei due file inserendo del testo nel file index.html e riproviamo a lanciare lo status:

$ git status
Sul branch master
Modifiche non nell'area di staging per il commit:
  (usa "git add <file>..." per aggiornare gli elementi di cui sarà eseguito il commit)
  (usa "git restore <file>..." per scartare le modifiche nella directory di lavoro)
	modificato:             index.html

nessuna modifica aggiunta al commit (usa "git add" e/o "git commit -a")
Otteniamo l'elenco dei file modificati ed il suggerimento di committarli. Non lo facciamo e proviamo un nuovo comando: checkout.

$ git checkout *
Aggiornato 1 percorso dall'indice
Ci informa che è stato aggiornato un "percorso". Se si prova a vedere il contenuto di "index.html" si noterà che esso è tornato ad essere come era quando lo abbiamo committato.
Modifichiamo nuovamente "index.html" ed eseguiamo prima uno status e poi un commit *:
$ git status
Sul branch master
Modifiche non nell'area di staging per il commit:
  (usa "git add <file>..." per aggiornare gli elementi di cui sarà eseguito il commit)
  (usa "git restore <file>..." per scartare le modifiche nella directory di lavoro)
	modificato:             index.html

nessuna modifica aggiunta al commit (usa "git add" e/o "git commit -a")

$ git commit *
[master 3bf9db2] rimodifica
 1 file changed, 6 insertions(+)
In questo caso lo status ci ha detto che il file "index.html" era stato modificato, abbiamo lanciato il commit e ci si è aperto l'editor di testo prestabilito. In questo inserendo il commento del commit e salvando si ottiene quello che abbiamo fatto direttamente con il parametro "-m" al commit.

Branches

Sta per "diramazioni" ed appunto è il nome che prendono le diramazioni dal branch principale, che è "master", solitamente usate per testare l'implementazione di funzionalità senza toccare la struttura principale ed evitare conflitti con gli altri sviluppatori del progetto.


Con il comando "branch" si ottiene l'elenco di quelli esistenti:
$ git branch
* master
Ci informa che ne esiste solo uno e ci indica che stiamo lavorando sull'unico branch esistente con l'*.
Ipotizziamo di dover lavorare ad una funzionalità relativa all'ordinamento di un risultato che inizialmente la nostra soluzione non aveva, creiamo un branch "ordinamento":
$ git branch ordinamento

$ git branch
* master
  ordinamento
Dopo averlo creato per visionare nuovamente i branch esistenti facciamo nuovamente "git branch", ora risulterà in elenco il nuovo branch ma l'asterisco indica che siamo ancora nel master. Per spostarci sull'altro facciamo:
$ git checkout ordinamento
Si è passati al branch 'ordinamento'
Il sistema ci informa che siamo passati con lo stato dell'arte al nuovo branch "ordinamento". Proviamo a modificare un file di quelli versionati, ad esempio index.html e facciamone l'add e il commit:

$ git add *
E committiamo:

$ git commit -m "secondo commit"
A questo punto se ci spostiamo nel branch master:

$ git checkout master
E si prova a visiona il file index.html si noterà che è quello che avevamo committato in master.


Confronti fra versioni

Ora tenendo ben presenti i concetti di staging area e di repository proviamo a vedere le differenze fra versioni diverse di file.
Lo scenario è questo: faccio delle modifiche al file index.html ma non lo committo:

$ git diff index.html
Mi evidenzia le differenze fra il file nella directory e quello nella staging area:

 git checkout master
E si prova a visiona il file index.html si noterà che è quello che avevamo committato in master.


Confronti fra versioni

Ora tenendo ben presenti i concetti di staging area e di repository proviamo a vedere le differenze fra versioni diverse di file.
Lo scenario è questo: faccio delle modifiche al file index.html ma non lo committo:

$ git diff index.html
diff --git a/index.html b/index.html
index 75cbba3..e61dd96 100644
--- a/index.html
+++ b/index.html
@@ -1,6 +1,6 @@
 <html>
 <head>
-<title>Titolo</title>
+<title>Titolo principale</title>
 </head>
 <body>
 test

Git mi mostra le differenze fra i due file, dove sono e quali sono.



Commenti

Post popolari in questo blog

Telecamere Ip con accesso "nascosto"

Telecamere Ip con accesso "nascosto" Storia triste di un auto-hacking obbligato che mi ha fatto scoprire come la nostra privacy è realmente messa a rischi. Storia Ho acquistato dal mercatino/fiera del Radioamatore di Fasano quattro telecamere IP. La scatola riporta "Smart Camera" LF4810. Ne ho montata una e testata in tutte le sue funzionalità per oltre un mese. Chiaramente la manualistica scarsissima, come da tradizione in questi prodotti cinesi di costo molto concorrenziale, consiste in un "pieghevole" di 4 facciate. Chiaramente non erano documentate le impostazioni necessarie per attivare i protocolli ONVIF e RTSP che mi sono indispensabili per l'uso che ne devo fare. Nonostante questa scarsa documentazione dopo l'installazione base fatta con l'apposita app: tutto sembrava corretto. Chiaramente la prima azione che ho compiuto è stata quella di cambiare la password che di default è "123". Subito dopo h

Alzatapparella con Shelly 2 e Alexa

Alzatapparella con Shelly 2 e Alexa Qui spiego tutti i passaggi per installare lo Shelly 2 per automatizzare una tapparella e come configurarlo in Alexa. Impianto attuale Collegamenti da effettuare: Schema teorico: Collegamenti reali: Impostazioni: Dopo aver collegato tutto si procede alla configurazione. Prima di tutto installare la App "Shelly" cercandola nel proprio store e create un account: Il dispositivo verrà visto come doppio interruttore. Andare sulla "i" "Impostazioni": Nella sezione "MODO" ed impostare "Roller Shutter" Poi su "APRI/CHIUDI TEMPO DI LAVORO" ed impostare tipo 20 secondi. Altro passaggio importante in caso di tapparelle è quello relativo alla calibrazione (schermata relativa a "Shelly 2.5"). Se si omette questo passaggio non sarà possibile vedere in che stato è (aperta/chiusa

UPS Monitor via USB

Collegamenti Ho collegato l'UPS Mustek PowerMust 800 mediante il cavo USB al server con Ubuntu Linux 18.04. Software Ho installato: $ sudo apt-get install nut nut-cgi Configurazione Ho impostato i permessi di accesso: $ sudo chown root:nut /etc/nut/* $ sudo chown 640 /etc/nut/* Ho impostato nel file ups.conf (il file di configurazione del servizio) [mustek] driver = blazer_usb port = auto desc = "Musteck Power 800 usb" Ho impostato nel file upsd.conf (il file di configurazione del demone del servizio) LISTEN 127.0.0.1 3493 ACL all 0.0.0.0/0 ACL localhost 127.0.0.1/32 ACCEPT localhost REJECT all Ho impostato nel file upsd.users (il file di configurazione degli utenti del servizio) [mustek] password = 123456 allowfrom = localhost upsmon master Ho impostato nel file upsmon.conf (il file di configurazione del servizio di monitoraggio) MONITOR mustek@localhost 1 local_mon 123456 master Ho abilitato il servizio di moni