GIT COMO NUNCA TE LO EXPLICARON: Qué es GIT y como usar un sistema de control de versiones.

Summary

La parábola de Git es una narrativa hipotética que ilustra cómo diseñar un sistema de control de versiones. La historia comienza con la idea de tomar 'fotos instantáneas' o snapshots del código, lo que permite volver a versiones anteriores fácilmente. A medida que se desarrolla, se introducen conceptos clave como los directorios de trabajo, snapshots con nombres identificativos y el uso de mensajes para describir cambios. La historia evoluciona para abordar la necesidad de rastrear múltiples líneas de desarrollo, lo que lleva a la creación de un historial de código en forma de árbol. Se exploran soluciones para problemas de colaboración y se destaca la importancia de la identificación única de snapshots mediante hashes SHA1. Finalmente, se introduce el directorio staging para una mejor gestión de cambios y se compara el sistema resultante con Git, destacando las herramientas adicionales que ofrece Git para gestionar situaciones complejas. Este resumen ofrece una visión general del proceso creativo y los fundamentos de un sistema de control de versiones como Git.

Takeaways

• 💡 La idea de un sistema de control de versiones surge al necesitar un método confiable para hacer seguimiento de las versiones del software y poder volver a versiones anteriores fácilmente.
• 📸 La metáfora de las fotos instantáneas o 'snapshots' en inglés, se utiliza para ilustrar cómo tomar 'fotos' de un estado del código en un momento dado y poder regresar a ellas cuando sea necesario.
• 📁 Se crea un directorio llamado 'working' para trabajar en el desarrollo del software y se realizan copias completas de este directorio llamadas 'snapshots' cada vez que se completa una funcionalidad.
• 🗒️ Se introduce un archivo especial llamado 'mensaje' dentro de cada snapshot que contiene un resumen de los cambios y la fecha de creación, facilitando la identificación y búsqueda de versiones específicas.
• 🌟 La versión 1.0 del software se despliega y es bien recibida por los usuarios, lo que motiva a desarrollar nuevas versiones y mejoras.
• 🔄 Se enfrenta el problema de tener que crear un snapshot que no sea una continuación directa de la última versión, lo que lleva a la idea de ramificaciones o 'branches' en el desarrollo.
• 🌿 Al caminar en la naturaleza y observar el patrón de las ramas de un árbol, se inspira la idea de modelar el historial del código como un árbol con múltiples ramas para manejar diferentes líneas de desarrollo.
• 🔗 Se implementa un nuevo campo en el archivo 'mensaje' de cada snapshot que indica su padre, permitiendo realizar un seguimiento de la historia completa de cada snapshot hasta la rama principal.
• 🔄 Se crea un archivo llamado 'branch' que almacena la información de las ramas y sus últimas snapshots, facilitando la navegación entre diferentes ramas de desarrollo.
• 👥 Se introduce la colaboración en equipo, lo que requiere adaptar el sistema de control de versiones para permitir la identificación de quién es el autor de cada snapshot y la creación de nombres únicos para evitar conflictos.
• 🔧 Se implementa un directorio de 'staging' que actúa como un intermediario entre el directorio de trabajo y el snapshot, permitiendo una selección más precisa de qué cambios incluir en el siguiente snapshot.

Q & A

¿Qué problema específico resuelve la idea del nuevo software que el usuario imagina en el script?

El nuevo software resuelve el problema de hacer un seguimiento confiable de todas las versiones del sistema de archivos, permitiendo volver fácilmente a una versión anterior en la que se hayan modificado o eliminado elementos.

¿Cómo se llama la solución que el usuario imagina para su problema de control de versiones?

La solución que el usuario imagina se llama 'snapshots', que son copias instantáneas del código en puntos específicos del tiempo.

¿Qué es un 'snapshot' en el contexto del script?

Un 'snapshot' es una copia del directorio working completo que se toma cuando se completa una funcionalidad, y que luego se nombra para su identificación futura.

¿Por qué decide el usuario agregar un archivo especial llamado 'mensaje' a sus snapshots?

Decide agregar un archivo especial llamado 'mensaje' para incluir un resumen de los cambios contenidos en el snapshot y la fecha en la que se completaron, lo que facilita la identificación y búsqueda de cambios específicos en el pasado.

¿Cómo se resuelve el problema de identificación de snapshots creciendo en número?

Se resuelve agregando un archivo llamado 'mensaje' que contiene información adicional como un resumen de los cambios y la fecha, y posteriormente se utiliza un hash SHA1 único para identificar cada snapshot.

¿Cómo se representa la estructura del historial de código después de la implementación de la solución snapshots?

El historial de código se representa como un árbol, donde cada snapshot es un nodo y los padres de cada nodo son los snapshots anteriores desde los cuales se derivó.

¿Qué es una 'branch' en el contexto del script?

Una 'branch' es una rama de desarrollo en el historial del código que permite trabajar en paralelo en diferentes funcionalidades o cambios sin afectar la rama principal.

¿Cómo se resuelve el problema de la identificación de quién es el autor de cada snapshot?

Se resuelve agregando el nombre y el apellido del autor en el archivo 'mensaje' de cada snapshot, lo que permite identificar claramente a quién corresponde cada snapshot.

¿Por qué deciden utilizar SHA1 para nombrar las snapshots?

Deciden utilizar SHA1 para asegurar que el nombre de cada snapshot sea único y para eliminar cualquier confusión, ya que un hash SHA1 es único para cada contenido del archivo message.

¿Cómo se mejora el proceso de trabajo en equipo y combinación de cambios en el sistema de control de versiones?

Se mejora creando un nuevo snapshot que incluye los cambios de ambas partes y tiene dos padres, apuntando a las últimas snapshots de cada uno de los colaboradores, lo que permite combinar cambios sin problemas.

¿Qué es el directorio 'staging' y cómo ayuda a organizar el proceso de creación de snapshots?

El directorio 'staging' es un intermediario entre el directorio de trabajo y el snapshot, donde se pueden decidir qué cambios incluirán en el siguiente snapshot, facilitando la especificación de los cambios que se quieren capturar.

¿Cómo garantiza Git que es difícil perder trabajo, incluso cuando se elimina una rama?

Git garantiza que el trabajo no se pierde al eliminar una rama porque simplemente se elimina el puntero hacia el commit, pero las snapshots o commits siguen existiendo en el objeto del directorio; se puede recuperar utilizando el SHA1 del commit.