¡¡¡¡¡BIENVENIDOS!!!!

Semana 003

• Evolución de los SCV
  

  Sistema de control de versiones LOCAL

  Cuando un desarrollador guarda avances de un proyecto manualmente (por ejemplo, creando carpetas con la fecha), puede cometer errores como:

  • Olvidar dónde está una copia.

  • No saber qué cambios tenía.

  • Borrar o sobrescribir versiones sin querer.

  Para evitar esto, surgieron los Sistemas de Control de Versiones (SCV). Los primeros VCS eran locales: guardaban un registro de los cambios directamente en la computadora del desarrollador, como una base de datos con el historial del proyecto.

  

  Sistema de control versiones CENTRALIZADO (SCVC)

  Cuando los proyectos se desarrollan en equipo, se necesita un control de versiones compartido. Por eso surgieron los sistemas centralizados (SCVC), donde un único servidor guarda todo el historial del proyecto y los desarrolladores trabajan conectándose a él.

  Ventajas:

  • Permiten trabajar en equipo de forma organizada.

  • Se puede ver qué aportó cada integrante.

  • El administrador tiene control total sobre los permisos.

  Desventajas:

  • Si el servidor falla, nadie puede trabajar ni guardar cambios.

  • Si se pierde la base de datos del servidor y no hay backup, se pierde todo.

  En resumen: son mejores que los VCS locales, pero dependen de un único servidor.

  

  Sistema de control de versiones DISTRIBUIDO (SCVD)

  Los sistemas distribuidos solucionan las fallas de los centralizados. En estos, cada vez que un desarrollador descarga el proyecto, se copia todo el repositorio, con su historial completo. Es decir, cada desarrollador tiene su propia copia completa del proyecto.

  Ventajas:

  • Si el servidor se cae, cualquier copia local puede restaurarlo.

  • Cada descarga es también una copia de seguridad.

  • Permiten definir flujos de trabajo más flexibles para equipos.

  Desventajas:

  • Requieren mayor conocimiento para manejar conflictos y definir bien cómo se va a trabajar.

  En resumen: son más seguros y versátiles, aunque un poco más complejos de usar que los centralizados.

  

• ¿Qué es GIT?
  

  Entre 1991 y 2002, el núcleo del Sistema Operativo Linux se mantenía con parches y archivos. En 2002, comenzó a usarse el SCVD propietario BitKeeper, pero en 2005 se rompió la relación con la empresa que lo desarrollaba. Ante esto, Linus Torvalds creó su propio sistema de control de versiones: Git.

  Objetivos de Git:

  • Alta velocidad

  • Diseño simple

  • Soporte para desarrollo no lineal (muchas ramas)

  • 100% distribuido

  • Eficiencia en proyectos grandes (como el núcleo de Linux)

  Desde entonces, Git se volvió uno de los sistemas más usados por ser rápido, eficiente, fácil de aprender y manejar muy bien las ramas de desarrollo.

  ---

  ¿Cómo funciona Git internamente?

  A diferencia de otros SCV que registran cambios en los archivos (como por ejemplo el SCV Subversion), Git guarda "instantáneas" del proyecto completo. Si un archivo no cambia, simplemente enlaza a la versión anterior.

  Esto lo convierte en un mini sistema de archivos con herramientas muy potentes de control de versiones.

  En esta imagen, puedes observar el modelo de funcionamiento de SCVD tradicionales:

  

  🔍 Qué representa:
  Cada archivo (A, B, C) se representa como una serie de diferencias (deltas) almacenadas en orden cronológico.

  🧠 Cómo funciona:

  • El sistema guarda una versión base del archivo (versión 1).

  • Luego, en cada nueva versión, se guarda solo el cambio (delta) que se hizo respecto a la anterior.

  • Para reconstruir una versión específica, el sistema tiene que aplicar los deltas desde la versión base.

  ✅     Ventaja: Usa menos espacio, ya que solo guarda los cambios.
  ❌ Desventaja: Requiere más procesamiento para reconstruir estados anteriores, y muchas operaciones dependen del servidor (menos eficiente localmente)

  En cambio, la siguiente imagen representa el modelo de GIT:

  

  🔍 Qué representa:
  Git no guarda deltas, sino instantáneas completas del estado del proyecto cada vez que se hace un commit.

  🧠 Cómo funciona:

  • Cada versión (commit) es como una foto del proyecto en ese momento.

  • Si un archivo no cambió, Git no lo guarda de nuevo, sino que apunta al mismo archivo de la versión anterior.

  • Por ejemplo, el archivo B no cambia en la versión 2, así que Git lo reutiliza sin volver a almacenarlo.

  ✅ Ventajas:

  • Es muy rápido para navegar entre versiones (todo está en local).

  • Ideal para ramas y desarrollo no lineal.

  • Alta integridad y seguridad (usa sumas de verificación).

  ❌ Desventaja: Puede parecer complejo al principio por su modelo distinto.

  ---

  Consecuencias del modelo de Git

  1. Casi todo es local:
     El desarrollador puede trabajar sin conexión, revisar el historial, comparar versiones, etc., sin necesidad de conectarte al servidor.

  2. Integridad garantizada:
     Usa checksums (SHA-1) para detectar cualquier cambio, corrupción o pérdida de datos. Nada se guarda sin validación.

  3. Siempre agrega información:
     Casi todo lo que se realiza con Git agrega datos, por lo que es difícil perder algo importante, siempre y cuando el desarrollador confirme el cambio y realice un push regularmente.

   

• Los tres estados de GIT (¡¡¡ Lo más importante!!!)
  

  En Git, todo archivo puede estar en uno de tres estados:

  1. 🔧 Modificado (Modified):
     Cambiaste el archivo, pero todavía no lo marcaste para incluirlo en el próximo commit.

  2. ✅ Preparado (Staged):
     Marcaste el archivo modificado para ser incluido en el siguiente commit. Está en el área de preparación.

  3. 📦 Confirmado (Committed):
     Los cambios están guardados de forma segura en la base de datos del repositorio Git (git directory).

  ---

  Los tres espacios de trabajo de Git

  1. Git Directory (Repositorio Git):
     📁 Donde Git guarda todo el historial y metadatos. Es el “cerebro” del sistema.
     👉 Es lo que se clona cuando obtiene un proyecto.

  2. Working Directory (Directorio de trabajo):
     🖥️ Es la versión actual del proyecto que el desarrollador tiene en su máquina.
     👉 En este espacio el desarrollador edita, borra o agrega archivos.

  3. Staging Area (Área de preparación):
     🕒 Es donde se colocan los archivos que el desarrollador quiere confirmar en el próximo commit.
     👉 Se arma una especie de “lista de lo que va al próximo commit”.

  ---

  Flujo de trabajo en Git

  La combinación de estados y los flujos de trabajo que ofrece git generan un flujo de trabajo que se puede resumir con esta imagen:

  

  📌 Representado por las flechas rojas en la figura:

  1. 🔄 Checkout:
     Trae archivos desde el repositorio Git al directorio de trabajo.

  2. ✍️ Esto puede modificar los archivos en el directorio de trabajo.

  3. ➕ Stage files:
     Agrega los archivos modificados al staging area.

  4. 📝 Commit:
     Confirma los archivos preparados, que pasan al repositorio Git como parte del historial.

  Lo anterior también se puede describir mediante la siguiente tabla:

  

• ¿Qué es GitHub?

  GitHub es una plataforma en línea que permite alojar repositorios Git. No es lo mismo que Git.

  🔹 Git es una herramienta que se instala localmente y se usa para el control de versiones.
  🔹 GitHub es un servicio en la nube que facilita compartir, colaborar y gestionar proyectos basados en Git.

  Diferencias claves entre Git y GitHub

  

  Funcionalidades principales de GitHub

  • Repositorios en la nube: Es posible almacenar y compartir código desde cualquier lugar.

  • Wiki integrada: Ideal para documentar proyectos con control de versiones.

  • Sistema de Issues: Para reportar errores, sugerencias o tareas pendientes. Similar a un sistema de tickets.

  • Revisión de código: Los miembros del equipo pueden comentar líneas específicas de código.

  • Gestión de ramas: Permite a los desarrolladores visualiza y comparar los cambios entre distintas ramas fácilmente.

  • Pull Requests: Permite proponer cambios y discutirlos antes de integrarlos al proyecto principal.

  • Accesibilidad: Los repositorios públicos son gratuitos, pero es posible establecer una privacidad o control de acceso, aunque para ello se necesita una cuenta paga.

• Clases grabadas

• Actividades