Rückblick auf 20 Jahre Git – immer noch seltsam, immer noch großartig

• Git ist ein Versionsverwaltungssystem, das vor 20 Jahren mit dem ersten Commit von Linus Torvalds begann
• Ursprünglich war es nur ein einfaches persönliches Projekt, entwickelte sich aber später zum weltweit am weitesten verbreiteten Versionsverwaltungssystem
• Der Autor ist Mitgründer von GitHub und war durch den Aufbau von Büchern und Community rund um Git tief an seiner Entwicklung beteiligt
• Anfangs war es nur ein einfaches Werkzeug zur Verwaltung von Verzeichnisinhalten, heute ist es ein zentrales Tool, das die Art der Softwareentwicklung verändert hat

Die Philosophie und Notwendigkeit von Git

• Git entstand in der Linux-Kernel-Community aus der Unzufriedenheit mit den Grenzen bestehender Versionsverwaltungstools
• Die frühere Art der Zusammenarbeit war verteilt und lokal geprägt, über Mailinglisten, Tarballs und Patch-Dateien
• Die damaligen SCM-Tools waren langsam, zentralisiert und ineffizient, weshalb ein auf Tarballs/Patches basierender Ansatz besser war
• Ein Tool namens BitKeeper war eine Alternative, doch wegen Lizenzproblemen begann die Entwicklung von Git
• Git wurde von Anfang an nicht als „Versionsverwaltungssystem“, sondern als Datenstruktur entworfen, um Patches und Tarballs besser zu handhaben

Der erste Commit von Git

• Der erste Commit war ein sehr grundlegendes Werkzeug zur Verfolgung von Verzeichnisinhalten
• Die damaligen Werkzeuge waren keine Befehle wie git commit, sondern Low-Level-Datenbanktools wie write-tree, commit-tree usw.
• Git besaß von Anfang an die folgenden Funktionen:
  • Speichern des Arbeitsverzeichnisses im Cache (update-cache), Umwandeln in einen Baum (write-tree) und Eintragen in die Datenbank
  • Speichern von Änderungen als Commit (commit-tree) und damit Aufbau einer Historie
  • Lesen und Vergleichen von Datenbankobjekten mit cat-file, read-tree, show-diff
• Linus betrachtete Git nur als Backend-„plumbing tool“ und wollte, dass die UI extern entwickelt wird

Beispiele für Content-Verteilung mit Git

• Der Autor nutzte Git 2005 in einem Startup namens Reactrix zur Verteilung digitaler Werbeinhalte
• Hunderte digitale Displays mussten jeweils unterschiedliche Kombinationen von Werbung erhalten, und Gits Content-Addressing löste dies effizient
• Das war ein kreatives Beispiel dafür, Git nicht für Codeverwaltung, sondern als Werkzeug zur Content-Verteilung einzusetzen
• Nick Hengeveld, einer der wichtigsten Mitwirkenden am frühen Git-Projekt, ergänzte Funktionen wie SSL und parallele HTTP-Übertragung
• Diese Erfahrung führte zur Erstellung von Git-Dokumentation, Websites und Büchern und mündete schließlich in GitHub

Die Entwicklung von Git-Befehlen und User-Tools

• In den frühen Tagen bestanden alle Git-Befehle aus skriptbasierten Low-Level-Tools und sahen noch ganz anders aus als heute
• Befehle wie git log, git rebase und git commit waren anfangs einfache Shell-Skripte und entwickelten sich nach und nach zu ihrer heutigen Form

Frühe Version von git log

• git log war ein einfaches Skript in der Form git-rev-list --pretty HEAD | less
• rev-list ist ein Tool zur Ausgabe von Commit-IDs, das bis heute existiert

Die Entstehung von git rebase

• Das Konzept „rebase“ entstand 2005 in einem E-Mail-Austausch zwischen Linus und Junio Hamano
• Junios Arbeitsweise bestand darin, den bisherigen HEAD zu verwerfen und die Arbeit auf Basis eines neuen HEAD fortzusetzen; dafür verwendete man den Ausdruck „rebase“
• Daraus entwickelte sich der git rebase-Befehl, wie wir ihn heute kennen

Der Ursprung von Octocat

• Octocat, das Symbol von GitHub, nahm seine Idee aus der Git-Strategie des „octopus merge“
• Die Strategie, mehrere Branches gleichzeitig zusammenzuführen, wurde „octopus“ genannt; davon inspiriert entstand in den frühen Tagen von GitHub die Figur Octocat

Gegenwart und Zukunft von Git

• Der Autor nutzt Git immer noch seinem ursprünglichen Zweck entsprechend als „stupid content tracker“
• Das Projekt GitButler nutzt Git, um die Historie von Projekten nachzuverfolgen und aufzuzeichnen
• Git ist weiterhin ein leistungsfähiges System zur Content-Verfolgung und verteilten Zusammenarbeit und kann auch künftig auf vielfältige Weise eingesetzt werden

• Alles Gute zum Geburtstag, Git. Immer noch seltsam, immer noch großartig

[aobamisaki]

Alles Gute zum 20. Geburtstag, Git.

[bobross0]

Herzlichen Glückwunsch

[girr311]

Alles Gute zum Geburtstag. Hör auf den Onkel und bleib lange, lange gesund.

[kaistj]

Alles Gute zum Geburtstag ^^

[crawler]

Das ist irgendwie ein seltsam mitreißender Post.

[GN⁺]

Hacker-News-Kommentare

• Die Geschichte über die Ursprünge von Git neigt dazu, Linus fast wie einen Propheten darzustellen

  • Der Blogbeitrag betont Linus’ menschliche Seite und erwähnt die anfänglichen Fehlversuche
  • Mercurial spielte ebenfalls eine wichtige Rolle, wird aber oft übersehen
  • Mercurial hatte von Anfang an eine UI und war mit einer an Subversion angelehnten UI benutzerfreundlich
  • Die Datenstruktur von Git eignet sich nicht gut für große Dateien
  • Ich halte Git nicht für unvermeidlich und hoffe, dass neue Alternativen erscheinen

• Um 2002 hatte ich die Idee, jeden Teil eines Projekts mit einem eindeutigen Hash-Code zu versehen

  • Ich habe das einem Softwareunternehmen vorgeschlagen, aber es stieß auf kein Interesse

• Ich begann, Git als Alternative zu ClearCase zu verwenden

  • Ich fing etwa 2007 an, Git zu nutzen, und schrieb Skripte, um die Umständlichkeit von ClearCase zu umgehen
  • 2008 begann ich, Patches zu Git beizusteuern, und lernte dabei viel über Open-Source-Beiträge
  • Trotz der komplexen CLI von Git hatte ich keine Schwierigkeiten bei der Nutzung
  • In meiner nächsten Stelle arbeitete ich auf Basis eines Forks von Chromium und wurde mit Git geschickt darin, Merge-Konflikte zu lösen
  • Ich war enttäuscht, dass GitHub zum wichtigsten Code-Review-Tool für Git wurde, halte Git aber dennoch für die bessere Wahl gegenüber Mercurial

• Es überrascht mich, dass Git erst 20 Jahre alt ist

  • Dass GitHub jünger als 20 Jahre ist, überrascht mich nicht, aber dass Git vor 2005 nicht existierte, ist schockierend
  • Ich habe nie andere Optionen zur Quellcodeverwaltung verwendet und frage mich, ob ich das jemals tun werde

• Es war interessant, den historischen Kontext zu erfahren

  • Auch ClearCase verwendete den Begriff "rebase", und man kann bestätigen, dass dies seit 1999 genutzt wurde
  • Das Rebase in ClearCase dauerte lange, daher war das sofortige Rebase in Git erstaunlich

• Ich wollte ein effizientes Werkzeug für eine Tarball-History-Datenbank bauen und hatte nicht die Absicht, ein Versionsverwaltungssystem zu entwickeln

• Ich habe erfahren, dass man Commits mit SSH-Schlüsseln signieren kann

  • Ich habe die Methode des Signierens mit SSH genutzt, um ein Problem unter OpenBSD zu lösen
  • Es fühlt sich nicht so an, als seien schon 20 Jahre vergangen, seit ich Arbeitselemente von CVS nach Git verlagert habe

• Danke für den nützlichen Artikel; ich empfehle außerdem ein Repository, das eine Einführung in die interne Struktur von Git enthält

• Ich fand die Meinung interessant, dass jemand einen Blogbeitrag über Zusammenarbeit über Mailinglisten schreiben möchte

• Von den vielen Versionskontrollsystemen hat Git die schlechteste Usability, ist aber trotzdem mein Lieblingssystem