5. 2012 - WordPress Software de Control de Versiones
html {
font-size: 100%;
scroll-behavior: smooth;
}
body {
background-image: url("src/img/background.svg");
background-repeat: no-repeat;
background-attachment: fixed;
color: $font-color-default;
font-family: $font-stack-sans-serif;
min-height: 100vh;
}
h1, h2, h3, h4, h5,h6 {
font-family: $font-stack-sans-serif;
}
style.scss
Mauricio
Mariano
6. ★ Software de Control de Versiones
★ Software libre y gratuito
★ Se instala en tu computadora o
servidor
★ Software de Control de Versiones
★ Servicio gratis o de pago
★ Copia local y en la nube
7. Muchas herramientas pero
NO fija una metodología de trabajo
¿Por qué GitFlow?
★ Branches
★ clone, commit, stash, revert
★ push, pull, tag, checkout
★ status, reset
9. Vicent Driessen
★ Holandés, Ingeniero de Software
★ Presentó el GitFlow en 2010
★ Después de 10 años se sigue utilizando
★ Una metodología muy simple y práctica
14. Ramas de Features - GitFlow
María
Frontend
María se encargará de crear la hoja de estilo de la Web
feature/create-stylesheet
Mauricio
Backend
Mauricio se encargará de crear la estructura básica de ficheros
feature/website-scaffold
15. Ramas de Features - GitFlow
María
Frontend
git checkout develop
git checkout -b feature/create-stylesheet
Mauricio
Backend
git checkout develop
git checkout -b feature/website-scaffold
17. Funciones de Merge - GitFlow
María
Frontend
María aún le quedan dos días de trabajo para finalizar
feature/create-stylesheet
Mauricio
Backend
Mauricio ya terminó y va a subir sus cambios
feature/website-scaffold
20. Funciones de Merge - GitFlow
María
Frontend
Cuando María termine, tendrá que hacer primero un pull para
traer todos los cambios realizados por Mauricio.
Git le dará un error si intenta fusionar con «develop».
21. Ramas de Features - GitFlow
María
Frontend
git checkout develop
git pull
git merge -b feature/create-stylesheet
22. ★ Conjunto de nuevas funcionalidades
★ O bien en una fecha determinada
★ Lo ideal es planificar un release con
metodologías ágiles
Rama Release - GitFlow
23. Mariano determina que hay un buen número de funcionalidades
y decide crear una nueva rama de release.
release/1.0.0Mariano
PM
26. ★ En esta rama se darán los últimos retoques
★ Tareas de documentación
★ Solucionar bugs
★ Otras tareas de publicación
★ Pero NUNCA nuevas funcionalidades
Rama de Release - GitFlow
28. Rama de Release - GitFlow
★ Cuando el «release» está listo, se fusiona
con la «master» y «develop»
★ Se etiqueta la publicación en la rama
«master»
★ Luego se elimina la rama «release»
29. Mariano termina todas las tareas del «release/1.0.0»
Fusionará en «master» con una etiqueta
Fusionará en «develop»
Borrará la rama «release/1.0.0»
Mariano
PM
32. Mariano reenvía el email a Mauricio y autoriza a implementar
un «hotfix»
Mariano
PM
Mauricio
Backend
Mauricio crea una rama «hotfix» y comienza a desarrollar
la solucón del bug
hotfix/contact-is-not-working
35. Rama «hotfix» - GitFlow
★ Es la única rama que se crea directamente de «master»
★ Una vez resuelto, se fusiona en «master» y «develop»
★ «master» se etiqueta con un número de versión
★ Se elimina la rama «hotfix»
37. Las 7 reglas del GitFlow
★ Se crea una rama «develop» a partir de «master»
★ Las ramas «feature» se crean a partir de «develop»
★ Cuando el «feature» está listo se fusiona solo en «develop»
★ Una rama «release» se crea a partir de la «develop»
★ Cuando la rama «release» está lista, se fusiona en «master» y «develop»
★ Si hay una incidencia grave en producción, se crea una rama «hotfix» a partir
de «master»
★ Una vez resuelta, se fusiona el «hotfix» en «develop» y «master»
38. Por qué usar GitFlow
★ Es una metodología probada y utilizada por más de 10 años
★ Mayor independencia entre los equipos de desarrolladores
★ Podemos hibernar una funcionalidad y continuar con otra de mayor
prioridad.
★ Se tiene un mejor control de los entregables
★ Se pueden aplicar cambios ante posibles fallos graves (amén !)
39. Cuando utilizar GitFlow
★ El equipo de trabajo está conformado por más de dos personas
★ Se emplean metodologías ágiles
★ El proyecto tiene cambios frecuentes pero se quiere tener control
del proyecto
★ El proyecto tiene un nivel de complejidad considerable
★ Se desea tener un proceso de soporte a errores efectivo con
actualizaciones rápidas