GitHub para programadores

Generando hotfixes y features

Prueba ahora LinkedIn Learning sin cargo y sin compromiso.

Prueba gratis Mostrar modalidades de suscripción
Los hotfixes y features son elementos cruciales para generar un flujo de trabajo profesional. Aprenderás a generar un flujo de cambios entre un servidor de producción y uno de pruebas.
08:16

Transcripción

Una de las capacidades más interesantes que tiene SourceTree es que nos permite implementar flujos de trabajo. Posiblemente ya trabajes así, y si no te recomiendo que comiences a considerarlo. Es el concepto de trabajar con múltiples servidores a la hora de presentar un proyecto. Vamos a tener un servidor público, o de producción, donde los usuarios van a poder entrar y van a revisar nuestra aplicación. en este caso nosotros siempre tenemos que tener un código absolutamente estable y de la mejor calidad posible para que no tengamos errores. Luego vamos a tener otro servidor, que va a ser el servidor de pruebas o "staging". Ahí es donde los desarrolladores vamos a ir depositando los cambios que vayamos haciendo dentro del código, y los encargados del control de calidad van a ir revisando y asegurándose de que todo está listo. Una vez que todo esté listo, pueden publicar dentro del servidor público. De esta forma mantenemos un proceso que nos asegura la calidad y que las personas, cuando utilicen nuestra aplicación, no van a tener errores, y nosotros garantizamos también que no vamos a tener problemas inesperados. SourceTree nos permite mantener este flujo de trabajo de una forma muy simple. Vamos a buscar la opción Git Flow. Voy a hacer clic en ella y me va a permitir a mí generar una rama de producción y una rama de desarrollo. Vamos a poder crear diferentes flujos y, por ejemplo, vamos a poder crear "features", "hot fixes" y "releases". en este caso vamos a utilizar los "features" y los "hot fixes". Voy a poner OK y esto es lo que va a hacer es que va a generar una nueva rama. en este caso se llama 'develop', pero se puede llamar como tú te sientas más cómodo. Puede llamarse 'desarrollo' o 'servidor de pruebas'. en este caso toda la información que esté dentro de la rama 'develop', en teoría, debería ser la información que se va a desplegar dentro del servidor de pruebas, y 'master' va a ser la información que se despliega dentro del servidor público. Así todos los desarrolladores podemos ir trabajando en 'develop' y cuando algún desarrollador –por ejemplo, el encargado del proyecto– decida que en 'develop' tenemos una buena versión estable, hace un "merge" o une ambos repositorios y podemos publicar. Ahora, durante el flujo de trabajo, por ejemplo, si nosotros queremos agregar una nueva capacidad dentro de 'develop', o sea, en el servidor de pruebas, entonces vamos a crear lo que se llama un "feature" o una nueva característica. Vamos a hacer clic en Git Flow y luego a hacer clic en Iniciar una nueva característica. Vamos a ponerle el nombre en este caso como 'boton', supongamos que vamos a agregar un nuevo botón, y vemos que al hacer clic se va a generar una carpeta qué dice 'feature' y generó un "branch" o rama de nuestro repositorio con el nombre 'boton'. Ahora ya sabemos que acá va a incluirse un botón. Yo hago clic sobre esta rama y, como podemos notar, al estar dentro de un "branch" específico va a parecer en negrita. Esto significa estamos trabajando dentro de esta versión de código. Yo voy a abrir el código –en este caso estoy en Brackets–, voy a entrar acá a 'index' y le voy a agregar esta nueva característica, que va a ser un botón. Perfecto, ya tenemos el botón, está listo. Vamos a guardar. Volvemos otra vez a SourceTree y ya nos aparece, tenemos un cambio y lo podemos enviar. OK, vamos a enviar este cambio, lo vamos a guardar dentro de nuestro repositorio local. Incluso lo puedo guardar a específicamente este repositorio en su versión en línea en caso de que esté trabajando con GitHub. Y vamos a poner 'nuevo botón'. Anotar. Listo, ya entonces tenemos esta nueva característica. Ahora yo quiero unir este código. Supongamos que ya terminé el trabajo que quería hacer y yo quiero que se una esta nueva característica a la rama principal del servidor de pruebas. Entonces, lo que voy a hacer es que vuelvo otra vez a Git Flow. en este caso tengo que presionar sobre el "branch" en el que me encuentro, 'boton', sería la capacidad que quiero agregar, hago clic en Git Flow y le pongo Finalizar actual. Esto lo que va a hacer es un "merge" o una unión entre las ramas, y vemos que la información que estaba dentro de ese botón ahora se encuentra dentro del servidor de pruebas y ha desaparecido el "branch". Una vez que yo ya me siento cómodo con los cambios, lo desaparece para que no tengamos que estar cargando con una gran cantidad de "branches" que no vamos a estar usando. Listo, ahora simplemente tengo que hacer un "push" de la información y ya está disponible dentro de la rama 'develop' de mi repositorio toda la información que yo acabo de agregar. Ahora, puede haber un caso especial en el que encontremos un error dentro del servidor principal y necesitamos hacer un cambio rápido. Esto es lo que se llama un "hot fix". Supongamos que, por ejemplo, se nos escapó un texto, se escapó de control de calidad, y la gente dentro del servidor público está viendo ese error. ¿Cómo lo arreglamos? Bueno, sencillo. Vamos a entrar de nuevo, vamos a entrar en este caso a 'master', hacemos clic en Git Flow y vamos a agregar una nueva revisión. Esto es lo que se llama un "hot fix". OK, vamos entonces a poner acá 'arreglo'. Bueno, acá no se pueden poner tildes. 'Arreglo_rapido'. Listo. Ahora tenemos otro "branch" que se llama 'arreglo_rapido'. Vamos a trabajar sobre este "branch". Recordemos que tiene que estar en negrita para saber que estamos trabajando ahí. Revisamos si suponemos que tenemos que hacer un cambio dentro de este 'master', y le ponemos acá un cambio que sea desde mi web. Listo. Eliminamos un texto que había que modificarse o le ponemos acá a este título un 'class'. Supongamos que con eso se arregla el error que nosotros teníamos. Listo, ahora que ya tenemos arreglado este problema, sabemos que funciona bien, ya lo probamos, estamos listos para enviarlo a 'master' directamente, entramos acá a Git Flow y pondremos Finalizar actual. Cerramos la información. Acá me aparece un error. Perdón. Me aparece un error porque no he hecho un "commit" de los cambios. Vamos a hacerlo rápidamente. Hacemos un "commit" de los cambios, ponemos 'nueva clase'. Listo. Y, ahora sí, una vez que tenemos guardado los cambios, volvemos a presionar Finalizar actual. Y, listo, ahora la información que acabamos de poner dentro de una "hot fix" acaba de irse directamente al servidor 'master', pero también se acaba de actualizar dentro del servidor de pruebas, así que ahora tanto la versión de prueba como la versión pública tienen ese cambio. Esa es la diferencia entre un "feature" y un "hot fix": el "feature" va a parecer únicamente dentro del servidor de pruebas, y el "hot fix" va a aparecer dentro del 'master', dentro del principal y también dentro del servidor de pruebas. Así podemos generar un flujo de trabajo profesional.

GitHub para programadores

Aprende conceptos de GitHub como crear, gestionar y examinar nuestros repositorios online. Descubre las funciones más comunes y el servicio que te ofrece GitHub.

1:53 horas (26 Videos)
Actualmente no hay comentarios.

Este curso video2brain está disponible como descarga y para ser visualizado online. ¡Pero no hace falta que decidas entre las dos opciones! Al comprar el curso, disfrutarás de ambas posibilidades.

La descarga te permite ver las lecciones sin estar conectado/a a internet y supone una navegación fácil y ágil entre capítulo y capítulo. Si vas a trabajar en diferentes ordenadores o si no quieres descargarte el curso completo, entra en la web con tus datos de acceso y disfruta directamente de tus vídeos online. Te deseamos que disfrutes de este curso y te resulte de mucha utilidad.

Estamos a tu disposición si tienes cualquier tipo de duda o pregunta.