26.02.2014 Aufrufe

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!