Lihuen
RSSRSS AtomAtom

Diferencia entre revisiones de «Ventajas de usar un branch develop»

(Metodologías)
Línea 1: Línea 1:
 +
El contenido de esta página debe ser entendido en el contexto de [[Workflow Git/SVN]].
 +
 
Normalmente cuando un usuario descarga un software usando Git (y especialmente en los proyectos alojados en GitHub), el usuario espera que la revisión del branch master funcione.
 
Normalmente cuando un usuario descarga un software usando Git (y especialmente en los proyectos alojados en GitHub), el usuario espera que la revisión del branch master funcione.
  

Revisión de 15:37 2 oct 2013

El contenido de esta página debe ser entendido en el contexto de Workflow Git/SVN.

Normalmente cuando un usuario descarga un software usando Git (y especialmente en los proyectos alojados en GitHub), el usuario espera que la revisión del branch master funcione.

Habitualmente si un usuario tiene que descargar un proyecto de GitHub espera seguir más o menos los siguientes pasos: git clone git@github.com:usuario/proyecto cd proyecto make make install

Metodologías

Para tener un branch master que sea lo suficientemente estable se adoptan 2 metodologías.

En ambas metodologías es altamente recomendable hacer merge de los branches periódicame con la rama de desarrollo (master en el primer caso, develop en el segundo) para evitar conflictos de versiones y aprovechar los merge automáticos.

GitHub Flow

Una de las metodologías es la recomendada por Scott Chacon (escritor del libro ProGit y desarrollador de GitHub) a la que llama GitHub Flow. Esta metodología está pensada para los sistemas que producen versiones instalables cada pocos días, donde las releases no son importantes.

En esta metodología cada desarrollador crea un branch con un nombre significativo y luego de hacer que el branch funcione de forma estable, el desarrollador hace un pull request a upstream/master.

Esta metodología depende de revisión del código por terceros (en principio que el usuario que administra upstream decida o no aceptar los cambios) y también depende fuertemente de una disciplina de testing donde antes de subir cambios cada desarrollador corre un conjunto de tests (por ejemplo tests de unidad). También se puede usar Travis-CI para que realice tests del branch master automáticamente.

Git-Flow

Esta metodología propone usar un branch develop en la cual se hace merge de los branches experimentales.

Los feature-branch y los los release-branch "nacen" a partir del branch develop y cuando se finalizan se mergean con el mismo (o se descartan), los release-branch se mergean también con master.

Después de mergear un release-branch con develop y con master y se crea un tag apuntando al tope de master con el nombre de la versión. De esta manera, en master, solamente hay versiones publicadas con nombre, por lo que se garantiza su estabilidad.

Este esquema es más adecuado para proyectos orientados a release, donde se hace una nueva versión cada varias semanas o meses y si bien es deseable que cada desarrollador testee su feature-branch antes de hacer merge con develop, en esquemas donde no siempre hay una revisión de terceros (ya que somos administradores del repositorio git y no precisamos hacer pull request) algunos bugs pueden pasar los controles, pero solamente llegan a develop y pueden solucionarse antes de llegar a master.