Jump to content

Desarrollo/Git para programadores de LibreOffice

From The Document Foundation Wiki
This page is a translated version of the page Development/Git For LibreOffice Developers and the translation is 100% complete.

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.

Aviso:
¡Esto solo debe hacerse en confirmaciones que aún no se han enviado a la rama master o a una rama de lanzamiento!


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

Nota:
Si tiene la intención de enviar el commit a gerrit, la línea ChangeId es crucial: gerrit la usa para encontrar un parche existente que se actualizará con una nueva revisión. Así que asegúrese de tomar la línea ChangeId del commit adecuado (generalmente la que cargó en Gerrit antes), no la edite. y elimine la línea ChangeId del commit menos importante de la que desea deshacerse.

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: