Sviluppo/gerrit
TDF LibreOffice Document Liberation Project Blog comunitari Weblate Nextcloud Redmine Ask LibreOffice Donazione
Questa è la pagina introduttiva allo strumento di revisione del codice gerrit.libreoffice.org ed a come usarlo per LibreOffice.
Preparatevi per l'utilizzo di Gerrit
Vedete Preparatevi per l'utilizzo di gerrit.
L'alternativa è quella di trafficare con un approccio manuale, dettagli al riguardo si possono trovare in Preparatevi per l'utilizzo di gerrit - il metodo manuale.
Inviare una Patch a Gerrit
Vedete Inviare una patch per la revisione su gerrit.
Nell'articolo Inviare una patch per la revisione su gerrit troverete trattati degli argomenti come:
- inviare una nuova versione
- inviare delle patch in bozza
Nell'articolo Submodules troverete la trattazione di come inviare delle patch per i moduli come:
- dictionaries
- helpcontent2 (per i file di aiuto)
- translations
Confronto del flusso di lavoro su Gerrit rispetto a GitHub/GitLab
Il flusso di lavoro per le patch su Gerrit è semplice come quello delle richieste di pull/merge su GitHub/GitLab, ha solamente un approccio differente. Con le richieste di pull/merge di GitHub/GitLab, lavorate in una branca e le modifiche che apportate appariranno come una serie di commit. Con una patch di Gerrit, continuerete a correggere un singolo commit e le vostre modifiche appariranno come una serie di gruppi di patch. Oltre a ciò, per i progetti più grandi è possibile creare una serie di patch che dipendono le une dalle altre (modifiche collegate) o anche creare branche separate di funzionalità.
Nella documentazione di Gerrit c'è un introduzione a Gerrit per utenti di Github Basic Gerrit walkthrough for GitHub users.
Gregory Szorc ha scritto un saggio sui problemi della gestione della patch di GitHub/GitLab. Parla anche di Gerrit:
Un'eccezione interessante è Gerrit, che riceve le sue richieste di integrazione tramite git push. Ma il modo in cui Gerrit riceve tramite git push funziona in modo fondamentalmente diverso da come funzionano le richieste di pull! Con le richieste di pull, fate il push della branch locale a una branch remota e la richiesta di pull è costruita su quella branch remota. Con Gerrit, il comando push è simile a git push gerrit HEAD:refs/for/master. Per i non-guru, la sintassi HEAD:refs/for/master significa, fai il commit dell'HEAD (in effetti il commit corrispondente alla directory di lavoro) su refs/for/master ref sull'istanza remota di gerrit (la sintassi SOURCE:DEST specifica la mappatura di un identificativo della revisione locale a un ref remoto). La magia dietro le quinte in questo caso è che Gerrit esegue un server Git speciale che implementa un comportamento non standard per i ref refs/for/*. Quando eseguite il push a refs/for/master, Gerrit riceve il push di Git come farebbe un normale server Git. Ma invece di scrivere un ref denominato refs/for/master, prende i commit in arrivo e li inserisce in una richiesta di revisione del codice! Gerrit creerà dei ref di Git per i commit di cui viene fatto il push. Principalmente fa questo per la sua tracciabilità interna (Gerrit memorizza tutti i suoi dati in Git - dai dati di Git ai commenti delle revisioni). E se credete che questa funzionalità sia troppo magica, potete anche passare a Gerrit dei parametri tramite il nome del ref! Per es. git push gerrit HEAD refs/for/master%private creerà una richiesta privata di revisione che richiede dei permessi speciali per essere visualizzata. (È discutibile se sovraccaricare il nome del ref di funzionalità aggiuntive renda buona l'esperienza dell'utente medio. Ma non potete sostenere che questo non sia un bel hack!)
Ulteriori informazioni su Gerrit
- vedete Development/gerrit/PatchReview che spiega come eseguire al revisione delle patch su gerrit
- Dividere una Patch dopo averla caricata su gerrit
- Development/gerrit/CommonQueries
- Avete una domanda? Prima di chiedere sulla mailing list di sviluppo consultate le Domande frequenti su gerrit. Potete anche dare un'occhiata alla documentazione ufficiale di gerrit.