🚀El flujo de GitHub es un flujo de trabajo diseñado para funcionar bien con Git y GitHub.
👀 Se centra en la ramificación y hace posible que los equipos experimenten libremente y realicen implementaciones con regularidad.
El flujo de GitHub funciona así:
Ahora veamos el desarrollo de cada punto mencionado
La ramificación es el concepto clave de Git. Y funciona en torno a la regla de que la rama maestra (main) SIEMPRE se puede implementar.
Eso significa que, si quieres probar algo nuevo o experimentar, ¡Debes crear una nueva rama! La ramificación le brinda un entorno en el que pueda realizar cambios sin afectar la rama principal
Cunado su rama esté lista, se puede revisar, discutir y fusionar con la rama principal cuando este lista
Cuando cree una nueva rama, querrá (casi siempre) crearla desde la rama maestra
💡 Tenga en cuenta que está trabajando con otros. Usar nombres descriptivos para las nuevas ramas, para que todos puedan entender lo que está sucediendo
Después de crear la nueva rama, es hora de ponerse trabajar. Realice cambios agregando, editando y eliminando archivos. Cada vez que alcance un hito pequeño, agrege los cambios a su rama mediante commits.
Agregar commits realizar un seguimiento de su trabajo. Cada commit debe tener un mensaje que explique qué ha cambiado y por qué. Cada commit se convierte en parte del historial de la rama y en un punto al que puede volver si lo necesita.
💡 ¡Los mensajes de los commits son muy importantes! Que todos sepan qué ha cambiado y por qué. Los mensajes y comentarios que sea mucho más facil para usted y otras personas realizar un seguimiento de los cambios
Los pull requests son una parte clave de GitHub. Una solicitud de extracción (pull request) notifica a las personas que tienen cambios listos para que los consideren o revisen.
Puede pedir a otros que revisen sus cambios o extraer su contribución y fusionarla con su rama
Cuando se realiza una solicitud de extracción (pull request), puede ser revisada por quien tenga el acceso adecuado a la rama. Aquí es donde ocurren las buenas discusiones y la revisión de los cambios.
¡Los pull request están diseñadas para permitir que las personas trabajen juntas facilmente y produzcan mejores resultados juntas!
Si recibe comentarios y continua mejorando sus cambios, puede impulsar sus cambios con nuevos commits, lo que hace posible mas confirmaciones.
💡 GitHub muestra un nuevo commit y comentario en la “unifield Pull Request view”
Cuando se ha revisado el pull request y todo se ve bien, es hora de la prueba final. GitHub le permite implementar desde una rama para la prueba final en producción antes de fusionarse con la rama principal.
Si surge algún problema, puede deshacer los cambios implementando la rama maestra en producción nuevamente
💡 Los equipos a menudo tienen entorno de prueba dedicados que se usan para implementar ramas
¡Después de pruebas exhaustivas, puede fusionar el código en la rama maestra!
Los pull requests mantienen registros de los cambios en su código, y si comentó y nombró bien los cambios, puede volver atrás y comprender por qué se realizo los cambios y las decisiones.
💡 ¡Puede agregar palabras clave a su pull request pra facilitar la búsqueda!
Excelente gracias por el aporte me gusta mucho este flujo de trabajo es el que yo uso actualmente. Mas sin embargo quiero aportar un algo. Cuando se nos presenta la situacion de trabajar un proyecto solos hay que seguir todos los pasos que se mencionan en este post excepto el de realizar los pull request. OJO ES UN CONSEJO PARA CUANDO TRABAJEMOS SOLOS EN UN PROYECTO.
Un muy buen tutorial, es una guía que siempre hay que leer, seguir estos pasos es muy importante.
Saludos
¡Gracias por el aporte!
Antes, era muy desorganizado, y el código se volvía un desastre en el main/master. Ahora todo es mejor desde que sigo estos pasos.
👍