Revisione del codice Gerrit o modello fork e pull di Github?


64

Sto iniziando un progetto software che sarà sviluppato da team e comunità. In precedenza ero venduto su gerrit, ma ora il modello di richiesta fork e pull di Github sembra quasi fornire più strumenti, modi per visualizzare i commit e facilità d'uso.

Per qualcuno che ha almeno una piccola esperienza con entrambi, quali sono i pro / contro di ciascuno e quale sarebbe meglio per un progetto basato su un team che vuole lasciare aperta la possibilità di sviluppo della comunità?

Risposte:


84

La principale differenza tra i flussi di lavoro di Gerrit e GitHub è la modellazione dei cambiamenti.

In Gerrit, ogni commit è un cambiamento che si distingue da solo. Sebbene Gerrit mostrerà le relazioni tra commit, le revisioni vengono eseguite in base al commit. Le squadre che sono brave a scomporre grandi cambiamenti in piccoli impegni autonomi avranno probabilmente più successo con Gerrit. Tuttavia, poiché il modello di Gerrit include revisioni successive a un particolare commit, incoraggia i flussi di lavoro di Git a cui molti sviluppatori non sono abituati, come la modifica di un commit precedente e la sua re-push o la compressione di una serie crescente di commit da un ramo di argomento in un singolo commettere.

In Github, una richiesta pull modella una relazione tra due rami. Il flusso di lavoro previsto su Github è di eseguire il commit di una o più modifiche in un ramo argomento (spesso in un fork del repository, ma non necessariamente) e creare una richiesta pull tra quel ramo e il ramo "upstream". In questo caso, ciò che viene esaminato è un insieme di commit che continua a crescere man mano che la revisione continua. Il risultato è un insieme di modifiche che possono essere unite atomicamente al termine. Le richieste pull possono essere efficaci nel tenere traccia delle modifiche con un ambito più ampio che può essere implementato su più commit. Le richieste pull supportano anche i flussi di lavoro SCM a cui sono abituati più sviluppatori, come rispondere a un commento di revisione inviando un commit di follow-up nello stesso ramo.

Un grande vantaggio a favore di Github è il numero di sviluppatori che lo conoscono rispetto a Gerrit. Gerrit può essere popolare tra gli utenti esperti di Git, ma l'uso senza attrito richiede conoscenze di git intermedie o avanzate e la tolleranza di una curva di apprendimento ripida.

Il vantaggio di Gerrit è una relazione più profonda con Git. Le richieste pull di Github sono rimosse abbastanza lontano dal modello di dati standard di Git che è necessario utilizzare l'interfaccia utente Web di Github o la sua API proprietaria per creare richieste pull. L'interfaccia di Gerrit per la creazione e l'aggiornamento delle modifiche è lo stesso protocollo git.


8
Grazie Martin, questa è una risposta interessante. Ho intenzione di guardare Gerrit per un po ', ma penso che lo accantonerò. Se incoraggia la modifica della cronologia e gli impegni di compressione, non voglio farci nulla. * 8 '(
Mark Booth,

15
Giusto per essere chiari (uso spesso Gerrit sul mio posto di lavoro), ciò che Martin dice qui, "Gerrit ... incoraggia i flussi di lavoro di Git ... come la modifica di un commit precedente e la sua ripetizione, o la compressione di una serie crescente di commit. ..in un unico commit "è esattamente corretto. Il mio chiarimento è che il commento di @ MarkBooth sulla "cronologia delle modifiche" non è quello che ha detto Martin. La modifica degli commit (mentre si è ancora su Gerrit e non ancora unita a origin / master) non comporta "la cronologia delle modifiche". In effetti, questo flusso di lavoro funziona alla grande. La "cattiva" modifica della storia a cui Mark Booth fa riferimento sta spingendo nuovamente le storie modificate su origin / master.
likethesky,

2
Grazie per il chiarimento @likethesky ma ho un'interpretazione piuttosto più letterale della "cronologia delle modifiche" e, per quanto mi riguarda, tutto ciò che si traduce in cambiamenti che contengono contenuti che non hai commesso esplicitamente è "cronologia delle modifiche". Mi rendo conto però che questa è un'interpretazione piuttosto draconiana e una che pochi altri aderiscono. * 8 ')
Mark Booth,

2
Giusto. :-) Non sono sicuro di aver capito cosa intendi per "changeset che contengono contenuti che non hai commesso esplicitamente", quindi per favore. elaboro ... Presumo che stai non dicendo che mai e poi mai commettere temporanea (locale, o condiviso tra i membri del team tramite filiali remote) commette come, "WIP: questo tenta di risolvere il problema arco abbiamo discusso", seguito da un più utile schiaccia / modifica che dice "Problema 123: refactored XYZ per aumentare la resilienza e la facilità di ridimensionamento orizzontale" come messaggio di commit finale per quel lavoro. Ma comunque, ovviamente puoi scegliere di usare git in qualsiasi modo ti renda felice!
likethesky,

7
Questa è una risposta fantastica Per aggiungere, ho scoperto che le richieste pull di GitHub promuovono commit più piccoli e più iterativi e spesso finiscono con un log git molto più descrittivo che mostra non solo il prodotto di lavoro ma il processo di lavoro. La revisione del codice di Gerrit promuove una cronologia dei repository molto più pulita (ci sono pochissimi commit di unione effettivi) con commit più grandi e più accurati.
tophyr
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.