Philip Withnall
philip.withnall@collabora.co.uk 2015
Control de versiones de código con git
Daniel Mustieles
daniel.mustieles@gmail.com 2016-2020
Javier Mazorra
mazi.debian@gmail.com 2016, 2020

# Control de versiones

#

        Resumen

        git se utiliza como control de versiones para todos los proyecto de GNOME. Esta página asume un buen conocimiento de trabajo con git; algunos materiales introductorios están disponiblesaquí, y aquí hay una chuleta de git.

          Haga commits atómicos y reversibles. ()
          Incluya un razonamiento completo en los mensajes de commit, así como enlaces a los informes de error o a la especificaciones. (Consulte la sección )
          Haga los cambios grandes, como los renombrados, en commits separados. (Consulte la sección )
          Fusione los cambios de las ramas de características haciendo rebase.  ()

# Uso de Git

La mayoría de los repositorios de GNOME siguen estas reglas:

No fuerce los envíos. Excepto para las rama con el prefijo `wip` (work-in-progress), el historial de commit no debe modificarse, ya que los colaboradores confían en él.

Rebase los commits en lugar de mezclarlos, para tener un histórico lineal (más fácil de seguir).

Trabaje en ramas de características en GNOME git en ramas `git`, después haga rebase en master y fusione rápidamente los cambios. Es una buena práctica añadir también su apodo al nombre de la rama, como `wip/apodo/feature`.

Ocultar elaboración de salchichas juntando los commits antes de fusionarlos.

# Guía para realizar commits

Los commits deben ser tan pequeños como sea posible, pero no más pequeños. Cada commit debe abordar un único problema, conteniendo solo cambios relacionados con ese problema. El mensaje para cada commit debe describir el problema, explicar qué lo causa y explicar cómo se ha corregido si no es obvio. Si el commit está asociado con un informe de error la URI completa del informe de error debe ponerse en una línea separada en la parte inferior del mensaje del commit. De la misma forma, el ID para el git commit (de git log —oneline) debe copiarse en el informe de error una vez se haya enviado el commit, para que sea fácil encontrar uno desde el otro.

Los cambios en cada commit deben ser fáciles de leer. Por ejemplo, no deben cambiar innecesariamente el espacio en blanco o la sangría. Los cambios mecánicos grandes, como el renombrado de un archivo o una función, deben ponerse en commits separados de las modificaciones en el código dentro de ese archivo o función, para que los últimos cambios no queden enterrados y se pierdan en el primero.

Los siguientes principios dan el razonamiento para todos los consejos anteriores:

Cada commit debe llevar el repositorio de un estado de trabajo a otro, de lo contrario la búsqueda binaria es imposible.

Cada commit debe ser reversible individualmente. Si después resulta que el commit fue una mala idea, git revert commit ID debe llevar el repositorio de un estado de trabajo a otro estado de trabajo.

El razonamiento de cada commit y su relación con recursos externos, como especificaciones e informe de errores, deben ser claros, de manera que esos commits escritos por un desarrollador un año atrás aún deben ser comprensibles por un segundo desarrollador sin tener que rastrear los cambios y averiguar lo que hacen.

Cada commit debe escribirse una vez y diseñarse para ser leído muchas veces por muchos revisores y futuros programadores.

# Procedimiento de fusión

Para fusionar una rama de característica llamada `my-branch` en master, utilice los siguientes comandos:

git checkout master git pull

git checkout wip/my-branch git rebase --interactive master # Ensure the rebase is successful; test the changes

git checkout master git merge wip/my-branch git push

# wip/my-branch can now be deleted git push origin :wip/my-branch git branch -D wip/my-branch

# Enlaces externos

Buenas prácticas de Git

P+F de Git

Tutorial de Atlassian sobre git

Tutorial oficial de git

Tutorial interactivo de git

Tutorial de git-tower