Workshop: Git und Social Coding (Blatt 01)
Nach der Bearbeitung dieses Arbeitsblattes haben Sie gelernt
- grundlegende Git-Befehle anzuwenden
- nachzuvollziehen, welchen Einfluss grundlegende Befehle auf den Versionierungsgraphen haben
- parallel an mehreren Versionen zu arbeiten und diese wieder zusammenzufügen
Bearbeiten Sie diese Aufgaben in Gruppen von ca. 2 Personen. Für die Übungen sind 45 Minuten vorgesehen.
Es ist nicht weiter schlimm, wenn Sie mit den Übungen in der Zeit nicht fertig werden. Das Wichtigste ist, dass Sie ein grundlegendes Verständnis entwickeln.
Viel Erfolg!
Umgebung einrichten (ca. 5 min)
$ git --version
Zeigt die installierte Version von Git an.
$ git init
Erstellt ein lokales Git-Repository im aktuellen Verzeichnis
Sie haben eine neue Idee für ein Programm und wollen direkt anfangen zu programmieren. Ihnen fällt ein, dass es sich lohnt auch für private Projekte Git zu verwenden. Deshalb installieren Sie Git und richten es sich ein, bevor Sie mit der Arbeit anfangen:
Überprüfen Sie in der Kommandozeile mit
git --version
ob Git vorhanden ist.Konfigurieren Sie Git und setzen Sie den Namen und die E-Mail Adresse unter der Sie künftig arbeiten werden:
$ git config --global user.name "Peter Lustig" $ git config --global user.email "peter.lustig@uni-tuebingen.de" $ git config --global color.ui auto
Erstellen sie eine leeren Ordner für diese Übung (z.B.
exercise01/
) und wechseln sie mit der Kommandozeile in diesen OrdnerRufen Sie
git init
auf, um den Ordner in ein Git-Repository um zu wandeln.
Jetzt kann es endlich mit der Entwicklung losgehen.
Änderungen machen und merken (ca. 10min)
$ git status
Index und geänderte Dateien anzeigen.
$ git commit
Speichert den aktuellen Index als Snapshot in der Versionshistorie
$ git log
Zeigt die Versionshistorie für den aktuellen Branch
Morgens bei einer Tasse Kaffee fangen Sie nun an den ersten Beitrag zu Ihrem Projekt zu leisten.
In dieser Aufgabe sollen Sie eine Datei anlegen, diese in die Versionierung aufnehmen und den Versionierungsgraphen zeichnen.
- Erstellen Sie eine einfache Java-Datei in Ihrem Arbeitsverzeichnis,
z.B. die Datei
hello.java
mit dem Inhalt:
class Hello {
public static void main(String[] args) {
System.out.println("Hello Git");
}
}
Überprüfen Sie den aktuellen Status Ihrer Arbeitskopie mit
git status
.Fügen Sie die eben erstellte Java-Datei mit
git add
zum Index hinzu und überprüfen Sie erneut den Status Ihrer Arbeitskopie.Erstellen Sie einen Snapshot, basierend auf dem aktuellen Index (
git commit
) und überprüfen Sie erneut den Status Ihrer Arbeitskopie.Zeichnen Sie (von Hand) den Versionierungsgraph, der den aktuellen Zustand des Respositories darstellt. Annotieren Sie jeden Commit in dem Graphen mit den ersten vier Stellen des Commit-Hashs (z.B.
0a13
).Tipp: Nutzen Sie
git log --oneline --decorate
, um eine übersichtliche Darstellung der Versionshistorie zu erhalten.
Vorübergehende Änderungen und paralleles Arbeiten (10min)
$ git branch [new branch name]
Erstellt einen neuen Branch durch Kopieren des
HEAD
-Pointers.
$ git checkout [branch or commit-id]
Setzt HEAD
auf den angegebenen Branch und kopiert die
Inhalte aus dem Snapshot in das Arbeitsverzeichnis.
Nachdem Sie noch ein bisschen weiterarbeiten, kommt Ihnen plötzlich eine Idee. Sie sind sich aber nicht sicher, ob diese Idee wirklich funktioniert. Deshalb arbeiten Sie an der Idee in einem neuen Branch.
Machen Sie eine Änderung an
hello.java
, überprüfen Sie den Status, fügen Sie die Änderung zum Index hinzu und erstellen Sie einen Commit.Tipp: Achten Sie auch immer darauf, dass die Commit-Nachricht Ihre Änderung kurz und treffend beschreibt (Tipps zu Commits). Nur so können Sie diese später wieder schnell nachvollziehen.
Erstellen Sie nun einen Branch, z.B. mit
git branch my-experiment
und wechseln Sie zu diesem Branch, um an Ihrer Idee zu arbeiten.
Erstellen Sie eine neue Datei mit etwas Inhalt, z.B.
greeter.java
mitclass Greeter { String name; Greeter(String name) { this.name = name; } public String greet() { return "Hello" + name + ", what a wonderful day."; } }
Sie sind zufrieden mit Ihrer Idee? Dann erstellen Sie nun einen Commit und speichern den Zustand der neuen Datei in ihrem Repository (im Branch
my-experiment
).Zeichnen Sie erneut den Versionierungsgraph, der den aktuellen Zustand des Respositories darstellt.
Änderungen übernehmen (ca. 10min)
$ git merge [branch name]
Erzeugt einen Merge-Commit mit zwei “parent”-Referenzen (HEAD und
angegebener Ziel-Branch). Der aktuelle Branch wird auf den erzeugten
Merge-Commit gesetzt.
Sie sind zunächst zufrieden mit den Änderungen im Branch
my-experiment
. Nun wollen Sie diese Änderungen auch in den
main
-Branch übernehmen.
- Nutzen Sie
git checkout
, um in denmain
-Branch zu wechseln. Überprüfen Sie mitgit status
, ob sie im richtigen Branch sind. - Untersuchen Sie Ihr Arbeitsverzeichnis. In welchem Zustand befindet sich dies nun?
- Übernehmen Sie nun die Änderungen aus
my-experiment
inmain
durch Aufrufen vongit merge my-experiment
. - Untersuchen Sie das Ergebnis von
merge
in Ihrem Arbeitsverzeichnis. - Zeichnen Sie erneut den Versionierungsgraph, der den aktuellen Zustand des Respositories darstellt.
Änderungen zusammenführen (ca. 10min)
Zufrieden mit der aktuellen Version in main
arbeiten Sie
weiter und erzeugen einen weiteren Commit in main
. Nun
fällt Ihnen auf, was Sie in my-experiment
noch besser
machen könnten – Sie sind sich aber wieder nicht sicher, ob die Änderung
auch in main
sollte.
Da sie weiter auf my-experiment
arbeiten wollen, aber
auch die neusten Änderungen von main
brauchen mergen Sie
nun main
in my-experiment
.
- Führen Sie eine Änderung in
main
durch und committen Sie diese. - Wechseln Sie zu
my-experiment
und mergen Siemain
inmy-experiment
, um an der aktuellen Version weiterzuarbeiten. - Zeichnen Sie erneut den Versionierungsgraph, der den aktuellen Zustand des Respositories darstellt.
Optional: Machen Sie noch eine Änderung in
my-experiment
und mergen Sie nun diese Änderungen zurück in
main
. Zeichnen Sie den Versionierungsgraph.
Dateien Ignorieren
Finden Sie heraus was eine
.gitignore
Datei macht. Kompilieren Sie hierzu die Java-Dateien aus dem obigen Projekt in einen Ordnerbuild/
. Warum sollten Sie die dadurch entstandenen*.class
-Dateien nicht in Ihrem Repository speichern?Finden Sie heraus was
git rebase
macht und wofür Sie es einsetzen könnten. In welchem Fall hätte es Sinn ergeben zu rebasen, statt zu mergen?