Desarrollo/gerrit
TDF LibreOffice en español Document Liberation Project Blogs comunitarios Weblate Nextcloud Redmine Preguntas y respuestas Donar
Esta es la página de introducción a la herramienta de revisión de código gerrit.libreoffice.org y cómo usarla en LibreOffice.
Prepare Gerrit
Consulte Prepare gerrit.
La alternativa es usar una configuración manual, cuyos detalles se pueden encontrar en configuración manual.
Enviar un parcha a Gerrit
Consulte Enviar un parche a gerrit para su revisión.
En el artículo Enviar un parche a gerrit para su revisión encontrará una aproximación a:
- enviar una versión nueva
- enviar parches como borradores
En el artículo Submódulos encontrará una aproximación sobre enviar parches a submódulos como
- diccionarios
- helpcontent2 (para archivos de ayuda)
- tranducciones
El flujo de trabajo de Gerrit comparado con GitHub/GitLab
El flujo de trabajo con parches de Gerrit es tan simple como las solicitudes de extracción/fusión de GitHub/GitLab, solo que tiene un enfoque diferente. Con GitHub/GitLab PRs/MRs, trabajas en una rama y sus cambios adicionales aparecerán como una serie de confirmaciones. Con un parche de Gerrit, sigue modificando un único envío (commit) y sus cambios aparecerán como una serie de conjuntos de parches. Además de esto, para proyectos más grandes es posible crear una serie de parches que dependan unos de otros (cambios relacionados) o incluso crear ramas de funciones remotas.
Gerrit documentation has a Basic Gerrit walkthrough for GitHub users.
Gregory Szorc ha escrito un ensayo sobre los problemas con el modelo de parche
de GitHub/GitLab modelo de parche que también implica a Gerrit:
An interesting outlier is Gerrit, which ingests its integration requests via git push. But the way Gerrit's ingestion via git push works is fundamentally different from how pull requests work! With pull requests, you are pushing your local branch to a remote branch and a pull request is built around that remote branch. With Gerrit, your push command is like git push gerrit HEAD:refs/for/master. For the non-gurus, that HEAD:refs/for/master syntax means, push the HEAD commit (effectively the commit corresponding to the working directory) to the refs/for/master ref on the gerrit remote (the SOURCE:DEST syntax specifies a mapping of local revision identifier to remote ref). The wizard behind the curtain here is that Gerrit runs a special Git server that implements non-standard behavior for the refs/for/* refs. When you push to refs/for/master, Gerrit receives your Git push like a normal Git server would. But instead of writing a ref named refs/for/master, it takes the incoming commits and ingests them into a code review request! Gerrit will create Git refs for the pushed commits. But it mainly does that for its internal tracking (Gerrit stores all its data in Git - from Git data to review comments). And if that functionality isn't too magical for you, you can also pass parameters to Gerrit via the ref name! e.g. git push gerrit HEAD refs/for/master%private will create a private review request that requires special permissions to see. (It is debatable whether overloading the ref name for additional functionality is a good user experience for average users. But you can't argue that this isn't a cool hack!)
Más sobre Gerrit
consulte
- Development/gerrit/PatchReview sobre cómo realizar una revisión de parches en gerrit
- Dividir un parche después de subido a gerrit
- Development/gerrit/CommonQueries
- ¿Tiene alguna pregunta? Consulte primero las FAQ sobre gerrit o pregunte en la lista de correo de desarrollo.
También puede consultar la documentación oficial de Gerrit.