@CodenlynDamilola Ale
El control de versiones se ha convertido en una parte importante del proceso de desarrollo de software. El control de versiones ayuda a registrar los cambios en un proyecto a lo largo del tiempo para poder recordar versiones específicas más adelante. Voy a hablar de GitHub.
Cuando empecé como desarrollador, empecé a usar GitHub porque todo el mundo decía que era necesario que los desarrolladores tuvieran su código online. Con eso en mente, lo vi como un lugar para almacenar todos mis proyectos en caso de que mi sistema se caiga, sería capaz de descargarlos de nuevo.
¿Curioso no?
Más tarde, me di cuenta de que GitHub era más que eso, es un lugar donde podía ver todo el progreso que he hecho en cada paso de la construcción de mi proyecto o software. También es un lugar donde todo el mundo puede contribuir a los proyectos con diferentes ideas.
Alrededor de mediados de año, empecé en Microverse, me presentaron a GitHub Flow. GitHub Flow te anima a crear ramas de características para cada característica de tu software. Cuando crees que tu software o proyecto está listo para ser visto o utilizado, creas un pull request y lo fusionas a la rama maestra.
¿Cool right?
clone the projecten tu repositorio local.
cden el repositorio
comprueba la rama en la que estás actualmente
Crea una nueva
feature branch
Comienza a trabajar en tu característica y cuando termines,
add,
commity
pusha la rama de la función
Ve a tu repositorio remoto en GitHub y crea un pull request y haz un merge cuando creas que la característica está completada
De esta manera consigues ver todas las características que has creado y lo que has añadido en cada fase. A medida que avanzaba, me di cuenta de que la rama maestra era principalmente para producción y en el momento en que fusionas un pull request estás diciendo que esa característica está lista para ser usada o vista por todos.
Fue entonces cuando llegué a la conclusión de que el flujo de GitHub funciona perfectamente para proyectos pequeños, pero que pasa si tengo un proyecto con más de una característica importante y uso el flujo de GitHub, estoy diciendo indirectamente que todas las características que se fusionan a la rama maestra están listas para producción pero si lo pensamos bien, ¿lo están?
Liberar una característica para un proyecto con muchas características no tiene sentido y ahí es donde entra Git Flow. Es muy similar al flujo de GitHub pero introduce una mejor manera de trabajar con el control de versiones.
En Git Flow, creamos una rama de desarrollo y luego hacemos que la rama de desarrollo sea la rama por defecto hasta que estemos listos para la producción. De esta manera, todas las ramas de características se crean desde la rama de desarrollo y se fusionan en la rama de desarrollo cuando se completan.
Tiene sentido, ¿verdad? Ahora, sólo consigo fusionar a la rama maestra cuando creo que mi software está listo para producción con todas las características añadidas.
Después de clonar tu repositorio, crea una
developmentrama
Comprueba en qué rama estás trabajando actualmente
Trata de añadir un archivo, quizás un archivo HTML para que puedas actualizar tu repositorio remoto con la rama de desarrollo.
Vaya a su repositorio remoto en GitHub , vaya a la configuración, haz clic en ramas y haz que desarrollo sea la rama por defecto
Ahora, puedes crear ramas de características desde la rama
development, crear un pull request desde ella y fusionar a la rama
development.
Cuando todas sus características estén listas, sigue los mismos pasos anteriores, vuelve a hacer master por defecto, crea un pull request de desarrollo a master y fusiona para producción.
Sé que ha sido una lectura larga, pero confío en que a estas alturas deberíamos saber cuándo usar GitHub flow o Git Flow.
Gracias por leer.
Etiquetas
Crea tu cuenta gratuita para desbloquear tu experiencia de lectura personalizada.