RSS
Atom
Seguir a @SL_Informatica
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
Para tener un branch master que sea lo suficientemente estable se adoptan 2 metodologías.
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.
Esta metodología propone usar un branch develop en la cual se hace merge.
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).
Después de mergear un release-branch con develop, se mergea develop 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, si bien se debe hacer testing antes de mergear algo con develop, es más aceptable que haya algo inestable en develop que en master.
feature branches y release branches para hacer los cambios experimentales que pueden hacer que el sistema no funcione.