20 años de Git: una mirada atrás a una herramienta que sigue siendo extraña y sigue siendo genial

• Git es un sistema de control de versiones que comenzó hace 20 años, cuando Linus Torvalds hizo el primer commit
• Originalmente era un proyecto personal simple, pero después creció hasta convertirse en el sistema de control de versiones más usado en todo el mundo
• El autor es cofundador de GitHub y ha estado profundamente involucrado en la evolución de Git, construyendo libros y comunidades relacionadas con Git
• Al principio era una simple herramienta para gestionar el contenido de directorios, pero ahora se ha convertido en una herramienta clave que cambió la forma de desarrollar software

La filosofía y la necesidad de Git

• Git nació en la comunidad del kernel de Linux por la frustración con las limitaciones de las herramientas de control de versiones existentes
• La forma tradicional de colaboración era distribuida y local, usando listas de correo, tarballs y archivos patch
• Como las herramientas SCM de ese momento eran lentas, centralizadas e ineficientes, el enfoque basado en tarball/patch resultaba mejor
• Una herramienta llamada Bitkeeper era una alternativa, pero debido a problemas de licencia comenzó el desarrollo de Git
• Desde el principio, Git no fue diseñado como un "sistema de control de versiones", sino como una estructura de datos para manejar mejor patches y tarballs

El primer commit de Git

• El primer commit era una herramienta muy básica para rastrear contenido de directorios
• En ese momento, en lugar de comandos como git commit, las herramientas eran utilidades de base de datos de bajo nivel como write-tree y commit-tree
• Desde el principio, Git tenía funciones como las siguientes:
  • Guardar el directorio de trabajo en la caché (update-cache) y convertirlo en un objeto de árbol (write-tree) para registrarlo en la base de datos
  • Guardar los cambios en forma de commit (commit-tree) para crear historial
  • Leer y comparar objetos de la base de datos con cat-file, read-tree y show-diff
• Linus veía Git solo como una "herramienta de plomería" backend, y quería que la UI se construyera externamente

Un caso de uso de Git para distribución de contenido

• En 2005, el autor usó Git en una startup llamada Reactrix para distribuir contenido publicitario digital
• Cientos de pantallas digitales debían tener distintas combinaciones de anuncios, y la funcionalidad de direccionamiento por contenido de Git resolvió esto de forma eficiente
• Fue un caso creativo de uso de Git no como herramienta para gestionar código, sino como herramienta de distribución de contenido
• Nick Hengeveld, uno de los principales contribuidores del proyecto Git en sus inicios, añadió funciones como SSL y transferencia HTTP en paralelo
• Esta experiencia llevó a crear documentación, sitios web y libros sobre Git, y finalmente desembocó en GitHub

La evolución de los comandos de Git y las herramientas para usuarios

• En los primeros tiempos, todos los comandos de Git eran herramientas de bajo nivel basadas en scripts, y eran muy distintos a los actuales
• Comandos como git log, git rebase y git commit también eran al principio simples scripts de shell, y luego evolucionaron gradualmente hasta adoptar su formato actual

La versión inicial de git log

• git log era un script simple con la forma git-rev-list --pretty HEAD | less
• rev-list es una herramienta para imprimir IDs de commit que todavía existe hoy

La aparición de git rebase

• El concepto de rebase nació en 2005 en una conversación por correo entre Linus y Junio Hamano
• La forma de trabajar de Junio consistía en descartar el HEAD existente y seguir trabajando sobre un HEAD nuevo, y a eso lo llamó "rebase"
• Esto evolucionó hasta convertirse en el comando git rebase que conocemos hoy

El origen de Octocat

• Octocat, el símbolo de GitHub, tomó su idea de la estrategia de "octopus merge" en Git
• La estrategia de fusionar varias ramas al mismo tiempo se llamaba "octopus", y en los primeros días de GitHub esa palabra inspiró la creación del personaje Octocat

El presente y el futuro de Git

• El autor sigue usando Git según su propósito original, como un "stupid content tracker"
• El proyecto GitButler lo está usando para rastrear y registrar el historial de proyectos
• Git sigue siendo un potente sistema distribuido y de rastreo de contenido, y probablemente podrá usarse de muchas más maneras en el futuro

• Feliz cumpleaños, Git. Sigues siendo una herramienta extraña y sigues siendo genial

[aobamisaki]

Feliz 20.º cumpleaños, Git.

[bobross0]

Felicitaciones

[girr311]

Feliz cumpleaños. Hazle caso a los mayores y mantente sano por muchos, muchos años.

[kaistj]

Feliz cumpleaños ^^

[crawler]

Qué publicación tan extrañamente emocionante.

[GN⁺]

Opiniones en Hacker News

• La historia sobre el origen de Git tiende a retratar a Linus como si fuera un profeta

  • La entrada del blog destaca el lado humano de Linus y menciona los tropiezos iniciales
  • Mercurial también jugó un papel importante, pero a menudo se pasa por alto
  • Mercurial tenía UI desde el principio y, con una UI similar a la de Subversion, era fácil de usar
  • La estructura de datos de Git no es adecuada para archivos grandes
  • No creo que Git fuera inevitable, y espero que aparezcan nuevas alternativas

• Alrededor de 2002, tuve la idea de etiquetar cada parte de un proyecto con un código hash único

  • Se lo propuse a una empresa de software, pero no mostró interés

• Empecé a usar Git como alternativa a ClearCase

  • Comencé a usar Git alrededor de 2007 y escribí scripts para resolver lo engorroso que era ClearCase
  • En 2008 empecé a contribuir parches a Git y aprendí mucho sobre las contribuciones al código abierto
  • A pesar del CLI complejo de Git, no tuve dificultades para usarlo
  • En mi siguiente trabajo, trabajé sobre un fork de Chromium y me volví hábil resolviendo conflictos de merge con Git
  • Me decepcionó que GitHub se convirtiera en la principal herramienta de revisión de código para Git, pero sigo pensando que Git fue una mejor opción que Mercurial

• Sorprende que Git tenga solo 20 años

  • Que GitHub tenga menos de 20 años no sorprende, pero es impactante que Git no existiera antes de 2005
  • Nunca he usado otras opciones de control de código fuente, y me pregunto si lo haré en el futuro

• Fue interesante conocer el contexto histórico

  • ClearCase también usaba el término "rebase", y se puede comprobar que se usaba desde 1999
  • El rebase de ClearCase tomaba mucho tiempo, así que el rebase instantáneo de Git fue sorprendente

• Quería crear una herramienta eficiente de base de datos de historial de tarballs, y no pretendía hacer un sistema de control de versiones

• Me enteré de que se pueden firmar commits con claves ssh

  • Usé la firma con ssh para resolver problemas en OpenBSD
  • No parece que hayan pasado ya 20 años desde que moví elementos de trabajo de CVS a Git

• Gracias por el artículo útil; recomiendo un repositorio que incluye una introducción a la estructura interna de Git

• Me pareció interesante la idea de querer escribir una entrada de blog sobre la colaboración mediante listas de correo

• Entre varios sistemas de control de código fuente, Git tiene la peor usabilidad, pero sigue siendo mi sistema favorito