Thomas Claudius Huber Trivadis AG

„Der Umgang mit Git ist nicht schwer. Nur die Denkweise ist im Vergleich zu Klassikern wie Subversion anders.“

Git hat sich in den letzten Jahren zum Favoriten für die Versionierung von Quellcode entwickelt. Insbesondere die Tatsache, dass Git entwickelt wurde, um die Open-Source-Entwicklung mit vielen Entwicklern optimal zu unterstützen, macht es heute zum populärsten Version Control System (VCS). Doch immer noch fehlen vielen Entwicklern die Grundlagen, um Git sicher und effizient einzusetzen. Neben den Grundlagen von Git zeigt der Artikel, wie Entwickler „fetchen“, „pullen“, „pushen“, „committen“ und souverän mit Tags und Branches umgehen.

Damit Entwickler an einer gemeinsamen Codebasis arbeiten können, wurden zentralisierte Versionskontrollsysteme (VCS) eingeführt – auch CVCS genannt (centralized VCS). Zu diesen Systemen zählen Subversion oder auch das vom Team Foundation Server (TFS) verwendete Team Foundation Version Control (TFVC). Ein solches zentralisiertes VCS hat einen zentralen Server, der die versionierten Dateien enthält. Entwickler checken aus diesem Server aus und speichern Änderungen auf den Server zurück. Jeder kann zentral sehen, wer was gemacht hat, und es lassen sich auch Einstellungen vornehmen, wer überhaupt etwas machen darf. So weit, so gut für eine gute Zusammenarbeit. Allerdings gibt es ein Problem mit den zentralisierten VCS: Entwickler checken nur einen Bruchteil aus – nämlich die Dateien zu einer bestimmten Version. Das führt insbesondere dann oft zu Problemen, wenn der Server nicht da ist. Welcher Entwickler hat während einer Zugfahrt nicht seine Erfahrungen mit TFS gemacht? Lokal ohne Serververbindung kann nicht eingecheckt werden, es kann kein Branch erstellt und nicht geschaut werden, was von anderen Teammitgliedern an einer Datei geändert wurde, da die Historie lokal nicht verfügbar ist usw. In einem Satz: Ohne Server lässt es sich einfach nicht richtig arbeiten. Neben diesem Problem haben zentralisierte VCS einen weiteren Schwachpunkt: den zentralen Server. Jede IT-Abteilung macht natürlich ihre seriösen Backups. Man stelle sich nur vor, das Backup hat nicht richtig funktioniert und die Festplatte des Servers hat ihre besten Zeiten hinter sich. Dann sind die Daten weg.

Genau an diesen Problempunkten von zentralisierten VCS setzen verteilte VCS an – auch als distributed VCS oder kurz DVCS bezeichnet. Zu den verteilten VCS gehört Git. Bei einem verteilten VCS checken Entwickler nicht nur die Dateien zu einer bestimmten Version aus, es wird vielmehr das komplette Repository lokal gespiegelt. Somit hat jeder Entwickler lokal ein eigenes, komplettes Repository, das er mit einem beliebigen anderen Repository abgleichen kann. Auf diese Weise kann man lokal committen, die Historie anschauen, Branches erstellen und alles andere tun, was man sich von einem VCS wünscht, ohne dass der Server verfügbar sein muss. Zudem ist jedes lokale Repository ein gültiges Backup für den Server, da es eine Spiegelung des Server-Repositories ist.

Aber es kommt noch besser: Ein lokales Repository lässt sich mit einem oder auch mehreren beliebigen anderen Repositories abgleichen. Somit können beispielsweise Änderungen an einem lokalen Repository auf mehrere verschiedene Server-Repositories „gepusht“ werden. Bevor dieser Artikel mit den Grundlagen zum Verwenden von Git und dem Erstellen eines Git Repositories beginnt, gibt es noch eine kleine Geschichtsstunde.

Wie Git entstanden ist

Git ist ein aus der Linux-Community entstandenes, verteiltes VCS. Wie sich jeder Entwickler vorstellen kann, ist der Linux Kernel ein riesiges Open-Source-Projekt. Zum Verwalten und Versionieren des Quellcodes wurde ab 2002 ein verteiltes VCS namens BitKeeper eingesetzt. 2005 wurde der hinter dem Linux Kernel steckenden Community jedoch der Status entzogen, das von einer kommerziellen Firma vertriebene BitKeeper weiterhin kostenfrei nutzen zu dürfen. Basierend auf den Erfahrungen mit BitKeeper entschied sich die Linux-Community, aber vor allem Linux-Erfinder Linus Torvalds, ein eigenes, verteiltes VCS zu entwickeln. Es wurden unter anderem folgende Anforderungen festgelegt:

  • Es soll schnell sein
  • Es soll ein einfaches Design haben
  • Es soll parallele Entwicklung mit tausenden von Branches unterstützen
  • Es soll in verteilten Umgebungen funktionieren und offlinefähig sein
  • Es soll große Projekte, wie den Linux Kernel, effizient verwalten können

Im Jahr 2005 war es soweit: Das eigenentwickelte, verteilte VCS erschien unter dem Namen Git. Git ist sehr schnell und kann große Projekte stemmen, wie zum Beispiel den Linux Kernel. Auch das ausgeklügelte Konzept zum Erstellen von Branches erlaubt eine sehr starke, nichtlineare Entwicklung.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 3.17 - "Volle Kontrolle"

Alle Infos zum Heft
579767079Wie .NET-Entwickler die Git-Grundlagen einfach meistern
X
- Gib Deinen Standort ein -
- or -