Come mantenere una cronologia pulita dopo la revisione del codice di richiesta pull di GitHub?

Question

Il nostro codice è su Github e utilizziamo le Richieste pull per esaminare il codice. Come risultato della revisione, un commit potrebbe essere ripristinato o modificato. Ciò potrebbe ingombrare la cronologia del commit. Il comando rebase è sconsigliato perché i commit sono già "pubblicamente disponibili".

Se si eseguono revisioni del codice in modo simile: come si gestisce questo? Come mantieni la tua storia pulita?

Answer 1

Il rebasing di rami non master (maint *, next) è ok anche se sono pubblicati. Usa solo i rami degli argomenti per pubblicare nuove cose da rivedere. Quindi eliminali in ogni caso dopo che sono stati uniti in master o dopo che la richiesta pull è stata rifiutata. Vedi man gitworkflows

Answer 2

Suggerirei semplicemente di passare sopra la cronologia dei commit in disordine.

Ricorda che quando guardi la cronologia, di solito guardi la discendenza di alcuni commit correnti. Se il tuo processo di revisione del codice crea diramazioni dead-end per il codice che è stato respinto o inviato nuovamente come un commit diverso, allora quelle non saranno in alcuno di questi antenati e di solito non verranno viste.

Ecco un esempio prolisso, ma completa di questo, utilizzando git log come il visualizzatore di storia:

$ git init example 
Initialized empty Git repository in /private/tmp/example/.git/ 
$ cd example/ 
$ date >date 
$ git add date 
$ git commit -am base 
[master (root-commit) 5108762] base 
1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 date 
$ date >date 
$ git commit -am bad 
[master 440c3b6] bad 
1 files changed, 1 insertions(+), 1 deletions(-) 
$ git log 
commit 440c3b61b279e8b7cd5f5f656984b63ba18e518b 
Author: Tom Anderson <twic@urchin.earth.li> 
Date: Sat Mar 10 09:15:48 2012 +0000 

    bad 

commit 5108762ba7011464fe3c57cf762d0d18f337f68c 
Author: Tom Anderson <twic@urchin.earth.li> 
Date: Sat Mar 10 09:15:28 2012 +0000 

    base 
$ git branch postreview 5108762ba7011464fe3c57cf762d0d18f337f68c 
$ git checkout postreview 
Switched to branch 'postreview' 
$ date >date 
$ git commit -am good 
[postreview 42e5257] good 
1 files changed, 1 insertions(+), 1 deletions(-) 
$ git log 
commit 42e5257addf73b516676d24e7092b0e4768d3564 
Author: Tom Anderson <twic@urchin.earth.li> 
Date: Sat Mar 10 09:17:30 2012 +0000 

    good 

commit 5108762ba7011464fe3c57cf762d0d18f337f68c 
Author: Tom Anderson <twic@urchin.earth.li> 
Date: Sat Mar 10 09:15:28 2012 +0000 

    base 

Anche se la cattiva commit è nel repository, ma non si presenta in uscita git log . In questo caso, ho creato una nuova filiale per svolgere il mio lavoro di post-revisione, ma in pratica, probabilmente vorrai spostare il master per il nuovo lavoro, lasciando il vecchio lavoro su un ramo morto.