Lernpfad:Einführung in Git/1

Nächster Schritt

Das Problem

Die Entwicklung von Software läuft in der Regel nicht einfach planlos ab, sondern folgt einem mehr oder weniger festgelegten Schema. Dieses Schema nennt man ein Vorgehensmodell (der Softwareentwicklung). Bekannte Vertreter sind das Wasserfallmodell oder moderne agile Methoden.

Je nach Größe des Projekts können von einigen wenigen bis zu hunderten Entwicklern an einer Software arbeiten. Das erfordert klare Absprachen.

Wenn so viele Personen - die manchmal über die ganze Welt verteilt sind - an derselben Software arbeiten, kommt es schnell zu Problemen. Es wird aus Versehen ein Fehler eingebaut; zwei Mitarbeiter arbeiten an demselben Teil des Programms und ändern gleichzeitig dieselben Dateien; mehrere Programmierer haben Teile implementiert, die nun zusammengeführt werden müssen; usw.

Schnell hat man erkannt, dass man dafür eine Lösung braucht und die ersten Versionsverwaltungssysteme entwickelt.

Versionsverwaltungssysteme

Versionsverwaltungssysteme erlauben es einem Team am selben Code zu arbeiten, ohne miteinander in Konflikt zu kommen. Sollte es dennoch zu einem Konflikt kommen, helfen diese Systeme dabei, ihn zu beheben.

In der Regel gibt es dazu einen zentralen Server, auf dem der komplette Quelltext gespeichert ist. Ein Mitarbeiter lädt sich dann den aktuellen Quelltext auf seine Maschine, nimmt einige Änderungen vor und lädt den neuen Quelltext zurück, sodass ihn die anderen Mitarbeiter nutzen können. Schleicht sich dabei ein Fehler ein, kann der Programmcode zu jedem beliebigen Zeitpunkt der Entwicklung zurückgesetzt werden. Die Änderungen können also rückgängig gemacht werden.

Das Versionsverwaltungssystem Git wurde vom Linux-Erfinder Linus Torvalds entwickelt, um den Open-Source Kernel von Linus zu verwalten. Git ist mittlerweile eines der am weitesten verbreiteten Versionsverwaltungssysteme, die heute im Einsatz sind.

Git arbeitet - anders als die meisten Systeme - grundsätzlich dezentral, wobei wir uns in diesem Lernpfad zunächst auf ein zentrales Vorgehen konzentrieren wollen.

Grundbegriffe

Das Vorgehen bei der Arbeit mit Git sieht grundsätzlich wie folgt aus:

1. Anlegen eines Repositories (init oder fork).
2. Klonen eines Repositories (clone).
3. Entwicklungsphase (wird immer wiederholt)
   1. Holen der neusten Änderungen (pull).
   2. Änderungen vornehmen (commit).
   3. Prüfen auf neue Änderungen (fetch).
   4. Änderungen zurücksenden (push).

Ein Repositories bezeichnet einen Ordner mit verschiedenen Dateien und Verzeichnissen, die mit Git verwaltet werden. In unserem Fall könnte das ein BlueJ-Projekt sein, mit den Quelltexten als .java Dateien.

Beim Anlegen eines Repositories kann dieses entweder leer initialisiert (init), oder als Kopie (fork) eines bestehenden erzeugt werden. Sobald das Repository auf einem zentralen Server liegt, kann es von dort mit dem clone Befehl auf den eigenen Arbeitsrechner heruntergeladen werden. Dies muss nur einmal passieren. Danach werden mit dem pull Befehl nur noch die neusten Änderungen geladen. Dann wird zunächst auf dem eigenen Rechner programmiert. Zwischendurch werden die Änderungen in das lokal geklonte Repository eingespeichert (commit). Diese Änderungen liegen zunächst nur auf dem eigenen Rechner. Erst wenn alle Änderungen mit dem push Befehl auf den zentralen Rechner geladen werden, können die anderen Programmierer auf den Code zugreifen. Bevor man dies tut, sollte aber zuerst mit dem fetch Befehl geprüft werden, ob seit dem letzten pull neue Änderungen (von anderen Programmierern) vorgenommen wurden, da man sonst vielleicht einen Konflikt erzeugt. Sollten Änderungen vorhanden sein, muss zunächst ein weiterer pull durchgeführt werden, bevor schließlich die Änderungen gepushed werden können.