7 Errores que estás cometiendo por no usar Github desde cero

• ¿Por qué deberías empezar a usar Github desde cero?
• ¿Qué es un sistema de control de versiones o VCS?
• 1. No utilizar un sistema de control de versiones como Git
  • Github que es y para que sirve
• 2. No crear un repositorio para tu proyecto
• 3. No Añadir un archivo Readme a tu repositorio de Github
• 4. No proteger tu Rama Master o Main
• 5. No hacer Pull Request
• 6. No usar Milestones (Hitos) e Issues
• 7. No utilizar Github Projects

Cuando nos adentramos en el mundo de la programación, uno de los problemas más comunes a la hora de gestionar nuestros proyectos, es la solicitud de cambios y nuevas actualizaciones que por su naturaleza todos los proyectos tienen

¿Por qué deberías empezar a usar Github desde cero?

Mientras más vaya creciendo un proyecto, probablemente más complicada es la gestión de esos cambios, por lo que la solución a dichos problemas se encuentra en poder implementar un sistema de control de versiones, pero probablemente, la siguiente pregunta sería:

¿Qué es un sistema de control de versiones o VCS?

Un sistema de control de versiones en términos muy sencillos, es un software que nos permite administrar o gestionar los cambios o actualizaciones que sufren los proyectos a través del tiempo, es decir, tomar el control de las versiones del software, esto es útil porque:

1. No tenemos que preocuparnos por tener diferentes carpetas o directorios en nuestra computadora añadiendole al nombre: “Este es el bueno” o “final, finaaaal”
2. Si trabajamos en equipo, no tenemos que preocuparnos porque nuestros compañeros reemplacen nuevas actualizaciones que hayamos hecho al código (o si? 🤔)
3. Podemos regresar a versiones anteriores en cualquier momento (He ahí la importancia que aprendas a manejarlo)

Es por eso que en este artículo quiero mencionarte cuáles son los errores más comunes que comentemos los desarrolladores, solo por no contar con un Sistema de Control de Versiones.

1. No utilizar un sistema de control de versiones como Git

En principio es importante mencionarte que el Sistema de Control de Versiones más popular hasta el momento se denomina Git, sin embargo, no es el único que existe en el mercado.

Como Git mismo indica en su propia página, existen algunos otros como: Subversion, CVS, Perforce y ClearCase por mencionar algunos, pero git tomó en los últimos años más fuerza y muchas de las empresas las incorporaron como Sistema de Control de Versiones.

Github que es y para que sirve

Debo comentarte que probablemente cuando escuchas la palabra Git, seguramente se te viene a la mente Github, sin embargo, Github es una plataforma de repositorios en línea que permiten el uso de Git, pero no es la única en el mercado, también existe GitLab que es su competidor directo en estos momentos, solo por mencionarte algo.

En este post en especial, centraremos nuestra atención en las características de Github, aunque podría recomendarte que visitaras GitLab o BitBucket para administrar tus repositorios.

Ahora si, una vez que ya conocemos cuál es la diferencia entre Git y Github, aquí te dejo una lista de posibles errores que estes cometiendo en tu flujo de trabajo, solo por no integrar Github

2. No crear un repositorio para tu proyecto

Puede parecer muy básico, pero muchas empresas y/o desarrolladores aún no integran repositorios a sus proyectos y lo manejan todo de manera local, en su disco duro o si se han “modernizado” con el paso del tiempo, seguramente habrán subido su código a Dropbox o Google Drive.

Los pasos para poder generar un repositorio son muy sencillos, simplemente tenemos que generar una cuenta en github.com y una vez que ya tengamos la cuenta, podemos empezar a generar nuestro primer repositorio, si aún no sabes como hacerlo, te dejo un video en donde explico paso a paso el procedimiento para crear un repositorio de Github.

3. No Añadir un archivo Readme a tu repositorio de Github

Otro error muy común que cometemos a la hora de realizar nuestros proyectos, es no generar un archivo readme, Este archivo readme, es comúnmente el primer archivo que todas las personas verán cuando accedan a tu repositorio, es decir, algo como tu carta de presentación.

Es por ello que debes siempre agregarlo utilizando etiquetas Markdown y agregando información valiosa del proyecto, para que cualquier persona que desee descargarlo o colaborar sepa por donde iniciar

Comúnmente la información que se agrega en un archivo readme es: Nombre o título del proyecto, Descripción del Proyecto, instrucciones de instalación o ayuda, detalles sobre actualizaciones o parches, también puedes añadir como correr el proyecto y como usarlo cuando ya se está ejecutando.

Es muy recomendable también que añadas información sobre Licencia, créditos, como contribuir al proyecto e incluso tablas de contenido y test o pruebas de desarrollo. Te dejo este video para que puedas aprender como añadir un archivo readme a tu proyecto.

https://www.youtube.com/embed/uuYrENU1KcQ

4. No proteger tu Rama Master o Main

Una vez que ya empezamos a trabajar con Github un error típico es hacer todos nuestros commits dentro de la rama main o master, siguiendo un workflow lineal, que si bien, al trabajar individualmente tal vez no sea “tan malo”, cuando trabajamos colaborativamente seguramente si nos añade muchos problemas.

Es por ello que la mejor forma de configurar nuestro repositorio de Github es añadir las reglas de protección a la rama master o main.

Lo que permitirá esta protección es: no dejar realizar commits directos a main, forzar a realizar pull request para mejorar el flujo de trabajo y añadir code reviews para que otros desarrolladores del equipo reciben tu código en búsqueda de mejorar o posibles errores que no hayamos detectado en un inicio.

Para poder proteger nuestra rama es tan sencillo como ir a la sección de settings dentro de nuestro repositorio y en el menú de la barra lateral, seleccionar la opción Branches, dentro de ella podremos añadir las reglas de protección en la opción Add branch protection rule.

Si deseas ver como lo hago, puedes revisar el video COMO HACER PULL REQUEST en un REPOSITORIO de GITHUB a partir del minuto 14:00, ¡aunque te recomiendo verlo completo!

5. No hacer Pull Request

Si no estás familiarizado con el concepto, seguramente te estes preguntando en estos momentos ¿Qué es un Pull Request? Para explicarte, abundaré un poco en el proceso:

Cuando tenemos un repositorio de Github y empezamos a realizar cambios o actualizaciones a nuestro código, es importante que mantengamos un orden y una estructura por cada cambio que hagamos, por lo que lo más conveniente es agregar una nueva rama o branch por cada modificación que tengamos que hacer.

Las buenas prácticas también incluyen el naming de las ramas, que consiste en una estructura de como nombrar nuestras branches para que sean más descriptivas, pero eso te lo contaré en otra entrega.

Una vez que hayas generado la rama, realizado las modificaciones pertinentes y commiteado tus cambios, Tendrás que Hacer una “petición de empuje” o pull request, que básicamente consiste en describir cuales fueron tus cambios y solicitar o pedir que dichos cambios sean agregados a tu rama main o master.

Una de las cosas que comúnmente me preguntaba cuando iniciaba en este mundo era: ¿Por qué no puedo hacer commit a main o master y me evito de problemas (Le decía de forma distinta)?

La respuesta es porque muchas empresas e desarrolladores integran a sus flujos de trabajo algo que se llama CI/CD.

Esto hace que cada vez que realices un merge, es decir, cada vez que te aprueben tu pull request y lo agregues a la rama main o master (Le llamamos mergear), se integran procesos para mandar directamente nuestros cambios a producción, lo que significa, que todos los usuarios o visitantes de tu sitio o aplicación puedan tener tus últimas modificaciones.

Otra pregunta que se me venía a la cabeza era: ¿Donde está mi FTP? ¿Como accedo a mi CPanel? bueno, pues con CI/CD nos olvidamos al menos por el momento de eso.

Si quieres saber como hacer un pull request y entender más de este show, aquí te dejo otro videito. No olvides hacer lo que te corresponde :)

6. No usar Milestones (Hitos) e Issues

El avance de un proyecto, siempre se debe de medir, por si misma, la gestión de proyectos es un poco compleja y eleva esa complejidad mientras se elevan factores como el tiempo o el capital humano que trabaja en él.

Es por eso que para poder medir y gestionar nuestro proyecto, Github dispone de “algo” que se denominan hitos, aunque en inglés suena más bonito: Milestones.

En términos sencillos un milestone se define como un evento importante en la historia o desarrollo de “algo” o alguien, entonces, si lo enfocamos a la parte de gestión de proyectos, significa que hemos logrado desarrollar una parte importante del proyecto, ejemplo: se liberó un nuevo feature, se liberó un nuevo módulo, se añadió una nueva página, se generó una nueva landing, etc…

Por otro lado cada tarea que hacemos para poder cumplir o completar el milestone, Github le llama issue y explicando un poco esto, en gestión de proyectos de podríamos llamar: Historia de usuario, caso de uso, tarea, objetivo específico o KR, no quiero decir que necesariamente sea lo mismo, pero tal vez tu lo conozcas de una manera distinta al término que yo utilizo y en esencia, digamos que se parecen.

¿Qué crees? no solo me gusta escribir, sino que también me gusta grabarme para validar que de verdad he aprendido cosas nuevas, por lo tanto, te dejo un video en donde explico como hacer un issue o milestone en github

https://www.youtube.com/embed/cIhNWpU5ZJg

7. No utilizar Github Projects

Ya para finalizar con todo este choro, el último de los errores más comunes que cometemos es el no incluir un tablero de proyectos o Github projects, ya que Github integra dentro de sus herramientas, un tablero al estilo Kanban o Task List para poder darle seguimiento a cada uno de los issues que hemos levantado.

Con ello, podemos medir la evolución del milestone, algo que en verdad llama la atención de estos tableros es que nos permiten automatizar los flujos de seguimiento con base en el evento que hayamos generado, es decir, cada vez que hagamos un Pull Request, un Code Review, Mergeemos algo, etcétera, el tablero cambiará el issue entre cada una de las columnas del proceso, tal cuál lo haríamos en Kanban

Es por ello que he generado un video en donde te cuento cual es el proceso a seguir para poder ir gestionando tu proyecto en un tablero Kanban mediante Github Project

Por último, ¿No te gusta leer?, ¿eres de los que comprende más las cosas de manera visual?, si es así te dejo el curso completo de Github que preparé para ti.

🎯 Reto Ninja

✅ Checklist de Dominio