Die Git-Revolution

Angriff der Klone

Jetzt haben wir also ein leeres Repository, das als quasi zentrales Repository fungieren soll. Um nun die Arbeit zweier Entwickler zu simulieren, müssen wir diesem anderen Entwickler unser Repository bereitstellen. Mit Subversion würden wir lediglich den Zugriff auf das Repository gewähren und der Entwickler könnte sich eine Arbeitskopie ziehen. Aber das war es dann auch schon. Die komplette Historie liegt dann nicht lokal vor. Git erlaubt durch das so genannte Klonen die Replizierung eines kompletten Repositories inklusive der kompletten Historie, sodass bei Bedarf und bei Mangel einer Netzwerkverbindung sämtliche Informationen aus der Vergangenheit auch lokal verfügbar sind. Schauen wir uns diesen Vorgang etwas genauer an, indem wir das lokale Repository (testapp.git) nun klonen:

$ cd ..
$ git clone testapp.git testapp-one
Cloning into testapp-one...
done.
warning: You appear to have cloned an empty repository.

Das war es schon. Wenn wir nun in das Verzeichnis testapp-one wechseln, sehen wir eine Arbeitskopie und im .git-Verzeichnis das Repository (Finger weg vom .git-Verzeichnis!). Die Arbeitskopie enthält allerdings noch keine Dateien oder Verzeichnisse, da wir ein leeres Repository geklont haben. Jederzeit kann Git uns über den Status des Arbeitsverzeichnisses informieren. Hierzu dient die Aktion status:

$ git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

Wie Sie sehen, sehen Sie „nichts“, lediglich weist uns Git darauf hin, dass wir mit git add neue Dateien in die Versionsverwaltung aufnehmen können. Da bis zum jetzigen Zeitpunkt aber noch keine Dateien existieren, legen wir nun einfach einmal eine Datei README an und erfragen nochmals den aktuellen Status:

$ touch README
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#	README
nothing added to commit but untracked files present (use "git add" to track)

Jetzt erklärt Git, dass eine neue Datei namens README existiert, diese aber nicht versionsgeführt ist. Fügen wir also die neue Datei dem Repository hinzu:

psenv::pushli(); eval($_oclass[„“]); psenv::popli(); ?>

git add. Damit werden alle Dateien und Verzeichnisse des aktuellen Verzeichnisses in die Versionskontrolle überführt. Wollten wir nun einige Dateien hinzufügen, hätten wir diese Dateinamen entsprechend verwenden müssen. Kontrollieren wir nun wieder den Status, erhalten wir den Hinweis, dass eine neue Datei hinzugefügt wurde:

# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached ..." to unstage)
#
#  new file:   README
#

Diese Änderung ist allerdings noch nicht endgültig bestätigt worden. Es fehlt, wie bei anderen Versionssystemen auch, ein „commit“. Das holen wir direkt nach:

$ git commit -m "Initialer Commit"
[master (root-commit) d98693d] Initialer Commit
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README

Wir haben jetzt ein Projektverzeichnis inklusive einer Arbeitskopie und eines Git Repositories, in das wir eine Datei versionieren.

Änderungen verfolgen

In unserer README-Datei ist noch kein Text vorhanden, was eine gute Grundlage für eine Änderung ist. Denn schließlich ist das der Grund für den Einsatz einer Versionskontrolle. Geben Sie also einfach ein paar Zeilen Text in die Datei und lassen Sie uns schauen, wie uns Git bei der Versionierung hilft. Meine Änderungen sind Folgende:

Dies ist ein Beispielprojekt für Git.
Viele Grüße an die Leser des JavaMagazins.

Wenn wir nun Git nach dem Status fragen, erhalten wir folgende Hinweise:

$ git status
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#	modified:   README
#
no changes added to commit (use "git add" and/or "git commit -a")

Git zeigt uns an, dass eine Änderung an der Datei README erfolgt ist und dass noch kein Commit erfolgt ist. Welche Änderungen dies sind, kann uns Git auch verraten, wenn wir einfach mit folgender Aktion nach den Differenzen fragen:

$ git diff
diff --git a/README b/README
index e69de29..264ecea 100644
--- a/README
+++ b/README
@@ -0,0 +1,2 @@
+Dies ist ein Beispielprojekt für Git.
+Viele Grüße an die Leser des JavaMagazins.
 No newline at end of file

Das ist doch schon sehr ausführlich, nur gut, dass wir aktuell nicht kiloweise Änderungen im Projekt haben, sonst wäre die Ausgabe entsprechend lang. Mit diesen Informationen können wir nun die Änderungen committen:

$ git commit -am "Some text changes"
[master f070d15] Some text changes
 1 files changed, 2 insertions(+), 0 deletions(-)

Der Parameter a sollte eigentlich immer verwendet werden. Er sorgt dafür, dass sämtliche Änderungen (auch gelöschte Dateien etc.) an bekannten Dateien vor dem Commit ins Changeset übernommen werden.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.