LinuxUser Programmieren (Vorschau)

Grundkurs Git
SCHWERPUNKT
weder fangen Sie also noch einmal
von vorne an – oder nutzen die
Vorteile der Versionsverwaltung
und machen ein Rollback auf die
letzte funktionierende Revision.
Sind Sie absolut sicher, dass die
letzten Stunden für die Katz waren,
stoßen Sie nun mit git reset
--hard CommitID ein „hartes“ Rollback
an. Die Commit-ID bezeichnet
den 40-stelligen Hash-Wert
des gewünschten Schnappschusses.
Die Hashes unterscheiden
sich in der Regel so weit, dass Git
meist die ersten sieben Stellen genügen,
um einen Commit eindeutig
zu identifizieren. Mit einem
harten Reset setzen Sie alle Dateien
im Arbeitsverzeichnis und
in der Staging Area zurück.
Ersetzen Sie --hard durch --soft,
setzt Git den angegebenen Commit
auf die Version „HEAD“, was
bedeutet, dass er als der letzte
Commit gilt. Dabei bleiben alle
Änderungen im Arbeitsverzeichnis
und in der Staging Area erhalten.
Ob ein Soft-Reset bei wirren
Code-Verstrickungen sinnvoll
und hilfreich ist, muss jeder für
sich entscheiden.
Eine andere Möglichkeit eines
Rollbacks bietet git checkout, das
Sie schon vom Wechseln der
Branches kennen. Für einen Rollback
benennen Sie den Master-
Branch um, holen mit git checkout
CommitID den letzten brauchbaren
Schnappschuss und machen diesen
mittels git checkout -b master
zum neuen Master. Bei git checkout
-b Name handelt es sich um
eine Kurzform für git branch Name
und git checkout Name (Abbildung
G). Der Vorteil bei dieser
Variante des Rollbacks: Sämtliche
Änderungen und eventuell verwendbaren
Ideen bleiben zunächst
erhalten – Sie können sie
später immer noch löschen.
Mit git checkout lassen sich
nicht nur komplette Commits zurücksetzen,
sondern auch einzelne
Dateien. Dazu geben Sie lediglich
zusätzlich den Dateinamen
an. So stellt das Kommando git
checkout af4673fa6 main.cpp den
Zustand der Revision af4673fa6
der Datei main.cpp wieder her.
Verteilte Versionen
Git wurde von Beginn an als verteilte
Versionsverwaltung entworfen,
was bedeutet, dass mehrere
Beteiligte gleichzeitig an einem
Projekt arbeiten können. Im
Unterschied zu einer zentralen
Versionsverwaltung, die für Logs
und Commits eine Verbindung
zum Repository auf dem Server
braucht, laufen Git-Repositories
lokal und lassen sich mit einem
Server abgleichen, sobald eine
Netzwerkverbindung besteht.
Da der Server nur die Änderungen
verteilen soll, genügt es, wenn
dort ein sogenanntes Bare-Reposi-
F Das Git-Log zeigt
die Projekthistorie.
G Gits Checkout-Befehl
eignet sich nicht
nur für das Wechseln
von Branches, sondern
auch für Rollbacks.
VERTEILTE VERSIONSVERWALTUNG: ERFAHRUNGSWERTE
Bei Software-Projekten, an denen mehrere Entwickler
über eine Versionsverwaltung arbeiten, haben sich
einige Vorgehensweisen als vorteilhaft erwiesen. Beispielsweise
sollten Sie auch die Änderungen durch
andere Entwickler verfolgen. So sehen Sie schnell,
ob deren Code mit den eigenen Komponenten zusammenspielt,
und finden etwaige Notizen zu noch
bestehenden Fehlern. Repositories sollten immer nur
ein Projekt enthalten, auch wenn Entwickler an mehreren
Projekten gleichzeitig zusammenarbeiten.
Mit einem Commit schließen Sie idealerweise immer
genau eine Aufgabe ab, beispielsweise ein
neues Feature oder einen Bugfix. Die Commit-Nachrichten
sollten aussagekräftig ausfallen und komplizierte
Sachverhalte erklären, sofern das nicht in
Kommentaren im Code erfolgt. Ein Repository enthält
nach Möglichkeit nur Dateien, welche die Entwickler
erstellt haben. Automatisch generierte Files
oder frei zugängliche externe Bibliotheken und
Hilfsprogramme haben darin nichts zu suchen: Sie
blähen das Repository nur unnötig auf.
Der bei einem Commit veröffentlichte Code muss
funktionieren, sodass die Projektmitglieder mit der
Arbeit fortfahren können und nicht anfangen müssen,
überraschend auftauchende Fehler zu beheben.
Entfernen Sie trotzdem niemals ohne Rückfrage
Code aus dem Projekt, nur weil er Ihnen nicht
gefällt oder Sie ihn nicht auf Anhieb verstehen.
www.linux-user.de
11 | 12 35