Control de Versiones con Git
¿Qué es Git?
Git es un sistema de control de versiones distribuido que permite gestionar y registrar los
cambios en los archivos de un proyecto. Este sistema facilita la colaboración entre equipos
y asegura que cada cambio realizado en el código fuente sea rastreable y reversible. Git es
ampliamente utilizado en proyectos de software debido a su capacidad para manejar flujos
de trabajo complejos y garantizar la integridad de los datos.
Historia de Git
Git fue creado por Linus Torvalds en 2005 para gestionar el desarrollo del núcleo de Linux.
Antes de Git, el equipo utilizaba un sistema propietario llamado BitKeeper, pero su uso se
volvió insostenible debido a limitaciones legales. Linus diseñó Git con tres principios clave
en mente:
1. Velocidad: Git debía ser extremadamente rápido para manejar proyectos grandes
con millones de líneas de código.
2. Distribución: Cada desarrollador tendría una copia completa del historial del
proyecto, eliminando la dependencia de un servidor central.
3. Integridad: Los datos almacenados debían ser inmutables y resistentes a
corrupciones.
En la actualidad, Git se ha convertido en el estándar de facto para el control de versiones y
es utilizado por millones de desarrolladores en todo el mundo.
¿Por qué es importante el control de versiones?
El control de versiones resuelve problemas comunes en el desarrollo de software, como la
pérdida de cambios importantes, la sobrescritura accidental del trabajo de otros, y la
dificultad para coordinar proyectos en equipo. Los principales beneficios incluyen:
1. Registro histórico: Cada cambio se guarda con detalles como el autor, la fecha, y
un mensaje descriptivo.
2. Colaboración eficiente: Múltiples desarrolladores pueden trabajar en un proyecto
simultáneamente sin interferir en el trabajo de los demás.
3. Pruebas y experimentación: Las ramas permiten probar nuevas ideas sin afectar el
código principal.
4. Recuperación de errores: Es posible retroceder a versiones anteriores si algo sale
mal.
Conceptos clave de Git
Para entender cómo funciona Git, es fundamental familiarizarse con los siguientes
conceptos:
1. Repositorio
Un repositorio es el lugar donde Git almacena todos los archivos y el historial de cambios.
Existen dos tipos principales:
● Repositorio local: Está en tu máquina y contiene todo el historial del proyecto.
● Repositorio remoto: Está en un servidor (como podría ser GitHub, que está en la
nube) y permite compartir el proyecto con otros desarrolladores.
Ejemplo de la vida real:
Piensa en un repositorio como una biblioteca digital de publicaciones científicas en pdf. Los
pdf originales representan el repositorio local inicial, mientras que una copia en línea de los
pdfs accesible para el resto de la comunidad científica representa el repositorio remoto.
2. Commits
Un commit es una instantánea de los cambios realizados en los archivos de un proyecto.
Cada commit incluye un mensaje descriptivo que explica qué se cambió y por qué.
Ejemplo:
Si un científico accede a las copias en línea podría descargarse las publicaciones y añadir
algún capítulo, observación o cambio a alguna de ellas, pudiendo pasar a estar disponible
para toda la comunidad si actualiza los cambios al repositorio remoto mediante un commit.
Además, existe un registro de qué científico ha modificado qué parte de qué publicación y
en qué fecha lo hizo, de manera que podría volverse a versiones anteriores de las
publicaciones en caso de demostrarse que el científico se ha equivocado en sus
aportaciones.
3. Ramas (Branches)
Las ramas permiten trabajar en diferentes líneas de desarrollo al mismo tiempo. Por
ejemplo, puedes tener una rama principal (main) para el código estable y otras ramas para
desarrollar nuevas funcionalidades.
Ejemplo práctico:
Supongamos que estás colaborando en la programación de una aplicación. Creas una rama
para implementar un nuevo menú, y mientras trabajas en ella, la rama principal sigue
operativa para realizar actualizaciones menores, correcciones de errores o implementación
de otros menús o partes de la aplicación.
4. Bloqueos o fusiones (Merging)
Los sistemas de control de versiones tienen que resolver ciertas problemáticas, como, por
ejemplo, cómo evitar que las acciones de un programador se sobrepongan a los otros
programadores. Contamos con diferentes alternativas para resolver estas problemáticas:
● Compartir archivos por parte de diferentes programadores (sin control)
● Bloquear los archivos utilizados
● Fusionar los archivos modificados
5. Área de preparación (Staging Area)
La staging area es una zona intermedia donde se colocan los cambios antes de
confirmarlos en un commit. Esto permite revisar qué cambios se incluirán en el próximo
commit.
Ejemplo práctico:
Si un científico está reformulando una teoría que se menciona en varios documentos
científicos (pdf), puede querer ir confirmando los cambios de cada pdf en una zona temporal
una vez ha terminado de modificarlo y, una vez ha terminado de modificarlos todos, subir los
cambios todos de una vez haciendo el commit de todos los pdfs en esta zona (similar a las
transacciones en bases de datos)
Estructura interna de Git
Git organiza la información en tres niveles principales:
1. Directorio de trabajo: Es donde editas y trabajas con los archivos actuales del
proyecto.
2. Área de preparación (Staging Area): Es un espacio intermedio donde se colocan
los cambios antes de confirmarlos.
3. Repositorio: Es donde se almacenan los commits y el historial completo del
proyecto.
Estos niveles aseguran que los cambios se gestionen de manera controlada y evitan la
sobrescritura accidental de trabajo.
¿Qué es GitHub?
GitHub es una plataforma basada en la nube para alojar repositorios Git. Es el más usado y
el que actualmente tiene alojados más proyectos de desarrollo de software de código
abierto en el mundo. Permite albergar un número ilimitado de repositorios tanto públicos
como privados.
Colaboración en repositorios remotos de Github
Existen dos formas de colaborar en un repositorio alojado en GitHub:
1. Ser colaborador del repositorio.
● Recibir autorización de colaborador por parte de la persona propietaria del
proyecto
● Clonar el repositorio en local
● Hacer cambios en el repositorio local
● Subir los cambios al repositorio remoto.
○ Primero hacer un “pull” para integrar los cambios remotos en el
repositorio local
○ Luego resolver conflictos de “merging”
○ Luego un “push” para subir los cambios del repositorio local al remoto
● Replicar el repositorio y solicitar integración de cambios.
1. Replicar el repositorio remoto en nuestra cuenta de GitHub mediante un
“fork”
2. Hacer cambios en nuestro repositorio remoto (directamente en la interfaz
web de Github o clonandolo primero en local como en el paso anterior)
3. Solicitar a la persona propietaria del repositorio original que integre nuestros
cambios en su repositorio mediante un “pull request”
Beneficios principales de GitHub
1. Acceso remoto: Permite trabajar en el proyecto desde cualquier lugar.
2. Colaboración: Facilita el trabajo en equipo mediante herramientas como la revisión
de código y los comentarios.
3. Historial público: Los proyectos de código abierto alojados en GitHub son visibles y
modificables para toda la comunidad o para aquellos colaboradores que se decida.
Práctica: Primeros pasos con Git y GitHub
Instalación de Git en la máquina local
Paso 1: Descarga Git
1. Visita la página oficial de Git: https://git-scm.com/.
2. Descarga la versión adecuada para tu sistema operativo (Windows, macOS, o
Linux).
Paso 2: Instalación
1. Abre el instalador descargado y sigue las instrucciones.
2. Configura las opciones según lo recomendado (puedes usar las configuraciones
predeterminadas).
Paso 3: Verifica la instalación
1. Abre la terminal (o Git CMD en Windows).
2. Escribe el siguiente comando para verificar la versión:
git --version
Deberías ver algo como: git version 2.x.x.
Paso 4: Configuración inicial
Configura tu usuario de git, en concreto tu nombre y correo electrónico:
git config --global user.name "Tu Nombre"
git config --global user.email "tuemail@ejemplo.com"
Trabaja en tu proyecto localmente y después crea el repositorio en
GitHub y envíalo a remote.
Haz un documento y sube las capturas de pantalla de la consola de comandos después de
ejecutar cada apartado y la captura de tu repositorio github con el archivo README.txt.
1. Crea un nuevo repositorio local en la carpeta que quieras (puedes hacerlo desde el
gestor gráfico de ficheros del sistema operativo)
mkdir mi_proyecto (linux) / md mi_proyecto (windows) // Make directory
cd mi_proyecto // Change Directory
git init
2. Crea un archivo README.txt, añádelo a la staging area y luego al repositorio local:
echo "Mi Primer Proyecto" > README.txt
git status // Ver el estado del repositorio
git add README.txt // Añadir a la staging area
git status
git commit -m "Agregar README inicial" // Confirmar cambios al repositorio local
3. Crea un repositorio en GitHub (github.com) y conéctalo al local:
git remote add origin <URL-del-repositorio> // enlazamos el repositorio local
// “mi_proyecto” con el remoto recién
// creado (tendrá el alias “origin”)
git remote // Si responde “origin”, es que hemos enlazado correctamente
git push origin master // Subimos los cambios de la rama principal (master) al
// repositorio github remoto “origin”
Solución esperada: El archivo README.txt debe aparecer en el repositorio Github
remoto.
Crea el repositorio en Github, clónalo en tu pc, trabaja con él y sube los
cambios
Incluye en el mismo documento las capturas de pantalla de la consola de comandos
después de ejecutar cada apartado y la captura de tu repositorio local donde se vean los
archivos de tus compañeros.
1. Clona el repositorio existente (ya creado por el profesor) desde GitHub (ve antes a tu
carpeta raíz de los repositorios en local):
cd .. // Change Directory to parent
git clone <URL-del-repositorio-existente>
cd <nombre-del-repositorio>
4. Realiza cambios locales en el repositorio clonado:
echo "Hola mundo" >> MiNombreYPrimerApellido.txt
git add . // Añadir todo lo del actual directorio (carpeta) a la staging area
git commit -m "Agregar archivo con mi nombre"
git push origin master
// Esperar…
git pull origin master // Obtener el repositorio remoto y fusionarlo con el local
Solución esperada: Los archivos creados por los alumnos deben aparecer en el repositorio
Github remoto del profesor. Cada alumno también tendrá los archivos de sus compañeros
en su repositorio local.
