diff --git a/git-crash-course.md b/git-crash-course.md index 24c112f..53c0600 100644 --- a/git-crash-course.md +++ b/git-crash-course.md @@ -129,7 +129,7 @@ Creare un nuovo repository partendo da una directory (vuota o meno): Clonare un repository remoto esistente: - $ git clone https://github.com/user/repo.git + $ git clone https://git.lattuga.net/user/repo.git ----- @@ -241,7 +241,7 @@ Un tag è un puntatore ad un commit: Rappresenta la storia dei commit fino al punto corrente (o da/a qualsiasi punto indicato). -Si può limitare agli ultimi N commit con **-N** +Si può limitare agli ultimi N commit con ***-N***
@@ -339,12 +339,14 @@ Creare e spostarsi in un singolo comando: * **master** è solamente un default +* **HEAD**: reference al branch (o commit) corrente + +* **refs**: nome collettivo per riferirsi ad HEAD, branches, tags + * fate caso all'asterisco: è il branch corrente * dare nomi significativi; usate prefissi (bugfix/, fix/, improvement/, feature/, task/) e issue di riferimento -* **refs**: nome collettivo per riferirsi ad HEAD, branches, tags - --- ## Rimettere insieme i pezzi: merge @@ -404,6 +406,10 @@ Mergiamo: +### Bonus track + +* che succede se cancelliamo fix/bug-123? + ----- ## Conflict files @@ -420,7 +426,7 @@ Cercare sempre tutti i markers **<<<<<<<**, **=======**, **>>>>>>>** ## Lavorare con repository remoti - $ git remote add origin https://github.com/user/repo.git + $ git remote add origin https://git.lattuga.net/user/repo.git $ git remote -v
@@ -460,7 +466,7 @@ Aggiungere al repository remoto un branch locale: $ git push --set-upstream origin local-branch-name -Aggiungiamo i cambiamenti locali ad un branch remoto: +Inviare i cambiamenti locali ad un branch remoto: $ git push --tags [origin [master]] @@ -469,6 +475,7 @@ Aggiungiamo i cambiamenti locali ad un branch remoto: ### Bonus track * git push di default non invia i tags +* cancellare un branch remoto: **git push -d origin branch-name** --- @@ -476,7 +483,7 @@ Aggiungiamo i cambiamenti locali ad un branch remoto: Cosa da non fare **MAI** (salvo non ne siate davvero convinti): modificare una history che sia già stata pushata. -Questo perché se qualcuno sta lavorando sullo stesso branch remoto, le altre persone si troveranno con dei repository non consistenti. +Questo perché se qualcuno sta lavorando sullo stesso branch remoto, le altre persone si troveranno con dei repository non coerenti. --- @@ -512,8 +519,7 @@ Valide risorse: Vediamo il **forking workflow**. Non perché sia intrinsecamente il migliore, ma perché quello più diffuso nello sviluppo su piattaforme come Github. Presupposti: * esiste un repository ufficiale (chiamiamolo **upstream**) di riferimento su cui solo gli autori principali possono scrivere -* i contributi di terzi sono accettati -* ruolo di **project maintainer**: la persona che si occuperà di mergiare nel repository principale +* ruolo di **project maintainer**: la persona che si occuperà di mergiare nel repository upstream * ruolo di **developer**: chi sta sviluppando un fix o una nuova feature * ciascun developer avrà un fork remoto del repository upstream ed una copia locale su cui lavorare @@ -523,9 +529,7 @@ Vediamo il **forking workflow**. Non perché sia intrinsecamente il migliore, ma Il project maintainer ha creato il repository upstream remoto e il proprio clone locale. -Maintainer: - -* git clone + $ git clone https://git.lattuga.net/maintainer/repo.git @@ -547,7 +551,10 @@ Il developer ora: ## Forking workflow: developer setup -* fa un **clone** locale del proprio repository remoto +Developer fa un **clone** locale del proprio repository remoto. È di norma buona idea aggiungere un remote "**upstream**" che punti al repository del maintainer: + + $ git clone https://git.lattuga.net/developer/repo.git + $ git remote add upstream https://git.lattuga.net/maintainer/repo.git @@ -557,12 +564,12 @@ Il developer ora: Developer deve sviluppare un fix che andrà applicato sul branch master del repository upstream. -Nel clone locale del *proprio* fork, farà: +Prima di tutto è opportuno sincronizzare il proprio branch master con quello upstream: $ git checkout master $ git pull upstream - + ----- @@ -596,7 +603,7 @@ Ora va sulla pagina web del proprio fork e crea una **pull request**. Pull request **NON** è un concetto base di Git (non esattamente, almeno). È qualcosa che vi è stato costruito sopra per facilitare la collaborazione tra sviluppatori. -La pull request creata in precedenza dice: "propongo di applicare i commit del branch *developer-fork:fix/bug-123* a *repository-upstream:master*" +La pull request creata in precedenza dice: "propongo di applicare i commit del branch *developer:fix/bug-123* a *maintainer:master*" Ora developer, project maintainer e altri possono discuterne. Se dovesse essere necessario, developer può aggiungere altri commit semplicemente con un nuovo push. @@ -605,12 +612,46 @@ Se dovesse essere necessario, developer può aggiungere altri commit semplicemen ## Forking workflow: merging -Una volta soddisfatti, project maintainer potrà effettuare il merge del codice su *repository-upstream:master*. +Una volta soddisfatti, project maintainer potrà effettuare il merge del codice su *maintainer:master*. -Se il merge non presenta conflitti, lo si può fare direttamente dalla GUI web sul repository upstream. Altrimenti il project maintainer dovrà fare il fetch di developer-fork:fix/bug-123 sul proprio clone locale, effettuare il merge su master per poi farne il push sul repository upstream. +Se il merge non presenta conflitti, lo si può fare direttamente dalla GUI web sul repository upstream. Altrimenti il project maintainer dovrà fare il fetch di developer:fix/bug-123 sul proprio clone locale, effettuare il merge su master per poi farne il push sul repository upstream. +----- + +## Forking workflow: sunto setup maintainer + +1. clone locale: git clone https://git.lattuga.net/maintainer/repo.git + +----- + +## Forking workflow: sunto setup developer + +1. fork sul web +1. clone locale del fork: git clone https://git.lattuga.net/developer/repo.git +1. aggiunge un remote che punta al repository upstream: git remote add upstream https://git.lattuga.net/maintainer/repo.git + +----- + +## Forking workflow: sunto sviluppo developer + +1. aggiorna il proprio master: git checkout master ; git pull upstream +1. crea un branch su cui lavorare: git checkout -b fix/bug-123 +1. invia le modifiche al proprio repository remoto: git push --set-upstream origin fix/bug-123 +1. crea sul web una pull request +1. se serve, integra il lavoro semplicemente pushando altri commit fatti su fix/bug-123 + +----- + +## Forking workflow: sunto lavoro del maintainer + +1. riceve una pull request e la valuta. +1. se mergiabile senza conflitti, lo fa via web. *Altrimenti:* +1. ottiene il branch di developer: git fetch https://git.lattuga.net/developer/repo.git fix/bug-123 +1. effettua il merge sul proprio master locale, risolvendo i conflitti: git merge fix/bug-123 +1. invia il master al proprio repository remoto: git push origin master + --- ## Parte 2 @@ -631,7 +672,6 @@ Salire di un livello, seguendo il secondo parent commit (in caso di merge): ### Bonus track -* cosa è HEAD: reference al branch (o commit) corrente * **detached HEAD**: ci siamo spostati su un commit che non è l'head di un branch * questi operatori sono concatenabili: HEAD~~^2 @@ -647,6 +687,8 @@ triple dot range: $ git log --left-right master...branch +TODO: descrivi! + ----- ## Referenziare i commit: range