RSS
Atom
Seguir a @SL_Informatica
(Página creada con «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 fu...») |
(→Git-Flow) |
||
| Línea 20: | Línea 20: | ||
===Git-Flow=== | ===Git-Flow=== | ||
| − | Esta metodología propone usar un branch develop en la cual se hace merge. | + | 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 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 | + | 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 | + | 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. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
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 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.