Desarrollo/Git para programadores de LibreOffice
TDF LibreOffice Document Liberation Project Blogs comunitarios Weblate Nextcloud Redmine Ask LibreOffice Donar
El código fuente de LibreOffice utiliza el sistema de control de versiones Git (VCS). La mayor parte se encuentra en el repositorio core, pero algunos módulos se encuentran en repositorios separados, translations, help y dictionaries. En la mayoría de los casos probablemente no tendrás que modificar estos repositorios.
Introducción
Git es un sistema de VCS distribuido. Es un sistema muy potente, pero si no está familiarizado con los VCS distribuidos, puede resultar confuso. Afortunadamente, existen excelentes recursos en la web para aprender sobre Git. Si no está familiarizado con él, debe visitar los enlaces:
- Pro Git (de Scott Chacon y Ben Straub)
- Git For Ages 4 And Up, una presentación de 100 minutos del 2013 para una explicación fácil y visual (en Inglés)
El resto de este artículo asumirá que tiene un conocimiento básico de Git.
Administrar ramas de Git
- Consulte: Development/Branches
Un consejo para mostrar la rama en el prompt del terminal (Linux)
Es posible mostrar la rama en la que está trabajando con un estilo similar a:
~/git/core/helpcontent2 (master)$
Para lograr esto, debe modificar la variable del prompt PS1 agregando lo siguiente a su archivo $HOME/.bashrc:
source /usr/share/git/completion/git-prompt.sh # Nota: la ubicación exacta de este archivo puede variar según su sistema. En sistemas basados en Debian, puede comprobar la ubicación con: dpkg -L git | grep prompt
export PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \W\[\033[31m\]$(__git_ps1 " (%s)")\[\033[01;34m\]$\[\033[00m\] '
Otra ayuda visual para el terminal es: delta, que proporciona resaltado de sintaxis para las salida de git, diff y grep.
Hackear y hacer un commit en una rama estable
Las ramas estables se crean a partir de la rama master u otra rama estable para estabilizar el código base para la versión y futuras actualizaciones de mantenimiento. Existen algunas reglas durante la fase beta:
- Se permiten cambios en las traducciones.
- Se permiten correcciones de errores.
- Se permite incorporar últimas funciones aprobadas por el Comité de desarrollo
Hay reglas más estrictas durante la fase de versión candidata:
- Se permiten correcciones seguras que son revisadas por otra persona.
- Se permiten cambios en las traducciones; se recomienda solicitar revisión en la lista de correo nativa de l10n
Por favor, no haga commit de las correcciones directamente durante la fase RC. En su lugar, envíe su parche a gerrit o solicite la revisión de otro desarrollador en la lista de correo libreoffice@lists.freedesktop.org, correo personal, IRC o mediante el número de bug relacionado. El revisor debe confirmar la corrección mediante:
git commit -s --author='Author name <author@mail.address>'
Qué hacer cuando git pull -r no funciona
Generalmente se debe a cambios locales en su repositorio. Puede deshacerte de ellos usando:
git checkout -f
git pull -r
o guardarlos temporalmente y recuperarlos después de git pull -r:
git stash
git pull -r
git stash pop
Restablecer el repositorio modificado a un repositorio «vanilla»
$ git reset --hard origin/master
El comando anterior descartará todos sus cambios locales (ya sean confirmados o no) y restablecerá la rama en la que se encuentre a la del repositorio remoto.
Eliminar archivos ignorados o sin seguimiento
Para limpiar archivos basura como archivos temporales y registros antiguos y crear un directorio de trabajo impecable, use el comando
$ git clean -fdx
Mejorar la clonación de git para redes lentas
Si su red es lenta, puede clonar/checkout sólo la rama que necesita, o hacer una clonación superficial/parcial. Puede hacer esto desde el repositorio de LibreOffice en GitHub, pero recuerde agregar un remoto para el repositorio original.
Por ejemplo, la clonación desde Github con profundidad=1 es así:
git clone --depth=1 https://github.com/libreoffice/core
Luego, debe asegurarse de que el control remoto esté configurado en el repositorio original. Para hacer eso, edite el archivo .git/config, para que la sección remota sea así:
[remote "origin"]
url = git://git.libreoffice.org/core
fetch = +refs/heads/*:refs/remotes/origin/*
Para luego recuperar el historial completo, puede usar:
git fetch --unshallow
Reordenar, unificar y en general modificar su historial local: git rebase -i
git rebase -i es una poderosa herramienta que le permite "reescribir" su historial local.
Digamos que está en master y las últimas 3 confirmaciones son A,B,C=HEAD pero C es en realidad una corrección de la confirmación A que te perdió antes de confirmar B. Entonces, lo que querría hacer es fusionar A y C juntos y terminar con A',B como historial.
Para hacer eso puede usar el comando:
git branch safehead HEAD
Esto es sólo en caso de que algo salga muy mal y quiera deshacer todo y volver al estado inicial.
git rebase -i HEAD~3
Esto debería enviar a su editor favorito (establecido por la variable $EDITOR) una lista de las últimas 3 confirmaciones, desde la más antigua hasta la más nueva (el orden inverso al normal en git log), por lo que C es el último de la lista:
pick 726fe9c enable localization of extension descriptions in mysqlc pick 9ab6ecf fix en-US only build pick a18bfb0 Revert "enable localization of extension descriptions in sdext" # Rebase 1846533..a18bfb0 onto 1846533 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails # # If you remove a line here THAT COMMIT WILL BE LOST. # However, if you remove everything, the rebase will be aborted. #
Edítelo, moviendo el commit C uno arriba y cambiando su acción a squash:
pick 726fe9c enable localization of extension descriptions in mysqlc squash a18bfb0 Revert "enable localization of extension descriptions in sdext" pick 9ab6ecf fix en-US only build
Guarde y salga del editor
Ahora puede editar el mensaje de confirmación de la confirmación fusionada:
# This is a combination of 2 commits. # The first commit's message is: enable localization of extension descriptions in mysqlc Change-Id: I7141eea0fe7f72408da0d2a5ebe4a5e2891b6b7d # This is the 2nd commit message: Revert "enable localization of extension descriptions in sdext" Change-Id: Iff01d31792a13a14ea720c477417217af0c01642
Una vez que haya combinado los 2 mensajes de confirmación, guarde y salga nuevamente.
Si todo salió bien, debería estar en master con HEAD en B y A+C fusionados en un commit A', justo antes de B.
Si las cosas salieron mal y está perdido:
git rebase --abort
Si las cosas no vuelven al estado esperado (composición erronea), puede ejecutar esto para fingir que nunca pasó nada:
git reset --hard safehead
Obtener y usar el acceso de commit
Para obtener acceso de commit necesita estar "patrocinado". Una vez que haya enviado los parches y haya sido reconocido, esto no será un problema, pero es mejor esperar hasta que le soliciten o solicite que alguien lo patrocine.
Vea también
Recursos generales de Git:
- General Git Branching (para un excelente aprendizaje práctico visualizado)
- On commit messages (consjos para mejorar los mensajes de commit)
- Flight rules for Git, una guía para gitstronautas sobre qué hacer cuando algo va mal