¿Qué es Git?
¿Qué es Git?
Git y GitHub se han convertido en dos de las herramientas más esenciales en este sentido, revolucionando la forma en que los desarrolladores administran el código, rastrean los cambios y colaboran en los proyectos. Estas herramientas no sólo han simplificado los procesos de desarrollo, sino que también han fomentado una comunidad global de programadores que trabajan juntos para crear y mejorar software. Bien, hablemos de Git, que es la columna vertebral del control de versiones. En esencia, Git es un sistema de control de versiones distribuido diseñado para rastrear cambios en el código fuente durante el desarrollo de software. Desarrollado por Linus Torvalds en 2005, Git ha ganado una inmensa popularidad debido a su velocidad, eficiencia y flexibilidad. A diferencia de los sistemas de control de versiones centralizados, Git opera de manera distribuida, lo que permite a los desarrolladores trabajar en sus copias locales de un repositorio y sincronizar sus cambios con las copias de otros sin problemas. Una de las características clave de Git es su capacidad para crear instantáneas de todo el historial de un proyecto. Esto se logra mediante el uso de un sistema de ramificación y fusión. Los desarrolladores pueden crear ramas para trabajar en funciones o correcciones específicas de forma independiente y luego fusionar esos cambios nuevamente en el código base principal. Este proceso permite el desarrollo paralelo manteniendo la integridad del código base.
El impacto de Git y GitHub
La adopción de Git y GitHub ha transformado el desarrollo de software de varias maneras.
- Primero tenemos la colaboración. Los desarrolladores pueden colaborar sin problemas en proyectos de cualquier tamaño, desde un pequeño script hasta aplicaciones complejas, sin preocuparse por conflictos de versiones o pérdida de datos.
- Segundo gran ventaja es el código abierto. La plataforma GitHub ha desempeñado un papel fundamental en la proliferación del software de código abierto. Los desarrolladores de todo el mundo pueden contribuir a los proyectos que les apasionan, fomentando la innovación y el desarrollo impulsado por la comunidad.
- Tercero la calidad del código. El proceso de revisión de código en GitHub garantiza que los cambios se analicen antes de fusionarlos, lo que genera una mayor calidad del código y menos errores.
- Cuarta la documentación. Las herramientas de documentación y wiki integradas de GitHub facilitan la creación y el mantenimiento de la documentación del proyecto, mejorando la usabilidad general del software.
- Quinto la gestión de proyectos. El sistema de seguimiento de problemas y los tableros de proyectos de GitHub brindan herramientas para organizar tareas, rastrear el progreso y administrar hitos.
- Sexto aprender y compartir. GitHub sirve como un tesoro de ejemplos de codificación y mejores prácticas, lo que permite a los desarrolladores aprender del trabajo de los demás.
- Séptimo mercado laboral. El dominio de Git y GitHub se ha convertido en una habilidad valiosa en la industria tecnológica, ya que la mayoría de las empresas de software utilizan estas herramientas para el desarrollo. Entonces, como hemos visto, Git y GitHub han revolucionado la forma en que se desarrolla, comparte y colabora el software. Las eficientes capacidades de control de versiones de Git, combinadas con las características colaborativas de GitHub, han permitido a los desarrolladores trabajar juntos sin problemas, ya sea que estén creando proyectos de código abierto o aplicaciones empresariales.
Estas herramientas han democratizado el desarrollo de software, permitiéndoles, como comunidad global, contribuir al avance de la tecnología de una manera más conectada y eficiente.
Imagina que estás escribiendo una frase sobre programación y escribes cosas como “Si debuggear es el proceso de remover errores de código, entonces programar debe ser el proceso de ponerlos”, esta frase es la versión 1. Pero el tiempo pasa y tienes que crear una versión nueva, entonces en esa versión nueva escribes que ya no es remover si no eliminar, ahora ya no va la palabra ponerlos si no ubicarlos.
Lo normal es que cuando creas tu archivo le ubiques un nombre, en este caso puede ser tesis.txt y así guardar la frase que escribiste, pero para tener una versión nueva con las modificaciones hechas, creas un nuevo archivo y le colocas guion bajo v2, o versión nueva, o versión final, o versión final, final, final, .txt, etcétera. Y eso es lo que todos hacemos, sea en el mundo del diseño o del marketing o de la programación, antes de conocer los sistemas de control de versiones, esta es nuestra única opción.
Sin embargo, la realidad es que son muy pocos los cambios que ocurrieron en el archivo y no debemos guardar todo el archivo de nuevo solo por esos cambios que son remover por eliminar y ponerlos por ubicarlos. Si hubiera una forma en la que solo guardamos esos cambios en vez de tener que guardar todo el archivo nuevo, sería ideal. En particular, se utiliza Git cuando estamos trabajando con múltiples personas sobre el mismo archivo o cuando estamos cambiando pequeñas cosas en algo tan grande como por ejemplo el código de un proyecto de software.
Control de versiones
Debido a lo que se pudo evidenciar en el ejemplo anterior, en esos casos es donde entran los sistemas llamados sistemas de control de versiones, que lo que hacen es solamente guardar esos cambios y dejar claro ¿dónde ocurrieron?, ¿cuándo ocurrieron?, ¿quién los hizo?, podemos volver a ellos en el pasado, entre muchas otras cosas.
El sistema de control de versiones más popular del mundo, se llama Git. Fue creado por la Fundación Linux, particularmente por Linus Torvalds, es el sistema que maneja el kernel de Linux. Y como ustedes ven la figura anterior, debe guardar los cambios. Si yo fuera a guardar el archivo tesis.txt y los cambios, guardaría solamente el cambio de la palabra remover por la palabra eliminar, también cambia la palabra ponerlos por ubicarlos.
Podemos acordarnos de lo típico que hacíamos en la universidad o instituto, cuando nos mandaban algún trabajo empezamos a escribir el documento, luego cuando finalizamos nuestro trabajo revisamos a ver si cuadra con lo que nos piden, vemos que nos falta añadir algunos cambios pero para no perder lo que hemos hecho pues lo duplicamos, y le ponemos el nombre de trabajo final a la nueva copia, revisamos los cambios y vemos que nos falta algo más y creamos otra copia y tenemos trabajo final final, con git se automatiza todo esto.
La ventaja es que siempre vamos a tener un único espacio de trabajo donde nosotros vamos confirmando los cambios que queremos aplicar y Git maneja las versiones, no tenemos que copiar y pegar ni nada de esto manual.
Áreas principales de Git
Working tree
Working tree o directorio de trabajo que es donde está nuestro proyecto que es una carpeta donde nosotros vamos añadiendo archivos y más carpetas, en este caso archivos de código JavaScript o de lo que sea del código que estemos escribiendo, podemos ir haciendo cambios en esos archivos, por ejemplo imagínate que en este archivo yo escribo varias líneas de código y creo una función, yo puedo considerar que es una versión nueva de mi código que quizás en el futuro me interesa volver pues ahí es cuando lo paso al staging area.
Staging area
El staging area son cambios pendientes a ser confirmados, es decir no son versiones como tal todavía, sino que eso está pendiente de que nosotros lo validemos como una versión y en aso de validarlo podemos hacer un commit.
Commit
Un commit es una versión del programa a la se que puede volver en cualquier momento y puedes tener infinitos commits.
Comandos
Vamos a ingresar aun una carpeta desde la línea de comandos e imaginando que ya tienes instalado Git, haces lo que se llama git espacio init. Lo que hace este comando de línea de comandos es empezar en tu carpeta un repositorio, que es en esa base de datos donde van a guardar los cambios de cualquier archivo. En este caso, tesis.txt. Pero ahora tu repositorio tiene que saber que este archivo existe.
Entonces dentro le colocas algo que se llama git espacio add como añadir y espacio el nombre del archivo, tesis.txt. Con esto Git ahora sabe que existe tesis.txt. Digamos que en ese punto quieres agregarlo a la base de datos porque no es suficiente simplemente darle add. Tienes que decirle que los cambios que hiciste ya están listos. Esto es porque cuando tú agregas un archivo justo antes de mandarlo al repositorio, entras en lo que se llama staging. Por ahora puede que sea muy problemático y complicado, pero no te estreses por ello. Sólo mantén en la mente que init es el que arranca el repositorio, add es el que arranca el archivo.
Luego commit es el que envía los últimos cambios del archivo a la base de datos del sistema de control de versiones para controlar los cambios que se le hayan hecho. Entonces es git espacio commit y si le quieres agregar un tipo de mensaje para que en el futuro tú puedas ver que fue lo que hiciste ahí, agregas espacio guión m espacio, abres comillas y escribes el mensaje que le quieras dejar y cierras comillas. Esto es una muy buena práctica, mantiene el higiene de tu proyecto entero y la higiene es algo muy importante sobre todo cuando pasa mucho tiempo o cuando empiezas a trabajar con diferentes miembros del equipo en un mismo proyecto.
Ahora sí vamos a hacer los cambios porque esta es la versión vieja que tengo agregada a mi base de datos del sistema de control de versiones, voy al editor de texto y hago los cambios como vemos en el texto de la figura anterior. Y ahora que es eliminar en vez de remover, ubicarlos en vez de ponerlos. Una vez hechos los cambios, guardo el archivo y ya está. Lo tengo guardado en mi disco duro, pero todavía no tengo guardados los cambios en el repositorio.
Entonces para ello tengo que volver a agregar el archivo, si deseo, realmente es opcional. Otra opción para agregar archivos, es git espacio add espacio punto. Cuando le agregas el punto, lo que haces es que agregas todos los archivos que hayan cambiado en la carpeta donde en ese momento estás.
Una vez has añadido esos cambios de archivo, vuelves a hacer un commit. Y ahora en ese commit lo que dices es que le hiciste unos cambios a la versión 1. Te dan esos cambios hechos y ya quedan absolutamente grabados.
Puedes ver cómo está el status de tu base de datos haciendo git espacio status. Si por ejemplo has hecho un cambio pero no lo has añadido, ahí te va a salir. Si todo está bien, te va a decir que no hay ningún problema.
Otro comando muy importante es el comando show, git espacio show. Show te va a mostrar todos los cambios históricos hechos, incluyendo cuáles han sido las líneas de código o las líneas de texto o las líneas de cualquier archivo que hayas añadido que hayan cambiado, cuándo se han hecho esos cambios y quién los hizo. Porque en un repositorio pueden acceder múltiples personas.
También si tú quieres ver la historia entera de un archivo, puedes hacerlo con el comando log. Git espacio log espacio el nombre de archivo. En este caso tesis.txt y te lo va a mostrar todo. Por último, una vez ya estás listo y has completado todos estos pasos, quizás puedes llevar tu archivo a un servidor remoto porque probablemente ese archivo vive en un repositorio en internet o en un servidor donde tú quieres que lo vea todo el mundo.
Para esto utilizamos el comando push. Es el que te permite enviar hacia otro repositorio remoto lo que estás haciendo. Y también con pull lo puedes traer.
Conclusiones
- Un sistema de control de versiones como Git nos ayuda a guardar el historial de cambios y crecimiento de los archivos de nuestro proyecto.
- Git está optimizado para guardar cambios de forma atómica e incremental, o sea, aplicando cambios sobre los últimos cambios, estos sobre los cambios anteriores y así hasta el inicio de nuestro proyecto.
- El comando para iniciar nuestro repositorio, o sea, indicarle a Git que queremos usar su sistema de control de versiones en nuestro proyecto, es git init.
- El comando para que nuestro repositorio sepa de la existencia de un archivo o sus últimos cambios es git add. Este comando no almacena las actualizaciones de forma definitiva, únicamente las guarda en algo que conocemos como “Staging Area” (área de montaje o ensayo).
- El comando para almacenar definitivamente todos los cambios que por ahora viven en el staging area es git commit. También podemos guardar un mensaje para recordar muy bien qué cambios hicimos en este commit con el argumento -m «Mensaje del commit».
- Por último, si queremos mandar nuestros commits a un servidor remoto, un lugar donde todos podamos conectar nuestros proyectos, usamos el comando git push.