Git is eating the world

Happy Birthday, Git! Unser Expertencheck zum 15. Geburtstag

Dominik Mohilo

© Shutterstock / Africa Studio (modifiziert),

Git Logo: © Jason Long / CC BY 3.0.

Das Versionskontrollsystem Git ist mittlerweile der de-facto-Standard, wenn es um die dezentralisierte Verwaltung von Source Code geht. Kaum ein anderes System hat in den vergangenen Jahrzehnten so einen heftigen Einfluss auf die Art und Weise gehabt, wie wir heute Software entwickeln. Zum 15. Geburtstag von Git haben wir mit sieben Experten über ihre Erfahrungen und Wünsche für die Zukunft gesprochen. Im großen Git-Expertencheck sprechen sie auch darüber, was Git noch fehlt und welche Features ihnen persönlich ans Herz gewachsen sind.

JAXenter: Hallo und danke, dass ihr euch die Zeit für unsere Geburtstagsaktion genommen habt! Git feiert heute seinen 15ten Geburtstag, daher zunächst einmal die Frage: Wie hat Git die Welt der Softwareentwicklung in den letzten 15 Jahren revolutioniert?

Die Git-Experten
Git - Batlogg

Jodok Batlogg – Co-Founder & CTO von Crate.io

Git - Guenther

Tobias Günther – Gründer und CEO von Tower

Git - Schulz

Marco Schulz – Freelancer

Git - Companys

Jordi Mon Companys – Sr. Product Marketing Manager bei GitLab

Git - OLeary

Brendan O’Leary – Sr. Developer Evangelist bei GitLab

Git - Stender

Daniel Stender – Geschäftsführer bei Pratis Cloud Solutions GmbH

Git - King

Jeff King – Distinguished Software Engineer bei GitHub

Jodok Batlogg: Die Art, wie teamorientierte Softwareentwicklung funktioniert, hat sich über diese Zeit revolutioniert. Das ganze agile Arbeiten, sei es mit Scrum, Kanban oder anderen Methoden, wäre undenkbar ohne die Funktionalitäten von Git – Git hat das agile, verteilte, teamorientierte arbeiten erst möglich gemacht. Es hat einen Grund, warum Entwickler, die von einer zur anderen Firma wechseln, sofort produktiv sein können. Man nimmt beispielsweise den „Git Feature Branch Workflow“ – und jeder weiß, wovon man redet. Sicher, es gab auch schon früher Tools wie diff, die wurden jedoch mehr zum Patchen von Dateien verwendet. Heutzutage wäre ein Leben ohne „Pull Requests“ nicht mehr denkbar.

Tobias Günther: Softwareentwicklung ist viel kollaborativer geworden – und dadurch auch professioneller. Vor einigen Jahren war Versionskontrolle noch ein „optionaler“ Schritt in vielen Entwicklungsteams. Heute gehört Versionskontrolle (was nun fast gleichbedeutend mit „Git“ ist) zum täglichen Toolset jedes Entwicklers dazu. Und mehr noch: Git ist auch die Basis für viele andere Services (wie z.B. Continuous Integration) geworden. Versionskontrolle mit Git hat sich also zur „Plattform“ entwickelt.

Marco Schulz: Hallo Dominik, gern doch. Nunja Source-Control-Management-Systeme gibt es schon seit einer ganzen Weile. Manch einer kennt CVS und dessen Schwerfälligkeit vielleicht noch aus Legacy-Projekten. Dagegen war der Nachfolger Subversion ein richtiger Formel-1-Bolide, ähnlich war es dann auch, als Git die Bühne betreten hatte.

Jordi Mon Company: Git hat solides, kostenfreies Open Source Quellcode-Management (SCM) für alle verfügbar gemacht. Entwickler aller Erfahrungsstufen, können ein leichtgewichtiges Binary herunterladen und ein paar Kommandos lernen (oder GitLab nutzen) und ihre Software-Projekte vorantreiben, ohne dass Git ihnen in die Quere kommt. Das Gegenteil ist der Fall: Git garantiert, dass die gesamte Historie des Projektes gespeichert wird. Hinzu kommt, dass sämtliche Kollaborationsmöglichkeiten mit Entwicklern aus der ganzen Welt ein natürlicher Teil des Projektes selbst sind. Git hat die Zusammenarbeit und die graduelle Softwareentwicklung allen zugänglich gemacht und die Welt damit im Sturm erobert.

Brendan O’Leary: Vor Git waren die meisten Tools für das Source-Code-Management (SCM) zentralisiert. Unterm Strich hieß das, dass alle Teilnehmer an einem Projekt sich auf einem zentralen Server anmelden mussten, um daran zu arbeiten. Git hat gezeigt, dass man auch verteilt arbeiten kann, sogar mit großen Codebasen wie etwa dem Linux-Kernel. Diese verteilte Natur war ein treibender Faktor für die Open-Source-Kultur, die wir in den letzten 15 Jahren gesehen haben.

Daniel Stender: Git hat sich aus verschiedenen Gründen schlicht als Standardplattform für Open Source etabliert.

Jeff King: Gits Einfluss auf die Entwicklung von Open-Source-Software ist deshalb so groß, weil dessen dezentralisierte Natur die gleichen Tools für jeden verfügbar macht. Egal, ob man regelmäßig an einem Projekt mitarbeitet oder es sich zum ersten Mal ansieht: Alle haben die gleichen Informationen und Werkzeuge an der Hand. Für Entwickler bedeutet das eine große Flexibilität, denn dadurch, dass sie die Tools und Daten lokal vorliegen haben, können sie ihren eigenen, individuellen Workflow erstellen – ganz unabhängig voneinander.

Git bewegte auch die Softwareindustrie dazu, besser zu kommunizieren. Versionskontrollsysteme haben es den Entwicklern immer erlaubt, ihre Änderungen zu beschreiben, aber ohne entsprechende Tools für die Untersuchung der Historie haben viele nicht den Wert darin gesehen. Git stellt schnelle und flexible Werkzeuge bereit, um die Commits zu finden, die bestimmten Code oder sogar ein bestimmtes beobachtetes Verhalten beinhalten.

Git is eating the world – Mit Hilfe von GitHub und GitLab

JAXenter: Git hat – auch wegen der Popularität von GitHub und GitLab – den Kampf um die Vorherrschaft in der Versionsverwaltung quasi gewonnen. Warum gibt es nichts Vergleichbares mit Mercurial oder Subversion, bzw. warum nichts so erfolgreiches?

Jodok Batlogg: Ich erinnere mich gut an die Zeiten, als ich mit CVS – eines der ersten Systeme zur Versionsverwaltung von Software – gearbeitet habe. Ebenso der kurzzeitige Wechsel auf SVN, das zum ersten Mal auch über das HTTP(S)-Protokoll mit WebDAV arbeiten konnte. Die Freundschaft war jedoch von kurzer Dauer, mein erster Commit auf GitHub war im September 2009.

Warum sich Git durchgesetzt hat? Wenn ich mich auf zwei Gründe beschränke – dann ist das zum Einen der Fakt, dass das Tool einfach alles konnte. Die Linux-Kernel-Entwicklung ist eines komplexesten Softwareprojekte überhaupt und hat die Funktionalität von Git von Anfang an mitgestaltet. Dadurch war sichergestellt, das die Funktionalität rock-solid ist. Zum Anderen findet das git Command Line Tool die richtige Balance zwischen Power-Usern, die von bi-sect über cherry-picking weiß der Teufel was machen, und Einsteigern, die mit pull, commit und push durchkommen. Ok, ein dritter Grund: Plattformen wie GitLab oder GitHub haben das ganze super consumable gemacht. Mit Webinterface, als SaaS – und trotzdem die volle Power unter der Haube.

Tobias Günther: Eine neue Technologie (die Git vor einigen Jahren noch war) steht und fällt immer mit dem Ökosystem und der Community, die sie entwickelt. Und GitHub war nunmal ein klarer Glücksfall für Git, da es genau den Nerv der Zeit getroffen hat. Ein weiterer Grund sind natürlich auch die Konzepte, die Git verfolgt: Dezentralität bringt viele Vorteile (z.B. gegenüber Subversion), genauso wie die hervorragende Umsetzung von Branching, Staging Area, Stashing, etc. im Vergleich zu anderen dezentralen Systemen wie Mercurial.

„Git ist technisch einfach weiterentwickelter als Subversion.“

Marco Schulz: Lässt man einmal den großen Namen außen vor, der so eng mit Git verknüpft ist, gibt es viele Punkte, die beim Entwurf des Werkzeugs konsequent richtig gemacht wurden. Viele Erfahrungen, die Linus Torwalds durch seine Arbeit an Linux gesammelt hat, sind in das Design mit eingeflossen. Vergleicht man einmal eine Revision in SVN mit Git, so stellt man fest, dass der Identifier des Commits in Git eine UUID ist und Subversion lediglich ein einfaches Auto Increment nutzt. Diese unabhängigen UUIDs bringen die enorme Flexibilität, welche wir beim Branchen und Mergen schätzen. Ein anderes Beispiel ist die zu akademische Lösung, mit der einst IBM Synergy für stabile Builds sorgen wollte. Git hat mit den Pull Requests hier einen weitaus leichtgewichtigeren Prozess etablieren können.

Jordi Mon Company: In Bezug auf Subversion gibt es da einige Gründe. SVN ist ein zentralisiertes Versionskontrollsystem, wodurch der verteilte, asynchrone Teil von Git für die Nutzer nicht verfügbar ist. Das spricht schon sehr für Git. GitLab bietet überdies eine komplette DevOps-Plattform, die auf Git basiert, wodurch Git zu einem Tool für alle Bedürfnisse in Sachen Softwareentwicklung und -Deployment wird. SVN wäre dazu nicht in der Lage.

Daniel Stender: Git ist technisch einfach weiterentwickelter als Subversion. Dabei spielt auch keine Rolle, dass SVN wesentlich einfacher zu bedienen ist. Mercurial und Bazaar bieten zum Teil vergleichbaren Konzepte, stehen aber vielleicht vom Gesamtpaket her nicht so gut da. Eine wichtige Rolle bei der Frage, warum die Karawane dahin gezogen ist, spielen aber auch äußere Faktoren.

Jeff King: Gits Datenmodell hat sich als schnell und flexibel herausgestellt. Dies hat es ermöglicht, dass Projekte von vielen verschiedenen Größen und mit unterschiedlichen Arbeitsabläufen es übernehmen. Es wurde auch schon früh von prominenten Projekten genutzt: dem Linux-Kernel und dem Ökosystem von Ruby. Das gab Git schnell eine große User Base und diente anderen in der Softwareentwicklung als Empfehlung.

„Git ist nahe der Perfektion“

JAXenter: Welche Features fehlen Git aktuell noch?

Jodok Batlogg: Puh, ehrlich gesagt fällt mir hier nicht wirklich etwas ein!

Tobias Günther: Ich denke nicht, dass Git noch mehr Features braucht: schließlich ist und bleibt es ein Versionskontrollsystem! Die Aufgabe, die ganze Power aus Git für Entwickler nutzbar zu machen, liegt eher beim Ökosystem – bei Plattformen wie GitHub oder bei Tools wie Tower.

Marco Schulz: Ganz klar stört mich der komplizierte Mechanismus, den man in Gang setzen muss, um seine Tippfehler aus einer Commit Message herauszubekommen. Das ging in SVN mit einem kleinen Hook Script wesentlich angenehmer.

„Die Repositories werden größer und größer. Man sollte sich also langsam überlegen, wie Git damit umgehen kann.“

Jordi Mon Company: Ich würde behaupten, dass Git sehr nah an der kompletten Fertigstellung ist. Natürlich können noch alle möglichen Verbesserungen in Sachen Usability und Performance implementiert werden, doch es gibt nur einige wenige Dinge, die in Git fehlen. Wäre Git noch flexibler und fähig, zentralisiert auf einem Client-Server zu laufen, könnte dies die Verbreitung in bestimmten Industriezweigen noch vergrößern. Liest man allerdings die Diskussionen in der Git-Community, ist es eher unwahrscheinlich, dass das je passieren wird.

Brendan O’Leary: Ich denke, dass Git es an wenig mangeln lässt. Die Simplizität und Verlässlichkeit von Git ist das, was es so beliebt macht. Ich denke allerdings, dass das Management mehrerer Projekte mit gemeinsamen Abhängigkeiten noch eine gewisse Herausforderung darstellt. Die Usability von Git-Submodulen könnte weiter verbessert werden und ein wenig Arbeit am Dependency-Management könnte auch für Git selbst einige interessante Änderungen bereithalten.

Daniel Stender: Eingebaute künstliche Intelligenz für das automatische Lösen von Merge Conflicts.

Jeff King: Die Repositories werden größer und größer. Man sollte sich also langsam überlegen, wie Git dahingehend skalierbar ist und wie man Entwicklern die Möglichkeit nicht versperrt, auf diese zuzugreifen.

Experten und ihre Lieblingsfunktionen

JAXenter: Was ist euer Lieblingsfeature/-Befehl in Git?

Jodok Batlogg: Über die Jahre bin ich vom Entwickler zum CTO degradiert. Daher ist mein Standard-Flow alles, was ich nutze. Und den hat glücklicherweise mein langjähriger Mitarbeiter und Freund Christian („chaudum“) vor langer Zeit (2015) festgehalten.

Tobias Günther: Ich liebe an Git, dass man damit so gut wie jeden Fehler rückgängig machen kann. Das Set an Undo-Features“ ist wirklich gewaltig und hilft Entwicklern, Nachts besser zu schlafen 😉

Marco Schulz: Für meine tägliche Arbeit benötige ich öfter die Möglichkeit, das History-Objekt mit eigenen Selektionen in Textdateien zu schreiben. Das hilft sehr, um sich in neuen Projekten einen Überblick zu verschaffen.

Jordi Mon Company: git rebase

Brendan O’Leary: Es mag nicht das spektakulärste Feature sein, aber git reset hat immense Power. git reset stellt alles bereit, was ich eine „Magische Zeitmaschine“ nenne. Es erlaubt dem User zu verstehen, was in der Vergangenheit passiert ist und speichert vorige Arbeit ab, falls man einen Fehler macht.

Daniel Stender: $ git checkout -b mybranch

Jeff King: Praktisch alles, was mit Software-Archäologie zu tun hat. Wenn ich einen Bug in Git untersuche, durchforste ich oft die letzten 15 Jahre an Änderungen, um herauszufinden, warum der Code so aussieht, wie er aussieht. git blame (und besonders der tig Blame Viewer), git bisect und git log -S sind alles integrale Bestandteile meiner Toolbox.

Es mag nicht das spektakulärste Feature sein, aber git reset hat immense Power.

Ist Git das Ende der Fahnenstange?

JAXenter: Ein Blick in die Zukunft – was kommt nach Git?

Jodok Batlogg: Ich glaube das ganze in Echtzeit – sprich alle Branches sind überall synchron. Das wäre cool. Oder „Micro-Merges“, die permanent passieren. Inclusive deployment to production!

Tobias Günther: Diese Art von Kristallkugel hätte ich auch gerne 😉 Vielleicht geht es gar nicht darum, was nach Git kommt, sondern was neben Git noch entsteht. In den letzten Jahren sind so viele spannende Apps, Tools und Services auf der Basis von Git entstanden, dass ich eher hieran glaube!

Marco Schulz: Auch wenn heutzutage für Entwickler SCM-Tools wie Git essentiell und diese auch Teil jeder Stellenausschreibung sind, wird bei der Ausbildung in vielen Universitäten kein Wert darauf gelegt, den Studenten die Mächtigkeit solcher Werkzeugen nahezubringen. Hier ist noch viel Nachholbedarf. Ich denke auch, eine künftige Evolution von SCM-Systemen könnte der Umgang mit Office-Dateien sein. Wir werden sehen, ob sich jemand dieser Thematik annehmen wird.

Jordi Mon Company: Nichts. Git für alles!

„Git löst das die Aufgabenstellung der Versionskontrolle mehr oder weniger optimal.“

Brendan O’Leary: Die ultimative Herausforderung für Git ist das Management großer Dateien und Anhänge. Im Zeitalter ultra-realistischer Videospiele, Augmented Reality (AR) und Virtual Reality (VR) steigt das Bedürfnis von Entwicklern, große Zahlen von besonders großen Dateien zu verwalten, immer weiter an. Traditionell ist Git für solche Use Cases nicht besonders gut geeignet und Tools wie Git LFS funktionieren nicht so gut mit anderen Git-Konzepten zusammen. Die neuen Git-nativen Features mit Shallow Clones und Partial Clones haben da geholfen.

Daniel Stender: Git löst das die Aufgabenstellung der Versionskontrolle mehr oder weniger optimal. Was kommt nach Versionskontrolle?

Jeff King: Git brachte der Welt dezentralisierte Versionskontrolle, aber Softwareentwicklung ist einfach mehr, als nur Quellcode. Ich würde gerbe mehr dezentralisierte Tools für Diskussionen, Issue Tracking und alle anderen Aufgaben sehen, die Entwickler täglich haben.

Unsere Experten

Jodok Batlogg ist weithin bekannt für seine umfassende Expertise auf den Feldern Open-Source und Big Data. Er ist Mitgründer und CTO von Crate.io. Vor der Gründung von Crate.io entwickelte Jodok reine Open-Source-Datenbanken für datenintensive Applikationen. Er war CTO der deutschen sozialen Netzwerke SchülerVZ, StudiVZ und MeinVZ. Zuvor war Jodok CTO bei Sevenload, einem Social-Video-Netzwerk für kostenlose Premium-TV-Inhalte, Musikvideos und interaktives WebTV. Als CEO von Lovely Systems half Jodok Medien-Start-ups bei der Skalierung. Jodok leitete die Plone Foundation und Zope Foundation, zwei Stiftungen zur Förderung der jeweiligen Open-Source-Projekte. Zwischenzeitig arbeitete er als Dozent an der Fachhochschule Vorarlberg. Jodok Batlogg hat einen Bachelor of Science in Elektronik-, Meß- und Regeltechnik an der Interstaatlichen Ingenieurschule für Technik Buchs. Er hat sein Diplom für Telematik an der Universität Karlsruhe erworben. An der Harvard Business School absolvierte er das Executive Education Program “Launching New Ventures”.

 

Tobias Günther ist Gründer und CEO von „Tower“, der bekannten Developer-App für Git, die bei über 100.000 Entwicklern weltweit im Einsatz ist und die Arbeit mit Git produktiver und einfacher macht.

 

Marco Schulz studierte an der HS Merseburg Diplominformatik. Sein persönlicher Schwerpunkt liegt auf Softwarearchitekturen, der Automatisierung des Softwareentwicklungsprozesses und dem Softwarekonfigurationsmanagement. Seit über fünfzehn Jahren entwickelt er für namhafte Unternehmen auf unterschiedlichen Plattformen umfangreiche Webapplikationen. Er ist freier Consultant, Trainer und Autor verschiedener Fachartikel.

 

Jordi Mon Companys is Sr. Product Marketing Manager at GitLab. He is a product person interested in software development tooling and culture as well as meaningful and lasting design. Developer productivity, open source, DevOps and culture are some of his passions.

 

Brendan O’Leary is a Senior Developer Evangelist for GitLab who connects with developers, contributes to open source projects, and shares his work with about cutting-edge technologies on conference panels, meetups, in contributed articles and on blogs

 

Daniel Stender hat als freier DevOps- und Linux-Engineer für große Kunden im Bereich Banken und Finanzdienstleistung gearbeitet. Er ist Geschäftsführer der Pratis Cloud Solutions GmbH in Hannover (Homepage).

 

Jeff King is a Distinguished Software Engineer at GitHub, where he has worked since 2011 on scaling and maintaining Git repository storage. He’s been an active contributor to the Git project since 2006.
Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: