User Tools

Site Tools


doc:appunti:prog:git

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
doc:appunti:prog:git [2024/02/12 11:07] – [Chiave SSH per Github.com] niccolodoc:appunti:prog:git [2026/11/06 10:51] (current) – [git restore] niccolo
Line 66: Line 66:
 cd qgis-web-client cd qgis-web-client
 git pull 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> </code>
  
Line 96: Line 118:
 git remote add origin_rw git@github.com:qgis/qgis-web-client.git git remote add origin_rw git@github.com:qgis/qgis-web-client.git
 git push origin_rw 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> </code>
  
Line 134: Line 165:
 </code> </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> <code>
Line 148: Line 181:
 <code> <code>
 git push origin print3d-1.0 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> </code>
  
Line 300: Line 339:
 git remote show origin git remote show origin
 </code> </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 ===== ===== Annullare le modifiche locali =====
Line 324: Line 376:
 Effettuare lo **stash** significa //mettere da parte// provvisoriamente le modifiche locali. Ciò che è stato //stashed// può essere visto con **git stash list**. 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> <code>
Line 334: Line 386:
 git merge '@{u}' git merge '@{u}'
 </code> </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 ===== ===== Chiave SSH per Github.com =====
doc/appunti/prog/git.1707732424.txt.gz · Last modified: by niccolo