Development/gerrit/da
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Dette er indgangsiden til koderevisionsværktøjet gerrit.libreoffice.org og hvordan det bruges i LibreOffice.
Gør dig klar til Gerrit
Alternativet er at pille løs med en hånddrevet tilgang, som du finder enkeltheder til på Gør dig klar til Gerrit - hånddrevet.
Indsendelse af en patch (lap) til Gerrit
Se Indsend et patch (en lap) til gennemsyn med Gerrit.
I artiklen Indsend et patch (en lap) til gennemsyn med Gerrit finder du en behandling af emner som disse:
- indsendelse af en ny version
- indsendelse af patches som kladder
I artiklen Undermoduler finder du en behandling af indsendelse af patches til undermoduler som
- ordbøger
- helpcontent2 (til hjælpefiler)
- oversættelser
Gerrit arbejdsgang sammenlignet med GitHub/GitLab
Arbejdsgangen med Gerrit programrettelse er lige så enkel som GitHub/GitLab pull/merge-anmodninger, der kun har en anden tilgang. Med GitHub/GitLab PR'er/MR'er arbejder du i en filial, og dine yderligere ændringer vises som en række indsendelser. Med en Gerrit-progamrettelse bliver du ved med at ændre en enkelt indsendelse, og dine ændringer vises som en række programrettelse-sæt. Ud over dette er det for større projekter muligt at oprette en række programrettelse, der afhænger af hinanden (Relaterede ændringer) eller endda at oprette fjernfunktionsgrene.
Gerrit-dokumentationen har en Grundlæggende Gerrit-gennemgang for GitHub-brugere.
Gregory Szorc har skrevet et essay om problemerne med GitHub/GitLab programrettelse model. Det berører også Gerrit:
En interessant afviger er Gerrit, som indtager sine integrationsanmodninger via git push. Men måden Gerrits indtagelse via git push fungerer på er fundamentalt forskellig fra hvordan pull-anmodninger fungerer! Med pull-anmodninger skubber du din lokale filial til en ekstern filial, og en pull-anmodning er bygget op omkring den eksterne filial. Med Gerrit er din push-kommando ligesom git push gerrit HEAD:refs/for/master. For ikke-guruer, som HEAD:refs/for/master syntaks betyder, skal du skubbe HEAD commit (effektivt commit svarende til arbejdsbiblioteket) til refs/for/master ref på gerrit fjernbetjeningen (SOURCE:DEST syntaksen specificerer en kortlægning af lokal revisions-id til ekstern ref). Guiden bag gardinet her er, at Gerrit kører en speciel Git-server, der implementerer ikke-standard adfærd for refs/for/* refs. Når du trykker til refs/for/master, modtager Gerrit dit Git-push som en normal Git-server ville. Men i stedet for at skrive en ref ved navn refs/for/master, tager den de indkommende commits og indtager dem i en kodegennemgangsanmodning! Gerrit vil oprette Git refs for de pushede commits. Men det gør den primært for sin interne sporing (Gerrit gemmer alle sine data i Git - fra Git-data til anmeldelser af kommentarer). Og hvis den funktionalitet ikke er for magisk for dig, kan du også sende parametre til Gerrit via ref-navnet! f.eks. git push gerrit HEAD refs/for/master%private vil oprette en privat anmeldelsesanmodning, der kræver særlige tilladelser for at se. (Det kan diskuteres, om overbelastning af ref-navnet for yderligere funktionalitet er en god brugeroplevelse for gennemsnitlige brugere. Men du kan ikke argumentere for, at dette ikke er et fedt hack!)
Mere om Gerrit
- se Development/gerrit/PatchReview om hvordan patches gennemses i gerrit
- Opdel patch efter det blev uploaded til gerrit
- Development/gerrit/CommonQueries
- Har du et spørgsmål? Se først gerrit FAQ eller spørg på Developments mail-liste. Du kan også kaste et blik i den officielle gerrit dokumentation.