Im Team mit Git: das Klassenquiz

1. Worum es geht

Allein an einem Programm zu arbeiten ist einfach: Was in deinem Ordner liegt, gilt. Arbeiten zwanzig Leute an demselben Programm, braucht es eine Stelle, an der alles zusammenkommt, und Regeln, damit niemand die Arbeit der anderen überschreibt. Diese Stelle ist ein gemeinsames Git-Repository: Jede und jeder hat einen Klon davon, arbeitet darin, holt sich die Commits der anderen mit git pull und gibt die eigenen mit git push ab.

Euer Repository liegt auf dem Git-Server git.example.org. Darin liegt schon das Quiz: ein kleines Programm, eine Runde zum Ausprobieren und eine Liste mit Aufgaben. Deine Lehrkraft lädt dich auf den Server ein; mit der Einladung kannst du dort mitmachen.

Die Befehle für jeden Tag stehen im Handbuch unter Git, was ein Git-Server dazu braucht unter Git-Server.

2. Einrichten

Einmalig: Zugang zum Git-Server

ls ~/.ssh/id_ed25519.pub

ssh-keygen -t ed25519 -C "Vorname Nachname"

cat ~/.ssh/id_ed25519.pub

ssh -T git@git.example.org

git config --global user.name "Vorname Nachname"
git config --global user.email "deine.mail@example.org"
git config --global pull.rebase false

Einmalig: Klonen

Klone das Repository der Klasse in deinen Workspace:

git clone [Adresse des Klassen-Repositorys] ~/class-quiz

Im Repository liegen:

3. Deine Runde

Sieh dir questions/beispiel.txt an. Eine Frage beginnt mit ?, die Antwort steht darunter mit =; gelten mehrere Antworten, trennt sie ein |. Zeilen mit # sind Kommentare.

# Eine Runde zum Ausprobieren
? Wie viele Bits hat ein Byte?
= 8 | acht

Leg in questions/ eine Datei für deine Runde an, mit deinem Vornamen klein und ohne Umlaute, etwa questions/lena.txt, und schreib mindestens drei Fragen hinein, zu einem Thema, das du gut kennst.

cd ~/class-quiz
ruby quiz.rb questions/lena.txt

ruby quiz.rb --check

cd ~/class-quiz
python3 quiz.py questions/lena.txt

python3 quiz.py --check

4. Abgeben

Ein Commit sollte nur enthalten, was zu ihm gehört. Darum nimmst du die beiden Dateien einzeln auf, statt mit git add -A alles, was sich irgendwo geändert hat:

git add questions/lena.txt rounds.txt
git commit -m "Runde von Lena"

git push

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '…'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally.

git pull --no-edit

5. Ein Konflikt

CONFLICT (content): Merge conflict in rounds.txt
Automatic merge failed; fix conflicts and then commit the result.

questions/beispiel.txt
<<<<<<< HEAD
questions/lena.txt
=======
questions/ida.txt
>>>>>>> 04a80e1422d4a1092423ad66fde49833572198e3

So löst du ihn auf:

1. Öffne rounds.txt, lass beide Zeilen stehen und lösche die Zeilen mit <<<<<<<, ======= und >>>>>>>. VS Code zeigt über dem Konflikt »Accept Both Changes«; das tut dasselbe.
2. Prüf das Quiz noch einmal mit --check.
3. Schließ den Merge ab und gib ihn ab:

git add rounds.txt
git commit -m "Runden von Lena und Ida"
git push

Lehnt Git den Push wieder ab, war in der Zwischenzeit noch jemand schneller: noch einmal git pull --no-edit, dann git push.

Ein Konflikt ist kein Fehler, sondern eine Frage, die Git nicht allein beantworten kann: Welche Fassung soll gelten? Hier war die Antwort leicht. Ändern zwei Leute dieselbe Zeile Code verschieden, müssen sie miteinander reden.

6. Die Arbeit verteilen

In TODO.md steht, was am Quiz noch fehlt. So eine Liste ist das einfachste Werkzeug, um Arbeit im Team zu verteilen: Jede und jeder sieht, was offen ist, wer woran arbeitet und was fertig ist.

Eine Aufgabe übernehmen

Such dir eine Aufgabe aus, die noch niemand hat, und übernimm sie sofort: Hol den neuesten Stand, schreib deinen Namen hinter ihr »Wer:«, und gib das gleich ab, bevor du anfängst. So sehen die anderen, dass sie vergeben ist.

git pull --no-edit
git add TODO.md
git commit -m "Lena übernimmt: Punkte in Prozent"
git push

Wollten zwei dieselbe Aufgabe, gibt es beim zweiten einen Konflikt in TODO.md. Dann redet ihr miteinander, wer sie macht.

In einem eigenen Branch

Deine Aufgabe erledigst du in einem eigenen Branch: einem Zweig des Repositorys, in dem du Commits machen kannst, ohne dass sie main ändern. Was in main liegt, funktioniert so immer, auch während du arbeitest.

git switch -c prozent

ruby quiz.rb
git add quiz.rb
git commit -m "Punkte am Ende auch in Prozent"

python3 quiz.py
git add quiz.py
git commit -m "Punkte am Ende auch in Prozent"

Ist die Aufgabe fertig, holst du den neuesten Stand von main und führst deinen Branch dort hinein:

git switch main
git pull --no-edit
git merge --no-edit prozent

Hat jemand anderes dieselben Zeilen geändert, gibt es wieder einen Konflikt, diesmal im Code. Dann stellst du eine Fassung her, die beides kann, probierst sie aus und schließt den Merge mit git add und git commit ab. Zum Schluss verschiebst du deine Zeile in TODO.md unter »Fertig«, committest das und gibst alles ab:

git push

Einen Commit lesen

In einem Team liest man die Arbeit der anderen, bevor sie bleibt. Das heißt Review. git log --oneline zeigt die Commits, git show einen davon mit allem, was er geändert hat:

git log --oneline
git show a3f9c21

Statt a3f9c21 nimmst du die Nummer eines Commits aus deiner Liste.

7. Regeln fürs Team

Was ihr gerade erlebt habt, gilt in jedem Team, das mit Git arbeitet:

• Erst holen, dann arbeiten: git pull, bevor du anfängst.
• Kleine Commits mit klaren Nachrichten: Ein Commit tut eine Sache, und seine Nachricht sagt, welche.
• Nur aufnehmen, was dazugehört: git add mit Dateinamen statt -A.
• Abgeben, wenn es funktioniert: In main liegt nur, was läuft.
• Nie --force in einem gemeinsamen Repository.
• Reden statt überschreiben: Bei einem Konflikt im Code fragst du die Person, deren Fassung es ist.