Dein Prototyp lebt auf einem eigenen Branch, und das ist richtig so. Aber während du dort
baust, läuft master weiter: neue Tokens in ui-web, eine umgebaute Komponente, ein Paket
mehr. Nichts davon kommt von allein zu dir. Diese Lektion erklärt, was „auseinanderlaufen"
heißt, was ein Merge dagegen tut, wie du einen Konflikt liest — und warum das bei trybe
jeden Morgen passiert und nicht erst am Ende.
Zwei Linien laufen auseinander
In der letzten Lektion hat sich die Historie gegabelt: dein Branch bekam Commits, master
auch. Jeder weitere Tag verlängert beide Linien. Solange du nichts tust, sieht dein Prototyp
packages/ui-web so, wie es am Tag der Abzweigung war — die Datei-Stände in deinem Ordner
kommen aus deinem Branch, und der kennt master nur bis zum gemeinsamen Vorfahren.
Das ist keine Störung, sondern der Zweck eines Branches: Du kannst bauen, ohne dass dir jemand unter den Händen etwas ändert. Der Preis ist, dass du das Ändern nachholen musst.
Dein Rechner
Arbeitsordner sauber
Branch, auf dem du stehstanderer BranchLesezeichen von origin● neu in diesem Schritt
Anfang
Der Stand, bevor etwas passiert.
Weiter geht einen Schritt vor · oben master, unten dein Branch
Du committest seit zwei Wochen auf proto/notes. Johannes hat letzte Woche neue Farb-Tokens in packages/ui-web auf master gemergt. Benutzt dein Prototyp sie?
Der Merge: ein Commit mit zwei Eltern
git merge origin/master auf deinem Branch sucht den letzten gemeinsamen Commit beider
Linien, nimmt die Änderungen seitdem auf beiden Seiten und legt beides in einen neuen Commit.
Der hat zwei Eltern: deinen letzten Commit und den von master. Danach enthält dein Branch
alles — deine Arbeit und das, was auf master dazukam.
Dateien, die nur eine Seite geändert hat, übernimmt Git einfach. Dateien, die beide geändert haben, aber an verschiedenen Stellen, setzt Git zusammen. Nur wenn beide Seiten dieselben Zeilen angefasst haben, hält Git an und fragt dich. Das ist der Konflikt — dazu gleich mehr.
Dein Rechner
Arbeitsordner sauber
Branch, auf dem du stehstanderer BranchLesezeichen von origin● neu in diesem Schritt
Anfang
Der Stand, bevor etwas passiert.
Weiter geht einen Schritt vor · der Merge-Commit hat zwei Kanten nach links
Du stehst auf proto/notes und tippst git merge origin/master. Was ist danach mit master passiert?
Wenn beide dieselbe Zeile geändert haben
Angenommen, du hast in atoms.tsx den Chip-Abstand von 4 auf 6 gestellt, und Johannes hat
dieselbe Zeile auf master auf 8 gestellt. Git kann nicht wissen, welche Zahl gelten soll,
also schreibt es beide in die Datei und markiert die Stelle:
<<<<<<< HEAD
const CHIP_ABSTAND = 6;
=======
const CHIP_ABSTAND = 8;
>>>>>>> origin/master
Oben, bis zum =======, steht deine Fassung (HEAD, der Branch, auf dem du stehst); darunter
die von master. Auflösen heißt: entscheiden, die Marker löschen, sodass nur die gewollte
Zeile übrig bleibt, und die Datei als erledigt vormerken. Der Merge ist dabei nicht
abgebrochen, sondern pausiert — er wartet auf deinen Commit.
Enter führt aus · Tab vervollständigt den nächsten Befehl · Ausgaben gekürzt
Git meldet CONFLICT in atoms.tsx. Was ist passiert?
Warum jeden Morgen
Ein Merge nach einem Tag betrifft eine Handvoll Dateien; meist geht er ohne Konflikt durch, und wenn nicht, ist es eine Stelle, die du gestern noch im Kopf hast. Ein Merge nach drei Wochen betrifft Dutzende Dateien, und die Konflikte stecken in Code, den du längst wieder umgebaut hast. Es ist derselbe Unterschied, den du zuvor nicht gemerkt hast — nur auf einmal.
Dazu kommt, was du dabei siehst: Nach jedem Merge läuft dein Prototyp gegen das aktuelle
ui-web. Bricht etwas, weißt du, dass es an den Änderungen von gestern liegt. Und am Ende,
wenn dein Branch auf master soll, gibt es nichts mehr zu vereinen — master ist ja schon drin.
So sieht der Anfang eines Arbeitstags auf deinem Branch aus. Bring die Schritte in die richtige Ordnung.
- 1git status — der Ordner ist sauber, alles von gestern ist committet
- 2git fetch — nachsehen, wo master auf GitHub steht
- 3git merge origin/master — master in den Branch holen
- 4Falls Konflikt: Datei bereinigen, git add, git commit
- 5pnpm install — falls master neue Pakete mitgebracht hat
- 6Prototyp starten und einmal anschauen — läuft er noch mit dem neuen Stand?
- 7Weiterbauen
Häufige Fragen
Woran sehe ich, ob master seit meinem letzten Merge weitergelaufen ist?
git fetch, dann git log --oneline proto/notes..origin/master — das listet die Commits, die master hat und dein Branch noch nicht. Ist die Liste leer, gibt es nichts zu mergen.
Kann ich statt fetch und merge auch git pull origin master tippen?
Ja, das ist dasselbe in einem Befehl: holen und in den aktuellen Branch mergen. Zwei Befehle haben den Vorteil, dass du zwischendrin sehen kannst, was kommt. Wichtig ist nur, dass du dabei auf deinem Branch stehst, nicht auf master.
Ich habe einen Konflikt falsch aufgelöst und schon committet.
Kein Drama: Die Datei einfach noch einmal richtig schreiben und ganz normal committen. Der Merge-Commit bleibt, der Korrektur-Commit kommt dahinter. Deine alte Fassung steht außerdem noch in deinem Commit vor dem Merge, falls du nachsehen willst, was du hattest.
In meiner Historie stehen lauter Commits „Merge remote-tracking branch origin/master". Ist das schlimm?
Nein, das sind genau diese Morgen-Merges, und sie gehören da hin. Sie zeigen, wann dein Branch welchen master-Stand bekommen hat. Bei trybe sehen die Branches von allen so aus.
Was, wenn master eine Datei gelöscht hat, die ich geändert habe?
Auch das ist ein Konflikt („deleted by them"). Git behält deine Fassung im Ordner und fragt. Meistens ist die Antwort: Die Datei ist auf master aus gutem Grund weg, also git rm und deine Änderung an die neue Stelle übertragen. Im Zweifel Johannes fragen, warum sie weg ist.