La diferencia entre Git y Github parte de entender quién controla y dónde se controla.
Git es un sistema a base de comandos que nos permite controlar las versiones generadas en un proyecto.
Github es el servidor donde puedes hospedar tu proyecto y a través de una interfaz web administrar las versiones generadas por git.
Si ya aprendiste a programar y quieres entrar en este mundo como todo un profesional Git y Github es algo que debes aprender y por supuesto hacerlo con las buenas prácticas te dará un bonus en tu carrera.
Es importante que conozcas o elijas un flujo de trabajo / workflow ya sea si colaboras en equipo o lo haces solo. Para eso es importante que identifiques las fases más importantes que ocurren mientras desarrollas, que analices el procedimiento a ejecutar cuando se necesita hacer cambios de emergencia contra bugs y muy importante que entiendas de qué forma es más fácil identificar los cambios del proyecto.
Existen numerosos flujos de trabajo que se adaptan a cada necesidad, te listo algunos:
Git Feature Branch Workflow:
Todos los features deben tener una rama dedicada en lugar de concentrar todo en master.
Gitflow Workflow:
Es similar al anterior solo que la estructura de ramas está diseñado alrededor de las entregas del proyecto.
Forking Workflow:
En lugar de usar un solo repositorio centralizado le da la opción a cada colaborador de tener uno propio.
Se recomienda que tus commits tengan una estructura que permita identificar el trabajo que realizaste en el proyecto. Entre más descriptivos sean tus mensajes mucho mejor.
Puedes emplear algunos sufijos como:
feat:
Describe si trabajaste en un nuevo feature
fix:
Describe si solucionaste un bug
docs:
Dice si hiciste algún cambio en la documentación
test:
Indica si añadiste un test
refactor:
Nos muestra que se ejecutó algún refactor en el código
De esta forma se puede tener mejor organizado todo el control de cambios además que lo hacen mucho más fácil de entender.
Un pull-request es una solicitud que hacemos al repositorio cuando enviamos código con cambios, idealmente el propietario del repositorio revisa el código y decide si es apto para ser integrado.
Tener una revisión previa del código antes de ser integrado es muy saludable no importa si estas en un equipo grande o pequeño enviar cambios sin aprobación puede provocar inconsistencias en el código.
[https://docs.microsoft.com/en-us/azure/devops/repos/git/merging-with-squash?view=azure-devops]
Usar git add . definitivamente no es la mejor práctica, lo mejor en estos casos es añadir solo los archivos de los que estuviste trabajando, esto evita que se ingresen muchos archivos “trash” que pueden traer una repercusión grave en la dimensión del repositorio.
Añadir los archivos individualmente:git add src/model/User.java
Es lo mejor para cuidar el hogar (hosting de control de cambios) de nuestro repositorio.
Cuando la buena práctica de usar pull-request en el equipo es parte de su cultura es importante pensar en formas de automatizar y tener más control sobre las revisiones.
El flujo de trabajo de un desarrollador sería este:
Existen herramientas de Integración Continua que facilitan esto, te listo algunas:
Aprende sacar el mejor provecho de Git con tu profesor Freddy Vega @freddier
Excelente explicación
Excelente muy buen aporte. Agregaría dentro de las herramientas de Integración continua Azure Pipelines, dentro de Azure DevOps.
Muy buen post, gracias por compartir!!
Cómo siempre!!! Eres la mejor @anncode
Gracias @anncode! Disfruté mucho leer el post.
Gran post! 😄
Excelente explicacion, gracias @anncode
¡Wau! git es pienso yo que la tecnología mas importante para los desarrolladores en estos momentos.
También codestream es una interesante herramienta.
Muchas gracias @anncode! Que buen dato y explicación.
Muy bueno el documento pero quiero saber tu opinión sobre la herramienta gitkraken
Gitkraken es una buena herramienta para comenzar o realizar trabajos rápidos, no es mala en general. Pero aprender a utilizar la terminal te permite realizar acciones mucho más precisas y adquirir nuevas habilidades.