Git: Commit

Una volta predisposta l’area di staging con le modifiche desiderate, è possibile procedere alla creazione di un commit. È importante ricordare che eventuali file ancora non aggiunti allo staging, ovvero quelli che sono stati creati o modificati ma per i quali non è stato eseguito il comando git add, non verranno inclusi nel commit corrente. Tali file rimarranno nello stato di modified nella working directory e potranno essere aggiunti successivamente.

Supponiamo, ad esempio, che l’ultimo comando git status abbia mostrato che tutte le modifiche risultano già correttamente inserite nello staging. In questo caso, è possibile eseguire il commit con il comando più semplice:

git commit

L’esecuzione del comando apre l’editor di testo configurato come predefinito (ad esempio Vim o Emacs), determinato dalla variabile d’ambiente EDITOR della shell. Tale editor può essere modificato a piacere tramite:

git config --global core.editor "<nome_editor>"

All’interno dell’editor viene mostrato un template che include:

• una riga vuota in cui inserire il messaggio di commit;
• un riepilogo delle modifiche in formato commentato, generato automaticamente da git status.

Le righe precedute dal carattere # sono considerate commenti e non vengono salvate nel commit. È possibile rimuoverle o lasciarle come promemoria.

FIG 1 - git commit

Per avere un contesto ancora più dettagliato, è possibile utilizzare l’opzione -v:

git commit -v

FIG 2 - git commit -v

In questo caso, oltre al riepilogo, viene mostrato anche il diff delle modifiche, consentendo di verificare con precisione quali linee di codice saranno incluse nel commit.

In alternativa, è possibile specificare il messaggio direttamente da riga di comando con l’opzione -m:

git commit -m "Modifica Projects1.cs"

Il messaggio deve essere chiaro, conciso e descrittivo, in modo da facilitare la comprensione della cronologia del progetto. È buona pratica adottare convenzioni uniformi all’interno del team di sviluppo (ad esempio includere ID di ticket o issue).

Output del commit

Dopo la conferma, Git fornisce un breve riepilogo contenente:

• il branch su cui è stato eseguito il commit (es. master o main);
• l’hash SHA-1 che identifica in maniera univoca il commit;
• il numero di file modificati;
• le statistiche sulle linee aggiunte e rimosse.

FIG 3 - Output commit

Il commit come snapshot

È fondamentale sottolineare che un commit non registra semplicemente le differenze, ma rappresenta un vero e proprio snapshot dello stato del progetto nell’area di staging in quel momento. Tutti i file non inclusi nello staging rimarranno inalterati nella working directory e potranno essere oggetto di un commit successivo.

Ogni commit diventa così una tappa storica nel ciclo di vita del progetto, alla quale è possibile tornare in caso di necessità, oppure confrontarla con versioni più recenti per analizzare l’evoluzione del codice.

Best Practice per i Messaggi di Commit

Un commit efficace non riguarda solo il codice, ma anche la documentazione della modifica. Scrivere messaggi chiari e coerenti consente a chiunque (incluso il sé stesso futuro) di comprendere rapidamente la storia del progetto.

Ecco alcune linee guida ampiamente riconosciute:

1. Usare un titolo breve e descrittivo

• Limitare la prima riga a 50 caratteri circa.
• Utilizzare il modo imperativo (es. “Fix bug”, “Add feature”, “Refactor code”) per descrivere l’azione.

2. Aggiungere una descrizione più dettagliata se necessario

• Inserire una riga vuota dopo il titolo.
• Fornire ulteriori spiegazioni sul perché della modifica, non solo sul cosa è stato cambiato.

3. Fare commit atomici

• Ogni commit deve contenere una modifica logica unica e indipendente.
• Evitare commit che mescolano refactoring, correzioni e nuove funzionalità.

4. Riferirsi a ticket o issue

• Quando si lavora in team con strumenti come Jira, GitHub o GitLab, citare l’ID del ticket o il numero dell’issue. Ad esempio: 
  git commit -m "Fix #182: corregge l’errore di serializzazione JSON"

5. Seguire convenzioni standardizzate

• Molti team adottano lo schema dei Conventional Commits, che prevede prefissi come:
  - feat: per nuove funzionalità
  - fix: per bugfix
  - docs: per modifiche alla documentazione
  - refactor: per miglioramenti interni al codice
  - test: per aggiunta o modifica di test
  
  Esempio:
  feat(auth): aggiunta autenticazione tramite OAuth2

6. Evitare messaggi generici

• Non usare commit come "update", "fix bug", "varie modifiche".
• Essere sempre specifici.

Git: Visualizzare le modifiche tracciate e non tracciate

Il comando git status fornisce una panoramica dello stato del repository, ma talvolta può risultare troppo generico: mostra quali file sono stati modificati, senza però evidenziare nel dettaglio quali righe siano cambiate.

Per ottenere una visione più approfondita delle differenze, è possibile utilizzare il comando git diff, che permette di ispezionare direttamente le modifiche a livello di contenuto.

In particolare, il comando git diff consente di ottenere risposte a due quesiti fondamentali:

• Quali modifiche sono state effettuate ma non ancora aggiunte all’area di staging?
• Quali modifiche risultano già presenti nello staging e che, di conseguenza, verranno incluse nel prossimo commit?

Differenze tra file modificati e staging area

Supponiamo, ad esempio, di modificare il file Readme.txt e di aggiungerlo allo staging con git add, mentre contestualmente modifichiamo il file Project1.cs senza però metterlo in staging.

Un comando git status restituirà un output simile a quello mostrato in FIG 1

FIG 1 - git status

In questa situazione, se eseguiamo:

git diff

Git ci mostrerà le modifiche presenti nel working directory ma non ancora aggiunte allo staging. Questo output, detto patch, include esattamente le righe aggiunte (+) e rimosse (-) nei file.

FIG 2 - git diff

Al contrario, se desideriamo visualizzare le differenze già pronte per il prossimo commit, dobbiamo usare:

git diff --staged

oppure, in alternativa:

git diff --cached

(--staged e --cached sono sinonimi). Questo comando confronta le modifiche presenti nello staging con l’ultimo commit registrato.

FIG 3 - git diff --staged

Caso pratico: modifiche sia staged che unstaged

Può accadere che lo stesso file venga modificato, aggiunto allo staging e poi ulteriormente modificato senza essere riaggiunto. In questo caso, git diff e git diff --staged mostrano rispettivamente:

• le differenze non ancora aggiunte,
• le differenze già pronte per essere salvate nel commit successivo.

Questo scenario è comune durante lo sviluppo, e l’uso combinato dei due comandi consente di avere il massimo controllo su ciò che sarà effettivamente registrato nella cronologia del progetto.

Nota importante: È bene sottolineare che git diff, se usato da solo, non mostra tutte le modifiche rispetto all’ultimo commit, ma solo quelle ancora unstaged.

Se tutte le modifiche sono state aggiunte allo staging, il comando non produrrà alcun output. In questi casi, l’opzione --staged è necessaria per visualizzare le differenze.

Utilizzo di strumenti esterni: git difftool

Per chi preferisce un’interfaccia grafica o un visualizzatore esterno, Git mette a disposizione il comando git difftool. Questo consente di analizzare le differenze utilizzando software come vimdiff, meld, kdiff3, o strumenti commerciali come Beyond Compare e Araxis Merge.

FIG 4 - git difftool, richiesta avvio tool per la comparazione

FIG 5 - Differenze nel file Project1.cs

Per scoprire quali strumenti sono disponibili sul proprio sistema:

git difftool --tool-help

È possibile configurare uno strumento di default nel file di configurazione globale:

git config --global diff.tool meld

Da quel momento, eseguendo git difftool senza ulteriori opzioni, Git aprirà automaticamente le differenze nell’applicativo scelto.

Best practices

• Usare spesso git diff: controllare con regolarità le differenze riduce il rischio di commettere modifiche indesiderate.
• Verificare prima di committare: un git diff --staged prima di eseguire il commit assicura che solo le modifiche realmente volute vengano salvate nella cronologia.
• Configurare strumenti grafici: in progetti complessi, visualizzatori esterni possono facilitare l’analisi di modifiche estese.

Di seguito una tabella riepilogativa dei principali comandi di Git usati per analizzare lo stato dei file e le modifiche:

Comando	Scopo principale	Cosa mostra	Quando usarlo	Output
git status	Fornisce una panoramica dello stato del repository	Elenco dei file modificati, non tracciati, staged o unstaged	Per avere una visione generale prima di committare	Testuale, descrittivo (ma non mostra le differenze riga per riga)
git diff	Mostra le modifiche non ancora aggiunte allo staging (unstaged)	Differenze tra working directory e staging area	Per sapere esattamente cosa è cambiato nei file non ancora aggiunti	Patch con righe aggiunte (+) e rimosse (-)
git diff --staged (o git diff --cached)	Mostra le modifiche già aggiunte allo staging	Differenze tra staging area e ultimo commit	Per verificare cosa verrà incluso nel prossimo commit	Patch dettagliata delle modifiche staged
git difftool	Visualizza le differenze con uno strumento esterno	Identico a git diff (staged o unstaged, a seconda dei parametri), ma in interfaccia grafica o editor	Per analizzare modifiche complesse o in progetti estesi	Dipende dallo strumento scelto (es. vimdiff, meld, Beyond Compare, ecc.)

New Outlook: Guida agli switch da riga di comando

Con l’introduzione di New Outlook, Microsoft non si è limitata a rinnovare l’interfaccia e a uniformare l’esperienza tra la versione desktop e quella web. Anche gli strumenti di amministrazione e diagnostica sono cambiati profondamente, inclusa la gestione degli switch da riga di comando, che risultano oggi molto differenti da quelli disponibili nel Classic Outlook.

Se nel client storico gli switch erano spesso usati per semplificare flussi di lavoro o integrare Outlook in procedure automatizzate, nella nuova versione l’obiettivo principale è spostato sul troubleshooting e sul supporto tecnico. Nonostante ciò, conoscere questi comandi può rivelarsi estremamente utile, soprattutto per amministratori IT, professionisti del supporto e power user.

In questo articolo analizzeremo sia gli switch documentati ufficialmente da Microsoft, sia quelli "nascosti", meno noti ma non meno interessanti, che consentono di ottenere un controllo più granulare sul comportamento dell’applicazione.

Utilizzo degli switch da riga di comando

L’esecuzione di uno switch in New Outlook segue una procedura relativamente semplice:

1. Premere la combinazione di tasti WIN+R  per aprire la finestra Esegui (oppure clic destro sul menu Start->Esegui).
2. Digitare olk.exe seguito da uno spazio.
3. Inserire due trattini (--) e il nome dello switch desiderato. 
   Ad esempio:
   olk.exe --safe
   
4. Premere Invio o fare clic su OK.

In questo modo Outlook si avvierà applicando il parametro selezionato.

FIG 1 - Finestra Esegui

Panoramica degli switch disponibili

Gli switch di New Outlook si dividono in due categorie:

• Documentati: elencati ufficialmente da Microsoft.
• Non documentati: scoperti tramite reverse engineering o sperimentazione e non sempre garantiti in termini di compatibilità futura.

Switch documentati

Switch	Descrizione
--clearLocalState	Cancella i file locali, la cache di WebView2 e riporta l’app allo stato "prima esecuzione". Utile per risolvere problemi di corruzione dati.
--force-update	Forza un controllo aggiornamenti di New Outlook.
--profile <nome>	Specifica il profilo di configurazione da utilizzare. Attualmente la funzionalità risulta limitata.
--safe	Avvia Outlook in modalità sicura, disabilitando PST, S/MIME, uso offline, configurazioni client non predefinite e componenti aggiuntivi Web.

Switch non documentati

Switch	Descrizione
--authloglevel <0-6>	Imposta il livello di log per l’autenticazione (0 = disattivato, 6 = massimo dettaglio).
--devtools	Attiva gli strumenti di sviluppo basati su Edge.
--offline	Disattiva i controlli offline, forzando l’avvio in modalità online.
--packageLogs	Genera un pacchetto locale con i log da condividere con il supporto tecnico.
--pos=<parametri>	Controlla posizione e dimensioni della finestra di Outlook (utile in configurazioni multi-monitor). I parametri da passare a pos sono valori separati da virgola che rappresentano la struttura WindowPlacement: rcNormal (sinistra, alto, destra, basso), versione, rcWork (sinistra, alto, destra, basso), dpi, showCmd, flag. Esempio: Per avviare Outlook nell'angolo superiore sinistro, con dimensioni 1200×800, su un monitor 1920×1080 con la barra delle applicazioni abilitata, configurato con 96 dpi; olk.exe --pos=0,0,1200,800,1,0,0,1920,1032,96,1,0
--recovery	Avvia Outlook in modalità di ripristino, simile a --safe ma con comportamenti più mirati al recupero della sessione.

Scenari di utilizzo pratico

• Supporto tecnico: con --clearLocalState o --packageLogs è possibile preparare rapidamente un ambiente "pulito" o fornire dati diagnostici al supporto Microsoft.
• Sviluppo e debug: lo switch --devtools permette di accedere alla console DevTools per analizzare il comportamento delle interfacce basate su WebView2.
• Gestione multi-monitor: grazie a --pos, gli amministratori possono predisporre avvii in posizioni e dimensioni predefinite, riducendo disallineamenti su workstation complesse.

Considerazioni finali

Gli switch da riga di comando in New Outlook riflettono la transizione verso un’applicazione ibrida, sempre più vicina a un’app web containerizzata, e meno a un classico client desktop. La riduzione delle opzioni di automazione è compensata da strumenti di diagnostica più avanzati, pensati per scenari enterprise e per semplificare le attività di troubleshooting.

Git: Ignorare i file con .gitignore

Spesso, all’interno di un progetto, esistono categorie di file che non si desidera vengano tracciati da Git né mostrati come untracked. Si tratta generalmente di file generati automaticamente, come log, file temporanei, file binari compilati o output di sistemi di build.

Per gestire questi casi, Git mette a disposizione il file speciale .gitignore, nel quale è possibile definire dei pattern che indicano i file o le directory da escludere dal controllo di versione.

Il file .gitignore è un semplice file di testo e il suo contenuto può essere del tipo:

# ignora tutti i file con estensione .a

*.a

# ma non ignorare lib.a

!lib.a

# ignora tutti i file con estensione .o o .a (tipici file oggetto o archivio generati da compilazioni).

*.[oa]

# ignora file con estensione .log e .tmp

*.log

*.tmp

# ignora le cartelle il cui nome inizia per Backup

Backup*/

Predisporre un file .gitignore fin dall’inizio del progetto è una buona pratica, perché evita di commettere accidentalmente file che non dovrebbero entrare nel repository.

Regole di base per i pattern in .gitignore

• Le righe vuote o quelle che iniziano con # sono ignorate (commenti).
• I glob pattern standard funzionano e vengono applicati ricorsivamente a tutta la working tree.
• Un pattern che inizia con / evita la ricorsività e si applica solo alla directory corrente.
• Un pattern che termina con / indica una directory intera.
• Un pattern che inizia con ! nega la regola, quindi forza il tracciamento di file che sarebbero altrimenti ignorati.

Glob pattern supportati
I glob pattern sono simili a espressioni regolari semplificate, comunemente usate nelle shell:

• *
  corrisponde a zero o più caratteri.
• [abc]
  corrisponde a un carattere tra quelli indicati (in questo caso a, b o c).
• ?
  corrisponde a un singolo carattere qualsiasi.
• [0-9]
  corrisponde a un carattere numerico da 0 a 9.
• **
  consente di corrispondere a directory nidificate (es. a/**/z corrisponde a a/z, a/b/z, a/b/c/z ecc.).

Normalmente, un progetto utilizza un unico file .gitignore nella directory principale, applicato ricorsivamente. Tuttavia, è possibile definire .gitignore aggiuntivi in sottodirectory: in questo caso, le regole si applicano solo ai file presenti sotto quella directory.

Per una descrizione completa delle regole supportate, è possibile consultare la pagina di manuale ufficiale con:

man gitignore

File .gitignore globali

Oltre ai .gitignore locali (specifici del progetto), è possibile definire un .gitignore globale valido per tutti i repository sullo stesso computer. Questo è utile per ignorare file tipici dell’ambiente di sviluppo personale (es. editor, IDE, sistema operativo).

Per configurarlo:

git config --global core.excludesfile C:/Users/<utente>/.gitignore_global

Git: Stato dei file

Uno degli strumenti principali per conoscere lo stato dei file all’interno di un repository è il comando:

git status

Se eseguito immediatamente dopo la clonazione di un repository, l’output potrebbe essere simile a quello mostrato in FIG 1.

FIG 1 - Nothing to commit

Questo messaggio indica che la working directory è "pulita": nessun file tracciato è stato modificato e non esistono file non tracciati. Inoltre, il comando segnala il ramo corrente (in questo caso master) e l'eventuale stato di sincronizzazione con il corrispondente ramo remoto (Ad esempio con il messaggio Your branch is up to date with 'origin/master'.).

Gestione nuovo file

Supponiamo di creare, all'interno della cartella del progetto, un nuovo file Readme.txt. Rieseguendo il comando git status avremo il messaggio mostrato in FIG 2.

FIG 2 - Untracked files

Come si può osservare, il file Readme.txt compare nella sezione Untracked files. Questo significa che Git lo rileva nella directory di lavoro, ma non lo sta ancora monitorando. Tale comportamento impedisce di includere accidentalmente file temporanei, binari generati o altri elementi non desiderati.

Per iniziare a tracciare il file è necessario utilizzare il comando:

git add Readme.txt

Eseguendo nuovamente git status si ottiene quanto mostrato in FIG 3.

FIG 3 - Changes to be committed

Ora Readme.txt risulta staged e pronto per essere incluso nel prossimo commit.

Gestire file modificati

Se si modifica un file già tracciato, ad esempio form.cs, l’output sarà simile a quello mostrato in FIG 4

FIG 4- Modified

Il file form.cs appare nella sezione Changes not staged for commit, a indicare che è stato modificato ma non ancora aggiunto allo staging. Per includerlo, si utilizza nuovamente git add:

git add form.cs

Eseguendo git status si vedrà che entrambi i file (Readme.txt e form.cs) sono ora pronti per il commit (FIG 5).

FIG 5 - Changes to be committed

Modifiche ulteriori su file già in staging

Può accadere di modificare nuovamente un file già aggiunto allo staging. In tal caso, lo stesso file apparirà in due sezioni contemporaneamente. Supponiamo di modificare nuovamente il file form.cs. Andando a visualizzare lo stato dei file con git status avremo la situazione mostrata in FIG 6.

FIG 6 - Modifica file già in staging

Il file modificato, form.cs, appare in due sezioni:

• Changes to be committed: rappresenta la versione del file già aggiunta allo staging.
• Changes not staged for commit: rappresenta la nuova versione del file, ancora non inclusa.

Questo comportamento è dovuto al fatto che Git memorizza nello staging area l’esatta istantanea del file al momento in cui è stato eseguito git add. Se il file viene modificato successivamente, per aggiornare l’istantanea occorre eseguire nuovamente:

git add form.cs

In questo modo, la versione aggiornata del file verrà inclusa nel prossimo commit.

Short Status

L’output del comando git status è piuttosto dettagliato, ma può risultare prolisso in alcune circostanze. Per questo motivo, Git mette a disposizione una modalità compatta tramite i flag:

git status -s

oppure

git status --short

Il risultato è una rappresentazione semplificata delle modifiche presenti nella working directory e nell’area di staging (FIG 7).

FIG 7 - Short Status

L'output del comando è composto da due colonne più il nome del file:  la colonna di sinistra (caratteri di colore verde) rappresenta lo stato del file nell’area di staging mentre quella di destra (caratteri di colore rosso) rappresenta lo stato del file nella working directory. 

Significato dei simboli

• ?? → file non tracciato (non incluso nello staging, nuovo file).
• A → file aggiunto allo staging (tracked per la prima volta).
• M → file modificato.
• D → file eliminato.
• R → file rinominato.
• C → file copiato.

Riassumendo

• git status è lo strumento di riferimento per monitorare lo stato della working directory.
• git add serve non solo ad aggiungere nuovi file al versionamento, ma anche ad aggiornare le modifiche di file già tracciati.
• Lo staging rappresenta uno snapshot intermedio: il commit fotografa esattamente i contenuti presenti nello staging al momento dell’esecuzione di git commit. 

Windows: Accesso al firmware UEFI

Nel contesto dei sistemi operativi Microsoft Windows, il comando shutdown rappresenta uno strumento di amministrazione fondamentale per la gestione delle operazioni di spegnimento, riavvio e logoff del sistema. Tra le numerose opzioni disponibili, una combinazione particolarmente interessante è la seguente:

shutdown /r /fw /t 0

Questo comando, eseguito come amministratore, consente di riavviare il sistema operativo con accesso diretto al firmware UEFI, offrendo un controllo avanzato della fase di avvio.

Analisi dei parametri

/r (Restart)

Specifica che il sistema deve essere riavviato dopo l’arresto. A differenza di /s, che provoca lo spegnimento completo, questa opzione ripristina immediatamente il ciclo di boot.

/fw (Firmware)

Indica che, al successivo riavvio, il sistema deve accedere direttamente al firmware UEFI (o BIOS, nei sistemi più datati).

Questa opzione è utile in scenari amministrativi in cui è necessario modificare rapidamente le impostazioni del firmware, senza dover premere manualmente i tasti funzione (ad esempio F2, F10 o Canc) durante la fase iniziale di avvio.

/t 0 (Timeout)

Definisce il tempo di attesa in secondi prima dell’esecuzione del comando. In questo caso, il valore 0 indica che l’operazione sarà avviata immediatamanete.

Il tempo può essere personalizzato da 0 a 315360000 secondi (10 anni), ma nell’amministrazione quotidiana è comune utilizzare valori ridotti.

FIG 1 - Firmware UEFI

Git: I repository

Un repository può essere pensato come un archivio di tutte le modifiche apportate ai file di un progetto. Contiene non solo la versione attuale, ma anche tutte le versioni precedenti e i branch di sviluppo.

In questo articolo verranno illustrati i principali metodi per ottenere un repository Git locale.

È possibile ottenere un repository Git in due modalità principali:

1. Inizializzazione di un repository locale: trasformare una directory già esistente, non ancora gestita da un sistema di versionamento, in un repository Git.
2. Clonazione di un repository remoto: scaricare una copia completa di un repository Git già esistente, ad esempio ospitato su piattaforme come GitHub, GitLab o Bitbucket.

In entrambi i casi, al termine dell’operazione si dispone di un repository Git completamente funzionante sul proprio sistema Windows.

Una volta creato o clonato un repository, si possono iniziare a gestire i file e le modifiche.

• Staging Area (git add): Prima di salvare le modifiche in un commit, è necessario dire a Git quali modifiche includere. Questo si fa trasferendo i file modificati (o nuovi) nella "staging area" (anche chiamata "indice").

git add nomefile.txt

git add . (per aggiungere tutti i file modificati nella directory corrente)

• Commit (git commit): Un commit è un'istantanea ("snapshot") dello stato del progetto in un determinato momento. Ogni commit rappresenta idealmente una singola modifica concettuale. I commit sono collegati tra loro in una "catena", che rappresenta la storia del repository.

git commit -m "Messaggio descrittivo del commit"

Il messaggio è molto importante e la prima riga viene usata come titolo in molte visualizzazioni. Dovrebbero essere concisi (prima riga preferibilmente <50 caratteri) e descrivere chiaramente le modifiche. La seconda riga può rimanere vuota, e dalla terza in poi possono seguire maggiori dettagli. Possono includere riferimenti a problemi (issues) e pull request.

• Stato del repository (git status): Permette di vedere quali file sono stati modificati, quali sono nella staging area e quali non sono tracciati.

git status

• Sincronizzazione con repository remoti:

• git push: Invia i commit dal repository locale a quello remoto.
  git push origin main
• git pull: Scarica le modifiche dal repository remoto e le integra nel repository locale.
  git pull
• git fetch: Scarica le modifiche dal repository remoto ma non le integra automaticamente nel repository locale.

• Branching (concetto base): Il branching è una funzionalità chiave di Git che permette di divergere dalla linea di sviluppo principale e lavorare su modifiche senza influenzare il codice stabile. I branch sono essenzialmente puntatori a un commit. Sebbene la gestione avanzata dei branch sia complessa, i principi di base sono essenziali per iniziare.

git checkout -b nome-nuovo-branch (crea un nuovo branch e ci si sposta)

• Visualizzazione della cronologia (git log): Mostra una lista dei commit, con il più recente in cima. È uno strumento potente per ripercorrere la storia del progetto.

git log

1. Inizializzare di un Repository locale

Se si possiede già una cartella di progetto che non è attualmente gestita da Git, è possibile convertirla in un repository locale.

Per farlo, è necessario aprire il Prompt dei Comandi o PowerShell e spostarsi nella directory desiderata.

Ad esempio
cd C:/Projects/my_project

Una volta posizionati nella cartella del progetto, è sufficiente digitare:

git init

FIG 1 - Git init

Questo comando crea una sottodirectory nascosta denominata .git, contenente tutti i file necessari al funzionamento interno del sistema di versionamento. A questo punto, il progetto è formalmente sotto controllo di Git, ma nessun file risulta ancora tracciato.

FIG 2 - Directory .git

1.1 Aggiungere e Versionare i File

Per iniziare a gestire i file già presenti nella directory, occorre eseguirne il tracciamento. Ad esempio:

git add *.cs
git add Readme.txt

Il comando git add permette di selezionare i file da includere nella prossima revisione. Una volta aggiunti, è possibile creare il primo commit:

git commit -m "Versione iniziale del progetto"

Questo passaggio registra ufficialmente lo stato iniziale del progetto nella cronologia di Git.

FIG 3 - Git add e commit

2. Clonazione di un repository remoto

La seconda modalità per ottenere un repository consiste nella clonazione di un progetto già esistente.

A differenza di altri sistemi di versionamento centralizzati (ad esempio Subversion), Git non scarica solo una copia superficiale del progetto, bensì l’intera cronologia e la struttura interna del repository. Questo significa che ogni clone è, a tutti gli effetti, un repository completo e indipendente.

Il comando da utilizzare è:

git clone <url>

Supponiamo di voler clonare il noto editor Notepad++ direttamente da GitHub. È sufficiente digitare:

git clone https://github.com/notepad-plus-plus/notepad-plus-plus.git

Questo comando produce i seguenti effetti:

• crea una cartella denominata notepad-plus-plus;
• inizializza al suo interno una directory .git;
• scarica tutti i dati del repository remoto;
• prepara automaticamente una copia di lavoro dell’ultima versione disponibile.

FIG 4 - git clone

Se si desidera clonare lo stesso repository in una cartella con un nome diverso, è possibile specificarlo come secondo parametro:

git clone https://github.com/notepad-plus-plus/notepad-plus-plus.git progetto1

In questo caso, i file del repository verranno copiati all’interno della directory progetto1.

Protocolli di Trasferimento Supportati

Git consente la clonazione e l’interazione con i repository remoti tramite diversi protocolli, ciascuno con specifici vantaggi e svantaggi:

• HTTPS: semplice da configurare e adatto a qualsiasi contesto, richiede spesso l’inserimento delle credenziali.
• SSH: più sicuro ed efficiente, consigliato per ambienti professionali; necessita la configurazione di una coppia di chiavi pubblica/privata.
• Git protocol (git://): veloce ma meno sicuro, usato raramente nei progetti moderni.

Registrare le modifiche nel repository

A questo punto si dispone di un vero e proprio repository Git locale, completo di una working copy contenente tutti i file del progetto. Da qui in avanti, l’attività tipica consiste nell’apportare modifiche e nel registrarne periodicamente lo stato mediante commit, creando così delle “istantanee” dell’evoluzione del progetto ogni volta che si raggiunge una condizione significativa.

È fondamentale comprendere che ciascun file presente nella directory di lavoro può trovarsi in uno dei seguenti stati: Tracciato (tracked) o Non tracciato (untracked).

• File tracciati (tracked): tutti i file presenti nell’ultimo commit, oltre a quelli che sono stati aggiunti all’area di staging. Essi possono trovarsi in tre condizioni differenti: non modificati, modificati o staged (pronti per il commit). In altre parole, sono i file di cui Git è a conoscenza e che gestisce attivamente.
  
• File non tracciati (untracked): tutti i file che si trovano nella directory di lavoro ma che non erano presenti nell’ultimo commit e non sono stati aggiunti allo staging.

Quando si clona un repository per la prima volta, tutti i file risultano tracciati e non modificati, poiché Git li ha appena copiati dal commit più recente.

Nel momento in cui si inizia a modificarli, Git rileva tali cambiamenti e li contrassegna come modificati. A questo punto, lo sviluppatore può decidere quali di essi inserire selettivamente nell’area di staging e, successivamente, consolidare tali modifiche in un nuovo commit. Questo processo – modifica, staging, commit – costituisce il ciclo fondamentale del lavoro quotidiano con Git.

Il Ciclo di Lavoro: Modifica, Staging e Commit

Il flusso di lavoro tipico con Git prevede una sequenza ricorrente di tre fasi:

1. Modifica dei file nella working directory. Una volta che si cambia un file già tracciato, Git lo riconosce come modificato.
   
2. Aggiunta allo staging delle modifiche rilevanti. Questo passaggio permette di selezionare quali modifiche includere nel prossimo commit. Ad esempio:
   git add nome_file.ext 
   oppure, per aggiungere tutti i file modificati
   git add .
   
3. Creazione di un commit. Il commit rappresenta una vera e propria "fotografia" dello stato dei file in staging. È buona prassi accompagnare il commit con un messaggio descrittivo:
   git commit -m "Descrizione delle modifiche effettuate"

Questo ciclo si ripete ogni volta che il progetto raggiunge uno stato che si desidera salvare nella cronologia.

Git: Configurazioni iniziali

Una volta installato Git, è necessario effettuare alcune configurazioni iniziali. Tali configurazioni vanno eseguite una sola volta su ogni computer e verranno mantenute tra gli aggiornamenti. Sarà sempre possibile modificare tali impostazioni successivamente.

Git include uno strumento chiamato git config che consente di visualizzare e modificare le impostazioni.

Le impostazioni di Git sono memorizzate in tre file di configurazione principali, a seconda del loro ambito:

• Locale:
  Le impostazioni specifiche per un singolo repository si trovano nel file .git/config all'interno della cartella del repository stesso.
• Globale:
  Le impostazioni che si applicano a tutti i repository di un utente sono memorizzate nel file .gitconfig nella directory home dell'utente. Il percorso esatto varia a seconda del sistema operativo:
  - macOS / Linux: ~/.gitconfig 
  - Windows: C:\Users\<NomeUtente>\.gitconfig 
• Sistema: Le impostazioni che si applicano a tutti gli utenti del sistema si trovano nel file gitconfig nella cartella di installazione di Git, solitamente in una posizione come C:\ProgramData\Git\config su Windows o /etc/gitconfig su Linux.

Quando Git legge le impostazioni, lo fa seguendo un ordine preciso:

1. Locale
2. Globale
3. Sistema

Questo significa che un'impostazione definita a livello locale sovrascriverà un'impostazione globale, che a sua volta sovrascriverà un'impostazione a livello di sistema.

Per visualizzare tutte le impostazioni e da quale file vengono prelevate è possibile utilizzare il comando

git config --list --show-origin

FIG 1 - Impostazioni Git

Identità

Quando si installa Git è fondamentale impostare il proprio nome utente e indirizzo email in modo che i propri commit possano essere identificati (tali informazioni vengono immutabilmente inserite all'interno dei commit creati).

I comandi da eseguire sono

git config --global user.name "<il_tuo_nome>" 

git config --global user.email "<indirizzo_email>"

Ad esempio

git config --global user.name "Giovanni Lubrano"

git config --global user.email giovanni.lubrano@contoso.com

Utilizzando l'opzione --global, Git utilizzerà sempre tali informazioni per l'utente sul sistema. 

Qualora si desideri sostituire tali informazioni con un nome o un indirizzo e-mail differenti per uno specifico progetto, è possibile eseguire il comando senza l’opzione --global all’interno della directory del progetto stesso.

Nome del branch predefinito

Dal 2020, GitHub e GitLab hanno adottato main come nome predefinito per i nuovi repository. Per impostazione predefinita, al momento della creazione di un nuovo repository mediante il comando git init, Git genera un ramo denominato master. A partire dalla versione 2.28 (luglio 2020), è tuttavia possibile definire un nome alternativo per il ramo iniziale, specificando quello da utilizzare come predefinito.

Per impostare main come nome predefinito del ramo, utilizzare il comando:
git config --global init.defaultBranch main

Editor predefinito 

Se non diversamente indicato, Git utilizza l’editor di testo predefinito per la redazione dei messaggi di commit e per la modifica dei file di configurazione. Durante la fase di installazione è già stato selezionato l’editor desiderato. Qualora si desideri modificarlo, è possibile farlo tramite il comando:

git config --global core.editor "<path_file_eseguibile_editor>"

Ad esempio

git config --global core.editor "C:/Program Files/Notepad++/notepad++.exe"

Controllo delle impostazioni

Per verificare le impostazioni di configurazione è possibile utilizzare il seguente comando che consente di elencare tutte le configurazioni attualmente riconosciute da Git

git config --list

FIG 2 - Impostazioni di configurazione

Alcune chiavi possono comparire più volte, in quanto Git le legge da file di configurazione differenti. In tali circostanze, per ciascuna chiave univoca viene considerato come valido l’ultimo valore rilevato.

È possibile verificare quale valore Git attribuisce a una chiave specifica digitando 

git config <chiave>

Ad esempio

git config user.name

Poiché Git può leggere il medesimo valore di una variabile di configurazione da più file, è possibile che venga restituito un risultato inatteso, la cui origine non sia immediatamente evidente. In tali circostanze, è possibile interrogare Git per determinare la provenienza del valore, ottenendo l’indicazione del file di configurazione che ha prevalso nell’assegnazione finale. Il comando da eseguire è

git config --show-origin <chiave>

Ad esempio

git config --show-origin user.name

FIG 3 - Valore e origine di una variabile

Help

Qualora si necessiti di supporto durante l’utilizzo di Git, esistono tre modalità equivalenti per accedere alla pagina di manuale (manpage) completa relativa a qualsiasi comando:

git help <comando>

git <comando> --help

man git-<comando>

Ad esempio, per visualizzare la manpage del comando git config, è sufficiente eseguire:

git help config

FIG 4 - Help

Questi comandi risultano particolarmente utili poiché consentono di consultare la documentazione in qualsiasi momento, anche offline.

Windows : Risoluzione dell'errore "Impossibile aprire l’oggetto Criteri di gruppo sul computer"

In alcuni scenari, durante l’apertura dell’Editor Criteri di Gruppo Locali (gpedit.msc), Windows può restituire il seguente errore:

Impossibile aprire l’oggetto Criteri di gruppo sul computer. Potresti non disporre delle autorizzazioni necessarie. 
Dettagli: Errore non specificato.

Nella versione inglese di Windows

Failed to open the Group Policy Object on the computer. You might not have the appropriate rights.
Details: Unspecified error

Contestualmente, tentando di aggiornare le policy tramite il comando gpupdate, può comparire un ulteriore messaggio:

Elaborazione dei Criteri di gruppo non riuscita. Windows non è stato in grado di applicare le impostazioni dei criteri basate sul registro per l’oggetto Criteri di gruppo LocalGPO. Le impostazioni di Criteri di gruppo non verranno risolte finché questo evento non verrà risolto.

Nella versione inglese il messaggio è

The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LocalGPO.

FIG 1 - The processing of Group Policy failed

In questi casi, nel Visualizzatore Eventi di sistema viene registrato un evento con ID 1096, che segnala l’impossibilità di applicare le impostazioni delle Criteri di Gruppo locali.

Cause del problema

L’errore si verifica in genere quando i file delle policy locali, situati nella cartella:

%windir%\System32\GroupPolicy

risultano corrotti o mancanti.

In particolare, il file Registry.pol, che contiene le impostazioni delle policy basate su registro, può essere danneggiato e impedire l’elaborazione delle regole.

Procedura di risoluzione

1. Rimuovere o rinominare il file Registry.pol

Per ripristinare il corretto funzionamento, è sufficiente rimuovere (o rinominare) il file Registry.pol corrotto.

Il file può trovarsi in uno dei seguenti percorsi:

• %windir%\System32\GroupPolicy\Machine
• %windir%\System32\GroupPolicy\User

Dopo la rimozione, riavviare l’Editor delle Criteri di Gruppo locali (gpedit.msc) e verificare che si apra senza errori.

2. Ricreare la cartella GroupPolicy (se necessario)

Se il problema persiste, può rendersi necessario ricreare completamente la cartella GroupPolicy.

È possibile procedere rinominando la directory corrente tramite Esplora File oppure con PowerShell:

Rename-Item -Path "C:\Windows\System32\GroupPolicy" -NewName GroupPolicy_backup

Al successivo avvio o aggiornamento delle policy, Windows rigenererà automaticamente una nuova cartella GroupPolicy.

Dopo aver verificato il corretto funzionamento, la cartella di backup può essere eliminata.