summary of workflow
This commit is contained in:
parent
e02e379ab3
commit
9960fe1407
1 changed files with 61 additions and 19 deletions
|
|
@ -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***
|
||||
|
||||
<br />
|
||||
|
||||
|
|
@ -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:
|
|||
|
||||
<img style="width:300px" src="images/branch-conflict-solved.png" data-action="zoom">
|
||||
|
||||
### 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
|
||||
|
||||
<br />
|
||||
|
|
@ -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
|
||||
|
||||
<img style="width:300px" src="images/worflow-maintainer-clone.png" data-action="zoom">
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
<img style="width:300px" src="images/worflow-developer-clone.png" data-action="zoom">
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
<img style="width:300px" src="images/worflow-developer-branch.png" data-action="zoom">
|
||||
<img style="width:300px" src="images/worflow-developer-pull-upstream.png" data-action="zoom">
|
||||
|
||||
-----
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
<img style="width:300px" src="images/worflow-maintainer-local-fix.png" data-action="zoom">
|
||||
|
||||
-----
|
||||
|
||||
## 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
|
||||
|
|
|
|||
Loading…
Reference in a new issue