Differences

This shows you the differences between two versions of the page.

--- doc:appunti:prog:git [2022/01/09 18:14] – niccolo
+++ doc:appunti:prog:git [2026/11/06 10:51] (current) – [git restore] niccolo
@@ Line 66: / Line 66: @@
 cd qgis-web-client
 git pull
+</code>
+==== git add ====
+Se nel repository locale di un progetto si aggiunge un file, questo risulta come //untracked file// (vedere con ''git status''). È necessario aggiungerlo al sistema di tracking di Git con il comando:
+<code>
+git add filename
+</code>
+Se si sono aggiunte diverse directory e file al progetto, è possibile aggiungerli tutti al sistema di tracking di Git con:
+<code>
+git add -A
+</code>
+==== git restore ====
+Se un file viene modificato nel repositori locale e **non è stato committed** né pushed nel repository origine, è possibile riportarlo alla versione precedente con:
+<code>
+git restore nomefile
 </code>
@@ Line 96: / Line 118: @@
 git remote add origin_rw git@github.com:qgis/qgis-web-client.git
 git push origin_rw
+</code>
+==== git pull --rebase ====
+Può capitare che un ''git push'' fallisca perché il repository remoto ha ricevuto qualche push da qualche altro sviluppatore che non è stato integrato localmente. In questo caso si può sperare di risolvere semplicemente il conflitto allineando il repository locale con quello remoto e poi ripetere il commit:
+<code>
+git pull --rebase
+git push
 </code>
@@ Line 134: / Line 165: @@
 </code>
-se invece della versione corrente si vuole etichettare un commit precedente, bisogna individuare l'hash ed eseguire il comando (notare che l'hash è indicato in forma abbreviata):
+Una pratica abbastanza diffusa è quella di usare il solo numero di versione come tag, es. **v0.41**. Viene aperto l'editor per poter inserire una **breve descrizione** del tag.
+Se invece della versione corrente si vuole etichettare un commit precedente, bisogna individuare l'hash ed eseguire il comando (notare che l'hash è indicato in forma abbreviata):
 <code>
@@ Line 148: / Line 181: @@
 <code>
 git push origin print3d-1.0
+</code>
+È possibile anche fare il push di tutti i nuovi tag con il comando:
+<code>
+git push origin --tags
 </code>
@@ Line 256: / Line 295: @@
 ===== Misc Commands =====
-==== Revert di un singolo file ====
+==== Restore o revert di un singolo file ====
+A partire da Git 2.23 esiste il comando **git restore** che consente di ripristinare un file modificato localmente alla sua versione di checkout:
+<code>
+git restore path/to/file
+</code>
+Con versioni precedenti di Git si può usare:
+<code>
+git checkout -- path/to/file
+</code>
+Se si desidera tornare ad uno specifico commit, si può visualizzare il log degli stessi e richiederlo esplicitamente:
 <code>
 git log path/to/file
-git checkout <commit> path/to/file
+git checkout <commit_id> path/to/file
 </code>
@@ Line 286: / Line 339: @@
 git remote show origin
 </code>
+===== Annullare le modifiche locali in conflitto con origin/main =====
+Se un file è stato cambiato sia nella copia locale che nel repository originale, queste sono le istruzioni per annullare le modifiche locali e riallineare tutto al **origin/main** (nell'esempio il file cambiato è ''database-pgsql.sql''):
+<code>
+git fetch origin
+git checkout origin/main -- database-pgsql.sql
+git pull
+git status
+</code>
+In questo modo le modifiche locali vengono annullate e **non resta traccia** di esse nel git.
 ===== Annullare le modifiche locali =====
@@ Line 310: / Line 376: @@
 Effettuare lo **stash** significa //mettere da parte// provvisoriamente le modifiche locali. Ciò che è stato //stashed// può essere visto con **git stash list**.
-Questi passaggi riallineano il repository locale con quello remoto. L'operazione conclusiva di merge comunque viene registrata in Git e pertanto viene chiesa una riga di commento:
+Questi passaggi riallineano il repository locale con quello remoto. L'operazione conclusiva di merge comunque viene registrata in Git e pertanto viene richiesta una riga di commento:
 <code>
@@ Line 320: / Line 386: @@
 git merge '@{u}'
 </code>
+===== Ignorare le modifiche locali =====
+Se in un clone locale è necessario modificare alcuni file (ad esempio un file di configurazione) ma non si vuole che tale modifica sia propagata al repository, è possibile marcare ciascun file in questo modo:
+<code>
+git update-index --skip-worktree config/database.php
+</code>
+Il file in questione verrà **ignorato** sia da **pull** che da **push**. Per rimuovere tale caratteristica:
+<code>
+git update-index --no-skip-worktree config/database.php
+</code>
+Purtroppo questa configurazione non può essere utilizzata per ignorare una intera directory.
+===== .gitignore =====
+Supponiamo che nella radice di un progetto Git si abbia il file **.gitignore** che contiene:
+<file>
+# --- Gradle & build output ---
+.gradle/
+build/
+# --- Local, machine-specific config ---
+local.properties
+# --- Signing secrets: NEVER commit these ---
+*.jks
+*.keystore
+keystore.properties
+# --- IDE / editor (not used here) ---
+*.iml
+.idea/
+.vscode/
+# --- OS cruft ---
+.DS_Store
+Thumbs.db
+# --- Misc ---
+*.log
+captures/
+</file>
+ad esempio la riga **build/** significa che qualsiasi cartella con quel nome verrà ignorata, ad esmepio **/build/** e **/app/build/**. L'esempio sopra è tipico di un progetto gestito con Gradle (tool per compilazione e pacchettizzazione Android). Nel file si indica di ignorare altri file eventualmente creati durante la normale attività di sviluppo, che però non ha senso replicare sul repository pubblico.
+Il progetto può includere altri **.gitignore** in sottocartelle, questi verranno applicati ovviamente a partire da esse e ricorsivamente nelle sottocartelle.
 ===== Chiave SSH per Github.com =====
@@ Line 347: / Line 465: @@
 ssh -T git@github.com
 Hi RigacciOrg! You've successfully authenticated, but GitHub does not provide shell access.
-</code<
+</code>
 Verifichiamo che un repository locale sia stato clonato tramite protocollo HTTPS: