Branches und Merge Requests

Warum Branches

Auf main wird nicht direkt gearbeitet. Jede Aufgabe bekommt einen eigenen Branch. So kannst du mehrere Dinge parallel anfangen, Halbfertiges pushen, und main bleibt immer sauber. In Teams ist das der Normalfall: Niemand pusht direkt auf main.

Branch anlegen und wechseln

git switch -c lab/02-git-uebung
git branch

switch -c erstellt den Branch und wechselt hinein. git branch listet alle lokalen Branches, der aktive ist mit * markiert. Zurück auf main geht es mit git switch main.

Namenskonvention in diesem Kurs: lab/<modul>-<kurzname>, also etwa lab/04-rechte oder lab/08-menu.

Der komplette Ablauf

1. Auf main den aktuellen Stand holen:

   git switch main
   git pull

2. Branch für die Aufgabe anlegen:

   git switch -c lab/02-git-uebung

3. Aufgabe lösen, Dateien unter labs/linux/ anlegen, committen (gerne mehrmals).
4. Branch pushen:

   git push -u origin lab/02-git-uebung

   Git gibt dir direkt einen Link aus, um den Merge Request zu erstellen.
5. In GitLab den Merge Request eröffnen: Titel wie die Aufgabe, kurze Beschreibung, was du gemacht hast und wo du unsicher warst.
6. Die Pipeline läuft automatisch. Grün: alles gut. Rot: auf das Symbol klicken und die Meldung lesen, dann nachbessern und erneut pushen. Der Merge Request aktualisiert sich von selbst.
7. Nach dem Review wird gemergt. Lokal aufräumen:

   git switch main
   git pull
   git branch -d lab/02-git-uebung

Was die Pipeline prüft

Für Shell-Skripte läuft ShellCheck, ein Programm, das typische Fehler und Stolperfallen findet. Du kannst es auch lokal laufen lassen: sudo apt install shellcheck, dann shellcheck labs/linux/08-skripte/menu.sh. Die Meldungen haben Nummern wie SC2086, die du auf der ShellCheck-Webseite nachschlagen kannst.

Konflikte

Ein Konflikt entsteht, wenn zwei Branches dieselbe Zeile unterschiedlich ändern. Git kann dann nicht entscheiden und markiert die Stelle in der Datei:

<<<<<<< HEAD
Zeile aus main
=======
Zeile aus deinem Branch
>>>>>>> lab/04-rechte

Du entscheidest, was bleiben soll, löschst die Markierungen, dann git add und git commit. In diesem Kurs sind Konflikte selten, weil jede Person in eigenen Dateien arbeitet. Wenn es doch passiert: keine Panik, nichts geht verloren.

Das Allernötigste zum Nachschlagen

Befehl	Zweck
git status	Wo bin ich, was hat sich geändert
git switch -c NAME	Neuen Branch anlegen und wechseln
git switch NAME	Branch wechseln
git add DATEI / git add -A	In die Staging Area
git commit -m "Nachricht"	Commit erstellen
git push / git push -u origin NAME	Hochladen
git pull	Herunterladen und zusammenführen
git log --oneline --graph --all	Geschichte ansehen
git diff	Änderungen seit letztem Commit
git restore DATEI	Änderung an einer Datei verwerfen

Aufgabe 2.2 · Erster Merge Request

Erstelle den Branch lab/02-git-uebung. Ergänze deine Visitenkarte aus Aufgabe 2.1 um eine Zeile mit deinem Lieblings-Terminalbefehl (auch wenn du erst einen kennst). Committe, pushe und eröffne einen Merge Request mit einer kurzen Beschreibung.

Abgabe: Der Merge Request in GitLab.

Lösung anzeigen

git switch main && git pull
git switch -c lab/02-git-uebung
echo "- Lieblingsbefehl: ls" >> labs/linux/02-git/visitenkarte.md
git add -A
git commit -m "Lieblingsbefehl in Visitenkarte ergänzt"
git push -u origin lab/02-git-uebung

Danach dem Link in der Ausgabe folgen und den Merge Request erstellen.

Selbstcheck · 3 Fragen

1. Warum arbeitet man nicht direkt auf main?

Weil Git es verbietetDamit main immer in einem sauberen Zustand bleibt und Reviews möglich sindWeil Branches schneller sind

2. Was bedeutet eine rote Pipeline im Merge Request?

Der Merge Request wurde abgelehntEine automatische Prüfung ist fehlgeschlagen, die Meldung lesenDer Branch wurde gelöscht

3. Welcher Befehl legt einen Branch an und wechselt hinein?

git branch -cgit switch -cgit checkout -m

Antworten prüfen

Weiterführend

• Pro Git, das offizielle Buch, kostenlos und auf Deutsch.
• GitLab Docs: Merge Requests