Initial commit

README.md

@@ -0,0 +1,48 @@
+# Git Branching Model
+## Introducción
+
+## El repositorio central
+
+## Ramas Principales
+El repositorio central contiene dos ramas principales con una duración infinita:
+
+- `master`
+- `develop`
+
+Consideramos la rama `origin/master` como la rama principal, en donde el código fuente del `HEAD` siempre refleja un estado listo para producción.
+
+Consideramos que la rama `origin/develop` es la rama principal don de el código fuente de `HEAD` siempre refleja un estado con los últimos cambios de desarrollo entregados para la próxima versión. Algunos lo llamarían la "rama de integración" ("integration branch"). Aquí es donde se compilan los realeases "nightly builds".
+
+Cuando el código fuente en `develop`alcanza un estado estable y esta listo para ser desplegado, todos los cambios deben ser de alguna forma unificados en `master` y tageados con un número de realease.
+
+Por lo tanto, cada vez que hay un merge hacia `master`, esta versión es un realease de producción. En ese sentido, hay que ser bastante estrictos en que únicamente cambios testeados y sin bugs sean unidos a `master`. Se puede utilizar algún script Git hook para compilar y desplegar automáticamente a los servidores de producción cada vez que haya un commit en `master`.
+
+## Ramas de Soporte
+
+Junto a las ramas principales, `master` y  `develop`, el modelo de desarrollo utiliza una variedad de ramas de sporte para dar soporte al desarrollo paralelo entre los miembros del equipo, facil seguimiento de nuevos features, preparación para realeases o para ayudar en la correción rápida de problemas en la versión de producción. A diferencia de las ramas principales, estas tienen un tiempo de vida limitado, ya que eventualmente serán eliminadas.
+
+Los diferentes tipos de ramas de soporte que se utilizan son:
+
+- ramas `features`
+- ramas `realease`
+- ramas `hotfix`
+
+Cada uno de estos tipos de ramas tienen un propósito específico y estan sujetas a diferentes reglas, como de que rama se desprenden y hacia que ramas son unidas nuevamente.
+
+### Ramas `feature`
+
+Pueden ramificarse de: `develop`
+
+Deben hacer merge con: `develop`
+
+Nombre: debe iniciar con `feature_*` no puede ser llamada `master, develop, release_*` o `hotfix_*`
+
+Estas ramas se utilizan para desarrollar nuevas características para la próxima versión o para una futura versión. Al iniciar el desarrollo de una característica, la versión de destino en la que se incorporará esta característica puede ser descnocida en ese momento. La escencia de una rama `feature` es que existe mientras la característica esta en desarrollo, pero eventualmente se fusionará de nuevo con `develop` (para añadir definitivamente la característica al próximo lanzamiento) o se descartará (en caso de un experimento fallido).
+
+Las ramas `feature`suelen existir sólo en los repos de desarrolladores, no en `origin`.
+
+
+
+
+
+