Control de versiones con GitHub

Alberto Lahuerta

Portada del post
#vcs-con-github

Aquí esta la pieza angular donde se cierra el circulo que comencé hace 2 publicaciones. Sigue leyendo y todo encajara.

Como indica la numeración que nos lleva acompañando los últimos post, utilizamos Github para el control de versiones, ¿sabes qué es?

Bueno Github es la plataforma que utilizamos, en realidad usamos Git y utilizamos Github como “nube”, aunque eso sería quedarme muy corto.

Te refresco por aquí la saga:

  • Netlify : para implementar el sitio.
  • Sanity: para gestionar el contenido que manipula el cliente, es un CMS sin cabeza.
  • Github: pues eso.

¿Qué es Git?

Git es un sistema de control de versiones gratuito y de código abierto, fue creado en 2005.

Yo no se cuanto tiempo perdí hasta que lo descubrí, pero fue empezar a utilizarlo y llegó la paz mental mientras desaparecían las carpetas y los archivos con sufijos del palo _final _definitivo _final_final _final_ok _este_si_que_es_el_bueno(1)

Seguro que ya sabes de que te hablo, de cientos de archivos, de cientos de carpetas duplicadas, de perder el control y estar trabajando en la que no debes, menuda pesadilla.

Git acaba con eso del tirón.

Así por resumir, cada vez que quieres “fotografiar” un estado haces un “commit” que se llama, le pones un nombre y una descripción y sigues trabajando.

Así una y otra vez...

Al final si quieres volver atrás tienes tantos “ctrl + z” como commits has hecho, y documentados claro. Entonces puedes volver al commit que quieras e incluso ver las diferencias con el actual, ves un timeline con todos los commits, una maravilla vamos.

A parte de eso tienes “ramas”, son líneas paralelas a ese timeline y puedes crear las que quieras, que quieres probar un diseño nuevo, puedes crear una rama nueva y seguir trabajando como si nada, en tu ordenador no hay archivos duplicados ni nada, NADA.

Que no te gusta como queda, vuelves a la rama principal y te olvidas del nuevo diseño, bueno borras la rama y listo, que te gusta, le dices que la una a la rama principal, ya está.

Lo habitual es tener un mínimo de dos ramas, una para producción y otra para desarrollo, esto te lo cuento porque necesito que lo sepas para más adelante.

Se puede usar git en local tú solito, o tenerlo en un servidor y que el equipo pueda trabajar sobre él del mismo modo que antes, solo que cuando quieres que trasladar al servidor tus commits haces un “push” y se mandan todos los commits, y por supuesto tienes que ir haciendo “pull” para recibir los que no has hecho tú y estar actualizado, trabajar en equipo es muy asequible, pero cuidado nosotros hacemos serverless

Github

Github es una plataforma donde se aloja Git, y ahí puedes guardar tus repositorios de Git, pues eso, una nube, donde todo el equipo puede colaborar y todos estamos actualizamos.

Por supuesto tiene un plan gratis con repositorios privados, tiene limitaciones en comparación con la versión pro, pero yo no me he chocado con ninguna.

Como he dicho antes Github es mucho más que esto, y tiene cosas con las que conseguimos hacer integración continua y desarrollo continuo de forma segura, pero eso da para otro post.

Ahora toca cerrar el círculo

Me gustaría montar esto en una landing con un poco de estilo... quizás lo haga 🤔

¿Quieres un cambio?
Contáctanos

Juntos podemos hacer las cosas fáciles.

Nuestras pepitas de chocolate para mejorar tus proyectos

© TheCookies Agency S.L. Todos los derechos reservados