LinuxUser Programmieren (Vorschau)
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
SCHWERPUNKT<br />
Grundkurs Git<br />
D Commit-Nachrichten<br />
dürfen Sie in<br />
Ihrem Lieblingseditor<br />
verfassen.<br />
mitID) oder Dateien (Dateiname)<br />
anzeigen und so Unterschiede<br />
schnell aufspüren. Das erweist<br />
sich vor allem dann als hilfreich,<br />
wenn beim Bugfixing nur wenige<br />
und auf den ersten Blick schwer<br />
zu findende Änderungen vorgenommen<br />
wurden.<br />
E Git erlaubt viele<br />
gleichzeitige Branches.<br />
Ein Asterisk<br />
zeigt den aktuellen<br />
„Spielplatz“ an.<br />
halten. Das gilt vor allem, wenn<br />
die Commit-Nachricht länger ausfällt.<br />
Vor allem, wenn mehrere<br />
Personen zusammenarbeiten, helfen<br />
kurze Anmerkungen, warum<br />
etwas geändert wurde und ob an<br />
irgendeiner Stelle Probleme oder<br />
Fehler auftraten beziehungsweise<br />
zu erwarten sind.<br />
Den ersten Commit nennt man<br />
den initialen Commit. Alle weiteren<br />
sollten Sie so benennen, dass<br />
die Projektbeteiligten sofort sehen,<br />
was der Commit bewirkt.<br />
Nachrichten wie kleine Bugs gefixt<br />
sagen nichts Sinnvolles aus – besser<br />
wäre beispielsweise Speicherzugriffsfehler<br />
in bitshift.cpp behoben.<br />
Oftmals – gerade beim verteilten<br />
Arbeiten, wo möglichst alle Projektmitglieder<br />
den aktuellen Stand<br />
ohne Verzögerungen erhalten sollten<br />
– enthält ein Commit nur kleine<br />
Änderungen. Genügt eine solche<br />
kurze Commit-Nachricht,<br />
können Sie diese direkt im Aufruf<br />
mit angeben, ohne dazu erst den<br />
Editor aufzurufen (Listing 3).<br />
Branches<br />
Erweitert man eine bestehende<br />
Anwendung um neue Funktionen,<br />
dann besteht immer die Gefahr,<br />
dass funktionierende Teile in Mitleidenschaft<br />
gezogen werden. Git<br />
raubt dem Worst-Case-Szenario<br />
den Schrecken, denn es erlaubt<br />
verschiedene Zweige („Branches“)<br />
eines Projektes. Ein solcher Zweig<br />
lässt sich mit einem Spielplatz<br />
vergleichen, auf dem sich neue<br />
Funktionen ausprobieren lassen,<br />
ohne schon bestehende Teile einer<br />
Anwendung zu gefährden.<br />
Einen neuen Branch legen Sie<br />
mit dem Befehl git branch Name an.<br />
Es dürfen beliebig viele parallele<br />
Zweige bestehen, zwischen denen<br />
Sie mit git checkout Name wechseln.<br />
Der Befehl git branch ohne<br />
Angabe eines Namens zeigt alle<br />
existierenden Zweige an. Den aktuellen<br />
„Spielplatz“ markiert Git<br />
mit einem Sternchen (Abbildung<br />
E) – hier erfolgende Commits<br />
betreffen nur diesen Branch.<br />
Änderungen in einem Zweig beeinflussen<br />
die anderen Branches<br />
in keiner Weise. Haben Sie das<br />
neu zu implementierende Feature<br />
fertiggestellt und getestet, führen<br />
Sie den betreffenden Zweig über<br />
git merge Name mit dem Master zusammen.<br />
Branches, die Sie nicht<br />
mehr brauchen, entfernen Sie<br />
mittels git branch -d Name. Möchten<br />
Sie einen Zweig umbenennen,<br />
erledigen Sie das mit dem Kommando<br />
git branch -m NeuerName.<br />
Mittels git diff lassen sich Unterschiede<br />
zwischen Zweigen<br />
(Branch1..Branch2), Commits (Com-<br />
Projekthistorien<br />
Ein Projekt wächst, die Commits<br />
reihen sich aneinander, ein Meilenstein<br />
ist erreicht – jetzt muss<br />
ein Changelog her. Statt im Gedächtnis<br />
zu kramen, was seit dem<br />
letzten Meilenstein erreicht wurde,<br />
fragen Sie dazu einfach Git –<br />
vorausgesetzt, Sie haben auch<br />
immer aussagekräftige Commit-<br />
Nachrichten erstellt.<br />
So plaudert git log aus, was bei<br />
jedem Commit passierte, wer dafür<br />
verantwortlich war und wann<br />
eine Änderung ins Projekt gespielt<br />
wurde. Die Ausgabe des Log<br />
fällt je nach Wunsch kurz und<br />
knackig oder auch sehr ausführlich<br />
aus. Rufen Sie den Befehl<br />
ohne weitere Parameter auf, gibt<br />
Git den eindeutigen Hash eines<br />
Commits, Autor, Datum und die<br />
Commit-Message aus. Die Option<br />
--graph visualisiert einzelne Branches<br />
(Abbildung F). Der Parameter<br />
--oneline beschränkt die Ausgabe<br />
auf den Beginn des Commit-<br />
Hashes und die Commit-Nachricht,<br />
wobei er nicht mehr als eine<br />
Zeile verwendet.<br />
Schäden begrenzen<br />
Ein kleines Szenario: Sie finden<br />
sich plötzlich nach mehreren Tagen<br />
Entwicklung unter Zeitdruck<br />
und akutem Schlafmangel in „dreckigem“,<br />
zurechtgefrickelten Code<br />
wieder, der nicht wie gedacht<br />
funktioniert. Beim Wegtragen des<br />
Mülls durchzuckt Sie plötzlich die<br />
vielversprechende Idee, die alle<br />
Probleme lösen könnte. Die erfolglosen<br />
Ansätze, die Fehler von<br />
Hand wieder aus dem Code zu fischen,<br />
sind wohl aussichtslos. Ent-<br />
LISTING 3<br />
$ git commit -m "MPI_Type_create_struct für LineHistogram hinzugefügt"<br />
34 11 | 12<br />
www.linux-user.de