Entwicklerallltag mit GIT

Aus Siduction Wiki DE
Wechseln zu: Navigation, Suche

GIT-Tutorial: Übersicht

Commit

Grundsätzliches fürs Committen

  • Committe früh, committe oft
  • Ein Commit repräsentiert eine Idee oder eine Änderung
    • Das macht es leicht, die Differenzen/Patches zu lesen
    • Änderungen können einfach zurückgenommen werden
    • Änderungen können leichter in andere Branche übernommen werden
  • Nutze GIT als Logbuch der Entwicklung: Alles gehört rein, dann lässt sich alles nachvollziehen

Commit-Kommentar

Der Commit-Kommentar ist wesentlich für das Verständnis der Historie und das nachträgliche Suchen nach bestimmten Änderungen.

Formale Konventionen

  • Die erste Zeile beinhaltet eine Zusammenfassung. Sie ist max. 50 Zeichen lang.
  • Die zweiter Zeile bleibt leer.
  • Die weiteren Zeilen sind max. 72 Zeichen lang.

Hinweis: Für VIM gibt es Erweiterungen, die diese Konventionen überprüfen und z.B. durch Farben mitteilen.

Beispiel:

Navigation außerhalb des Textbereichs

* Die Nagivatins-Buttons sind jetzt außerhalb des Textbereichs
* Die Definition der Buttons in inosid_xx.conf
* Dokumentation angepasst

Benennung besonderer Commits

  • Der letzte Commit jedes Branches kann auch unter der Bezeichnung HEAD angesprochen werden.
  • Der vorletzte Commit heißt auch HEAD~1, der drittletzte HEAD~2 usw.

Historie für Recherchen nutzen

Das Kapitel Historie mit gitk im Griff (GIT) zeigt ausführlich den Umgang mit gitk, das für Recherchen in der Historie sehr gut geeignet ist.

Commits korrigieren

Korrektur des letzten Commits

Diesem Thema ist das Kapitel Korrektur des letzten Commits (GIT) gewidmet. Hier nochmal in Kurzfassung:

Soll der letzte Commit korrigiert werden, dann:

  • Änderungen im Arbeitsverzeichnis durchführen: Dateien ändern, Dateien umbenennen usw.
 git commit --amend -c HEAD

Hinweis: Die Option "-c HEAD" sorgt dafür, dass der letzte Commit-Text zum Edieren angeboten wird.

Auf den Stand eines Commits zurücksetzen

Das Kommando

 git reset HEAD~1

setzt auf den Stand des Commits vor dem aktuellen HEAD zurück, jedoch nur im Repository, nicht im Arbeitsverzeichnis. Das ist sinnvoll, wenn nur ein Teil der Änderungen zurückgenommen werden soll: Es kann jetzt ein Vergleich mit dem neuen HEAD durchgeführt werden und die schon gemachten Teiländerungen können übernommen werden.

Soll auch das Arbeitsverzeichnis zurückgesetzt werden, dann lautet der Befehl:

 git reset --hard HEAD~1

Damit sind alle nachfolgenden Änderungen vernichtet!

Es gibt dann jedoch noch einen Rettungsanker: GIT legt beim RESET-Kommando automatisch einen Commit ORIG_HEAD an, der den alten Zustand speichert. Dieser lebt allerdings nur bis zum nächsten Commit. Soll also der reset-Befehl widerrufen werden, so geben wir ein:

 git reset ORIG_HEAD

Das restauriert uns jedoch nicht das Arbeitsverzeichnis!

Umgang mit Tags

Es gibt zwei Klassen von Tags: leichtgewichtige und kommentierte.

Leichtgewichtige Tags

Diese Tags sind (normalerweise) nur in dem Repository sichtbar, in dem sie erzeugt wurden.

 git tag DienstagMorgen

Kommentierte Tags

Mit den Optionen -a, -s oder -u werden kommentierte Tags erzeugt:

 git tag -a v1.0 -m "erste öffentliche Version"

Der Kommentar ist Pflicht, wird also interaktiv eingefordert, wenn nicht mit -m schon angegeben.

Die Optionen -s und -u <key> sorgen dafür, dass der Tag kryptographisch signiert wird.

Kommentierte Tags werden beim Export/Import automatisch weitergereicht.

Ist ein kommentierter Tag erst mal weitergereicht, so hilft ein lokales Löschen nichts. Jeder, der die Tags importiert hat, muss diese explizit selber löschen. Das klingt umständlich, ist aber gewollt! Auf kommentierte Tags muss man sich verlassen können, sie verschwinden nicht einfach durch "externe Aktionen".