Git rappresenta uno standard per gestire il versioning del codice sorgente (SOLO IL CODICE SORGENTE 🤣), per versatilità e semplicità.
Git è un SCM distribuito, non c’è un solo server centrale con l’unica versione ufficiale ma ad ogni clone creiamo un repository collegato con tanto di history dei commit.
git clone <http://…>
Ogni modifica è dichiarata al tramite il comando commit che si occupa di tracciare in un pacchetto (o versione) tutti i file presenti nello stage in quel momento, con un messaggio che lo rende facilmente identificabile nella history.
git commit -m “messaggio”
first of all… GITIGNORE –> https://www.gitignore.io/
Esistono tre luoghi in cui un file può essere: l’albero, l’indice e la copia di lavoro. Quando si aggiunge un file a una cartella, lo si aggiunge alla copia di lavoro. Quando fai qualcosa come git add file lo aggiungi all’indice. E quando lo commetti, lo aggiungi all’albero. Probabilmente ti aiuterà a conoscere i tre flag più comuni in git reset:
git reset [-
<mode>] [<commit>]
Questo modulo reimposta la diramazione attuale su <commit> e eventualmente aggiorna l’indice (reimpostandolo all’albero di <commit> ) e l’albero di lavoro in base a <mode> , che deve essere uno dei seguenti:
–soft Non tocca affatto il file indice né l’albero di lavoro (ma reimposta la testa su <commit> , proprio come fanno tutte le modalità). Questo lascia tutti i tuoi file modificati “Modifiche da impegnare”, come direbbe lo stato di git.
–misto Reimposta l’indice ma non l’albero di lavoro (cioè, i file modificati sono conservati ma non contrassegnati per il commit) e riporta ciò che non è stato aggiornato. Questa è l’azione predefinita.
–difficile Reimposta l’indice e l’albero di lavoro. Qualsiasi modifica ai file tracciati nell’albero di lavoro poiché <commit> viene scartata.
Ora, quando fai qualcosa come git reset HEAD – ciò che stai facendo è git reset HEAD --mixed e “resetterà” l’indice allo stato in cui era prima di iniziare ad aggiungere file / aggiungere modifiche all’indice (via git add ) In questo caso, la copia di lavoro e l’indice (o la fase di staging) erano sincronizzati, ma dopo il ripristino l’utente HEAD e l’indice erano sincronizzati.
git rm d’altra parte rimuove un file dalla directory di lavoro e dall’indice e quando si esegue il commit, il file viene rimosso dall’albero. git rm --cached tuttavia rimuove il file dal solo indice e lo mantiene nella copia di lavoro. Questo è l’esatto opposto di git add file In questo caso, hai fatto l’indice per essere diverso dal HEAD e il lavoro, in esso che il HEAD ha la versione precedentemente impegnata del file, la copia di lavoro ha avuto la modifica di las if any o content da HEAD del file e hai rimosso il file dall’indice. Un commit ora sincronizzerà l’indice e l’albero e il file verrà rimosso.
.gitignore does not work
Cambiato il .gitignore ma non vedi le modifiche? Piccola magia
git ls-files –deleted -z | git update-index –assume-unchanged -z –stdin
Git Stash ??
Il nostro lavoro potrebbe dover subire dei rallentamenti o Change Request improvvise e Git ci permette di gestire diversi “Branch” proprio per poter condurre contemporaneamente versioni diverse dello stesso applicativo. Per garantire la consistenza dei dati ci viene impedito di cambiare branch se abbiamo delle modifiche “in canna”, se il lavoro è incompleto, una commit potrebbe rendere lo stato inconsistente ma non vogliamo perdere le modifiche fatte… che fare? Possiamo utilizzare il comando stash
git stash
Ora, “messe da parte” le modifiche fatte al codice, si può cambiare stato (commit o branch) per poi sfruttare la pop per ripristinarli.
git stash
git pull
git stash popOfficial –> https://git-scm.com/docs/git-stash
Rename a Branch
If you want to rename a branch while pointed to any branch, do:
git branch -m <oldname> <newname>If you want to rename the current branch, you can do:
git branch -m <newname>Git Branch simple
in the new version of git you can use
git checkout <branch>
this simply checkout in a new local branch if does not exists