WALUDO Strumenti
DOCS.01 WALUDO DOCS

Promemoria Git

Riferimento dei comandi Git più comuni per configurazione, branch, commit, merge, annullamento, repository remoti e Conventional Commits, con esempi modificabili e copiabili.

Comandi comuni

La maggior parte dei comandi seguenti è raccolta da it-tools.tech e integrata con l’esperienza dello sviluppo quotidiano.

Il testo blu nei blocchi di codice è modificabile, così puoi cambiare e copiare rapidamente gli esempi.

Configurazione

Imposta nome utente ed email globali:

bash 
git config --global user.name "WaLudo"
git config --global user.email "[email protected]"

Iniziare un progetto

Inizializza un nuovo repository Git:

bash 
git init

Clona un repository Git esistente:

bash 
git clone https://github.com/WaLudo/waludo-tools.git

Commit

Esegui il commit di tutte le modifiche tracciate:

bash 
git commit -am "feat: add two cups of coffee"

Esegui il commit di tutte le modifiche:

bash 
git add .
git commit -m "feat: add five cups of coffee"

Aggiungi le nuove modifiche all’ultimo commit:

bash 
git commit --amend --no-edit

Ho combinato un guaio

Modifica il messaggio dell’ultimo commit:

bash 
git commit --amend

Annulla l’ultimo commit mantenendo le modifiche:

bash 
git reset HEAD~1

Annulla gli ultimi N commit mantenendo le modifiche:

bash 
git reset HEAD~N

Annulla l’ultimo commit ed elimina tutte le modifiche:

bash 
git reset HEAD~1 --hard

Riporta il branch locale allo stato remoto:

bash 
git fetch origin
bash 
git reset --hard origin/branch-name

Varie

Rinomina il branch locale master in main:

bash 
git branch -m master main

Convenzione dei commit

Consulta la specifica Conventional Commits v1.0.0.

Verifica il commit

git commit -m "feat(scope): description"

Riferimento rapido dei tipi

TipoDescrizione
fixCorregge un bug
featIntroduce una nuova funzionalità
buildModifica il sistema di build (dipendenze, interfacce esterne, versione di Node ecc.)
choreModifica elementi non legati alla logica di business (processo di build, configurazione degli strumenti ecc.)
ciModifica la configurazione dell’integrazione continua (CI/CD)
docsModifica la documentazione (README, documentazione API ecc.)
styleModifica lo stile del codice senza cambiare la logica
refactorRistruttura il codice senza cambiarne il comportamento
perfMigliora le prestazioni
testModifica i casi di test

Ambito

Dopo il tipo puoi aggiungere un ambito tra parentesi per fornire ulteriore contesto:

feat(parser): adds ability to parse arrays

Modifiche incompatibili

Un punto esclamativo indica una modifica incompatibile e può essere aggiunto a qualsiasi tipo:

feat(api)!: send an email to the customer when a product is shipped

Lo stesso effetto si ottiene inserendo BREAKING CHANGE nel footer.

Esempio di commit con corpo e footer su più righe:

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Specifica completa

Le parole chiave MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY e OPTIONAL devono essere interpretate secondo la RFC 2119.

  • Ogni commit MUST iniziare con un tipo, seguito da ambito OPTIONAL, punto esclamativo OPTIONAL e due punti con spazio finali REQUIRED
  • Una nuova funzionalità MUST usare il tipo feat
  • Una correzione MUST usare il tipo fix
  • L’ambito MAY seguire il tipo; MUST essere un sostantivo che descrive una parte del codice tra parentesi, ad esempio fix(parser):
  • La descrizione MUST seguire immediatamente i due punti e lo spazio del prefisso di tipo e ambito
  • Dopo la descrizione breve MAY comparire un corpo più lungo, che MUST iniziare dopo una riga vuota
  • Dopo un’altra riga vuota MAY comparire uno o più footer; ogni footer MUST contenere un token e un separatore
  • Il token di un footer MUST usare il trattino al posto degli spazi, ad esempio Acked-by; l’eccezione è BREAKING CHANGE
  • Una modifica incompatibile MUST essere indicata con ! nel prefisso o con il footer BREAKING CHANGE: descrizione
  • Se si usa !, BREAKING CHANGE: MAY essere omesso dal footer e la descrizione SHOULD spiegare la modifica
  • Si possono MAY usare tipi diversi da feat e fix, per esempio docs: updated ref docs.
  • Gli strumenti che implementano la specifica MUST interpretare le unità senza distinguere maiuscole e minuscole, salvo che BREAKING CHANGE MUST restare maiuscolo
  • BREAKING-CHANGE MUST essere sinonimo di BREAKING CHANGE quando usato come token di footer