Git- Eine Kurze Übersicht zur lokalen Anwendung

Der Chaos Radio Express Podcast von Tim Pritlove hat mich dann doch mal dazu ermutigt Versionierung und Versionskontrolle durchzuführen und ein wenig mit Git herumzuspielen. Das Konzept überzeugt und ist so schwer auch nicht zu lernen wenn man mal die wesentlichen Gedanken verstanden hat.

Git Initialisieren

Ein Git-Repo ist Grunsätzlich nur ein Verzeichnis, welches mehrere Projektdateien (Texte und Binärdateien) und sogar weitere Unterverzeichnisse enthält und von Git überwacht wird.

Ein Verzeichnis als Git-Repo markieren:

:~> git init

Nun müssen Projektdateien bei Git registriert werden, damit Git Änderungen an diesen Dateien überwachen kann.

:~> git add [Projektverzeichnis/Projektdateien]

Anschlißend erstellt man sinniger Weise seinen ersten Commit, von diesem Ausgehend man weitere Commits erzeugt oder sogennante Branches des Hauptstamms Master erzeugt.

:~> git commit -m "initial commit on branch master"

Die bei Git registrierten Dateien haben einen genau dieser Zustände.

Committed: Veränderung wurde erfolgreich dem nächsten Commit hinzugefügt und gehört der nächsten Version an.

Staged: Das Veränderte Element ist für den nächsten Commit "markiert."

Modified: Eines der Elemente in dem Working Directory wurde geändert, aber noch nicht für den nächsten Commit markiert. Nicht markierte Verändeungen werden beim nächsten Commit nicht berücksichtigt.

Clean: Keines der Elemente wurde verändert.

Dabei ist das aktulle working Directory das Verzeichnis in dem Veränderungen gespeichert und Dateien hinzugefügt werden. Das Git Rerpo lagert die Metateien über die einzelenen Objekte in der Datenbank ab und erkennt die 4 Zustände.

Ein Vorhandenes Projekt Clonen

:~> git clone [Quelle] [Ziel]

Bei einem Clone wird das Komplette Repo der Quelladresse inkklusive aller Revisionen und Branches auf die Platte geholt. In diesem kann man nun Veränderung vornehmen, eigene neue Commits erstellen oder neu Branches anlegen und mergen.

Veränderungen anzeigen

:~> git log

Zeigt die History der einzelnen Commits an. Dabei steht der aktuellste Commit an oberster Stelle. Eine nützliche Option ist -p mit der mn sich die letzten veränderungen anschauen kann.

:~> git status

Gibt an welche Datei sich momentan in welchem Status begfindet. Und gibt an welche Dateien möglicherweise ins nächste Commit übernommen werden.

:~> git diff

Zeigt das Diff für geänderte Dateien an, die noch nicht gestaged sind. Mit der Option --staged kann man sich die Diffs für gestagete Dateien anzeigen lassen.

Staging Veränderte Dateien

:~> git add [Datei]

Fügt Element, wobei Element eine Datei oder ein ganzes Verzeichnis sein kann, zur Staging Area hinzu. Damit wird für den nächsten Commit markiert.

Sobald Dateien für den nächsten Commit gestaged sind kann man sie schließlich mittels

:~> git commit -m "bal bla"

ins nächste Commit überführen. Wobei natürlich "bla bla" eine sinnvolle Commitnachricht sein sollte.

Tagging

Sobald man ein neues Commit erstellt möchte man diesen vielleicht einen Namen Tag geben.

:~> git tag v0.1

erzeugt einen Tag mit dem Namen v0.1 auf dem aktuellen Commit. Es ist sinnvoll Tags zu verwenden. Um schnell und einfach bestimmte Veränderungen emittels

:~> git-show

sehen zu können Dabei ist es sinnvoll, gute Tags zu vergeben. Zum Beispiel git tag feature_xyz

Veränderungen Rückgängig machen

Wenn man sich mittels git status den aktuellen Zustand des aktuellen Commits anzeigen lässt, wird einem in der Regel auch mitgeteilt wie man verm,urkste Veränderungen wieder rückgängig machen kann.

• Gestagete Dateien als unstaged markieren: :~> git reset HEAD [Datei]
• Änderungen bei ungestagten Dateien rückgängig machen: :~> git checkout -- [Datei]

Push und Pull
Ist man der Meinung dass die Arbeit an dem Projekt soweit vorangeschritten ist, das man dieses nun mit dem ursprünglichen Repo wieder zusammenführen möchte kann man, sofern einem das Repo selber gehört und man die entsprechenden Rechte daran hat, es entweder von Origin nach Master pullen oder von Master nach Origin pushen.

:~> git pull Origin Master

:~> git push Origin Master

Branching und Merging

Der typische Workflow beim Branchen und Mergen im eigenen Repo sieht so aus. Man erstellt eienen neuen Branch.

:~> git branch fix-bug#1

und wechelt in diesen neuen Branch. (Checkout)

:~> git checkout fix-bug#1

Die Option -b des Subbefehls checkout ermöglicht es, diese beiden Schritte in einem Rutsch zu erledigen.

Macht ein paar Änderungen und macht in diesem Branch einen neuen Commit:

:~> git add [Datei/en]
:~> git commit -m "fixed bug #1"

Wichtig das Commit bezeiht sich nur auf den aktuellen Branch. In der Regel wird man nun tetsen ob man den Bug #1 wirklich repariert hat und das Programm bzw. das Projekt weiterhin wie bekannt stabil läuft. Ist alles OK wechselt man wieder in den Branch master

:~> git checkout master

und kann nun die Änderungen des Branch Branch fix-bug#1 mit dem Branch Master wiederzusammenführen (mergen)

:~> git merge fix-bug#1

und den Branch fix-bug#1 nun durch die Eingabe des Befehls

:~> git branch -d fix-bug#1

löschen.

Ins Detail:

http://progit.org/

git subbefehl --help

man git

man git-subbefehl


Dieser Artikel wird unter CC noncomercial Veröffentlicht