Aprende al fin Git y Github – 1

16 mayo, 2016
-No trabajes en caliente- Era la frase que muchos administradores de sistemas dicen cuando alguien tocaba el código de un proyecto directamente en el FTP, hacer eso es un riesgo grande ya que puedes dejar a tu cliente sin web por estar toqueteándole las entrañas mientras la web está siendo visitada.

 

-¿Tienes backup?- Otra de las preguntas que siempre debes hacerte a la hora de desarrollar, si usas Time Machine de OSX o cualquier sistema de backup con disco externo sabes que tienes unos backups cada hora de todo el sistema, pero si trabajas en caliente esos backups no se guardan a menos de que bajes el archivo a tu ordenador y este se incluya en las “revisiones” de Time Machine, ahora dejemos TM para el sistema ya que no es lo óptimo para trabajar en grupo y peor de forma remota.

 

-¿¿ ¡Pero qué has tocado!??- Es ese sudor frío que te recorre la médula espinal cuando tu desarrollo deja de funcionar y no sabes porque, ni quien lo modifico, ni cuándo ni que línea de código o archivo.

 

Primero. ¿Qué es Git?

Es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando estas tienen un gran número de archivos de código fuente.

 

Git es un sistema distribuido de control de código fuente o SCM (en inglés Source Code Management). Si nunca has utilizado un SCM, me imagino que la frase anterior te habrá sonado a chino. Si es así, la pregunta que te estarás haciendo ahora es ¿qué es un SCM?

Un SCM es una herramienta que nos resuelve una serie de problemas a todos aquellos que tenemos que trabajar código fuente. “Código fuente” pueden ser muchas cosas:

  • Ficheros HTML / CSS / Javascript
  • Ficheros PHP
  • Ficheros de configuración
  • Documentación
  • … y un largo etc

Si te das cuenta, todos los ejemplos que he puesto tienen una cosa en común: todo son ficheros de texto plano y todos son ejemplos de ficheros que encontrarás en tus proyectos a la hora de programar.

¿Y qué problema resuelve un SCM?

Vamos a ponernos en situación: imagínate que acabas de comprarte un nuevo tema o plugin para tu WordPress. Está muy bien, te has gastado 60€ (o 0€ si es gratis) y con ese plugin tienes resuelto el 80% de las necesidades del proyecto que estás haciendo. Ahora sólo te falta desarrollar el 20% restante. Para hacerlo, tendrás que modificar el código fuente que has adquirido:

  • Seguramente tengas que modificar la hoja de estilos CSS y adaptarla a tu diseño
  • Tendrás que utilizar alguno de los hooks para implementar la funcionalidad que te falta
  • Quizás incluso tengas que añadir tu propio tipo de post, crear una interfaz de administración para él y seguramente hacer tu propio de shortcode

Cuando terminas, subes tu código al servidor y publicas tu nuevo proyecto o se lo entregas al cliente. En este momento, el código fuente ya no es el mismo que adquiriste, lo has cambiado. Es ahora cuando te hago las siguientes preguntas:

  • ¿Sabrías decirme dentro de 6 meses qué es exactamente lo que has cambiado del código del plugin del que partiste?
  • Resulta que tu plugin inicial se ha actualizado y ha pasado de la versión 1.5.1 a la versión 1.6 ¿Serías capaz de incorporar todas las mejoras y novedades a tu versión personalizada (en un tiempo corto, no hacerlo todo otra vez)?
  • Con el paso del tiempo el cliente te pide una actualización, se la subes a su servidor y dos días después te dice que lo dejes como estaba porque no funciona bien ¿Podrías volver atrás de forma rápida? ¿Te acordarás de qué líneas de código has modificado con precisión para depurar rápidamente dónde está el error que has introducido en el sistema?
  • El cliente llama a los tres meses diciendo que no funciona el WordPress ¿serías capaz de determinar de forma rápida si el cliente ha modificado el código fuente del proyecto por su cuenta y se lo ha cargado él? ¿o realmente es un bug que no ha salido en tres meses? La pregunta es importante porque el coste del arreglo no sería el mismo según el tipo de mantenimiento o garantía que hayas acordado con tu cliente

Un SCM es la herramienta que nos permite responder positivamente a estas preguntas, y a muchas más.

¿Qué nos aporta git?

  • Auditoría del código: saber quién ha tocado qué y cuándo
  • Control sobre cómo ha cambiado nuestro proyecto con el paso del tiempo
  • Volver hacia atrás de una forma rápida
  • Control de versiones a través de etiquetas: versión 1.0, versión 1.0.1, versión 1.1, etc. Sabremos exactamente que había en cada una de ellas y las diferencias entre cualquiera de ellas dos
  • Seguridad: todas las estructuras internas de datos están firmadas con SHA1. No se puede cambiar el código sin que nos enteremos
  • Mejora nuestra capacidad de trabajar en equipo
  • Merging y branching extremadamente eficientes

Segundo. ¿Y qué es Github?

GitHub es una forja para alojar proyectos utilizando el sistema de control de versiones Git. Utiliza el framework Ruby on Railspor GitHub, Inc. (anteriormente conocida como Logical Awesome).

El código se almacena de forma pública, aunque también se puede hacer de forma privada, creando una cuenta de pago.

¿Recuerdas la primera frase del artículo? “Git es un sistema distribuido de control de código fuente o SCM”. Que git sea distribuido quiere decir que está preparado para poder trabajar en equipos distribuidos (es decir, cada uno en su casa) de forma eficiente. Imagínate que tú estás en España y yo en Rusia ¿Cómo hacemos para coordinarnos? ¿Cómo sé yo qué código has tocado tú y viceversa?.

Este problema git lo resuelve con herramientas un poco complicadas de configurar si no tienes la experiencia y conocimientos adecuados (Servidores SSH, claves públicas y privadas, etc). Si eres administrador de sistemas y tienes tu propio servidor, no tardarías mucho en hacerlo. En caso contrario, Github te facilita toda la infraestructura para trabajar en equipos distribuidos a través de una interfaz web la mar de cómoda.

¿Y me interesa usar github si trabajo yo sólo? Yo lo hago, por la sencilla razón de que si tienes una copia de tu código fuente en github, tienes un backup de todo el proyecto completo. Ese backup incluye no sólo el código que tienes ahora sino también de todo el historial de modificaciones que el código ha sufrido desde el primer día. Esta copia la puedes recuperar en cualquier momento y continuar trabajando desde cualquier ordenador como si nada… pero esto sería ya tema para otro capítulo.

Bibliografia

http://wpmallorca.com/2013/02/12/pero-que-es-github/

https://es.wikipedia.org/wiki/Git

http://blog.santiagobasulto.com.ar/programacion/2011/11/27/tutorial-de-git-en-espanol.html

http://rogerdudler.github.io/git-guide/index.es.html

 

No hay comentarios en este articulo.Puedes ser el primero en comentar.

Deja un comentario