Neu strukturierter Lernpfad: Git, GitHub, VS Code & IntelliJ IDEA

Ziel: Du lernst Git nicht nur als Befehlsliste, sondern als Arbeitsweise: Änderungen verstehen, sauber speichern, Branches benutzen, Konflikte lösen, Pull Requests auf GitHub erstellen und Git in VS Code sowie IntelliJ IDEA sicher bedienen.

Neu in dieser Version: Das Material ist komplett neu strukturiert. Mehr Erklärungen beziehen sich jetzt auf alle Themen: Git-Grundlagen, Branches, Merge, Rebase, Konflikte, GitHub, Pull Requests, Actions, Releases, VS Code und IntelliJ IDEA. Zusätzlich gibt es jetzt ein Kapitel „Einfach erklärt“, mehr Praxisaufgaben mit Lösungen und ein Spezialkapitel zu Konflikten, Merge und Rebase in VS Code & IntelliJ.

Empfohlene Dauer: 6 Wochen bei 4–6 Stunden pro Woche. Für einen Intensivkurs: 10–14 Tage.

Noch mehr bildliche Inputs: Diese Version enthält eine eigene Bildergalerie und zusätzliche Diagramme für Status, Undo, Konfliktmarker, Forks, Actions, Releases sowie IDE-Konflikte.

Verzeichnis

Teil A – Orientierung und Denkmodell

1. So benutzt du diesen Lernpfad
2. Gesamtbild: Was du in welcher Reihenfolge lernst
3. Git in einem Satz – und warum das nicht reicht
4. Die wichtigsten mentalen Modelle

Teil B – Lokaler Git-Alltag

5. Setup und erstes Repository
6. Working Directory, Staging Area, Commit
7. Status, Diff, Add, Commit: der Tagesablauf
8. Commit-Nachrichten und kleine sinnvolle Schritte
9. Historie lesen: log, graph, show, blame
10. Undo und Rettung: restore, reset, revert, reflog

Teil C – Branches, Merge, Rebase und Konflikte

11. Branches wirklich verstehen
12. Merge ausführlich erklärt
13. Rebase ausführlich erklärt
14. Merge vs. Rebase vs. Squash
15. Konflikte verstehen und lösen
16. Komplexes Beispiel: Webshop-Checkout im Team

Teil D – GitHub und Zusammenarbeit

17. Remote, origin, fetch, pull, push
18. GitHub-Grundlagen: Repository, Issues, Pull Requests
19. Pull Requests Schritt für Schritt
20. Forks und Open-Source-Workflow
21. GitHub Actions, Releases, Tags und Schutzregeln

Teil E – Git in IDEs

22. VS Code Git-Benutzung bildlich erklärt
23. IntelliJ IDEA Git-Benutzung bildlich erklärt
24. GUI oder Terminal: Entscheidungshilfe

Teil F – Praxis, Fehlerdiagnose und Lernplan

25. 6-Wochen-Lernplan
26. Praxisprojekte
27. Cheat-Sheets
28. Fehlerdiagnose
29. Abschlusscheck

Teil G – Einfach erklärt, Übungen und IDE-Konflikte

30. Einfach erklärt: alle Themen in Alltagssprache
31. Praxisaufgaben mit Lösungen
32. Spezialkapitel: Konflikte, Merge und Rebase in VS Code & IntelliJ
33. Quellen

1. So benutzt du diesen Lernpfad

Dieser Lernpfad ist nicht dafür gedacht, nur gelesen zu werden. Git wird erst klar, wenn du Änderungen selbst erzeugst, bewusst Fehler machst und danach reparierst.

Arbeite immer mit einem echten Übungsrepository:

mkdir git-github-lab
cd git-github-lab
git init

Lege zusätzlich eine Datei learning-log.md an. Nach jedem Abschnitt schreibst du drei kurze Antworten hinein:

## Lernnotiz
- Was habe ich verstanden?
- Welcher Befehl war neu?
- Was würde ich im Team vorsichtig benutzen?

Wichtige Lernregel: Vor jedem riskanten Befehl führst du zuerst aus:

git status
git log --oneline --graph --decorate --all

Das ist wie ein Blick auf die Karte, bevor du abbiegst. Viele Git-Fehler passieren nicht, weil Git schwierig ist, sondern weil man nicht geprüft hat, wo man sich gerade befindet.

2. Gesamtbild: Was du in welcher Reihenfolge lernst

Die Reihenfolge ist wichtig. Viele Lernende springen zu GitHub oder Rebase, bevor sie status, diff, add, commit, branch und log sicher verstehen. Dann wirkt Git wie Magie. In diesem Lernpfad kommt deshalb zuerst das lokale Denkmodell, danach Teamarbeit und erst danach fortgeschrittene Strategien.

Kurz gesagt:

1. Du verstehst, was Git speichert.
2. Du lernst, kleine Änderungen sauber zu committen.
3. Du lernst, Historie zu lesen und Fehler rückgängig zu machen.
4. Du arbeitest mit Branches.
5. Du vergleichst Merge, Rebase und Squash.
6. Du nutzt GitHub für Pull Requests.
7. Du bedienst dieselben Abläufe in VS Code und IntelliJ IDEA.

3. Git in einem Satz – und warum das nicht reicht

Git ist ein verteiltes Versionskontrollsystem.

Das stimmt, hilft am Anfang aber nur wenig. Praktischer ist diese Erklärung:

Git ist ein System, mit dem du sinnvolle Zustände deines Projekts speicherst, zwischen ihnen wechseln kannst und Änderungen von mehreren Personen kontrolliert zusammenführst.

Git speichert nicht einfach „Datei A wurde verändert“. Ein Commit ist eher ein Foto deines Projekts zu einem bestimmten Zeitpunkt. Git kann dadurch später sagen: „So sah das Projekt damals aus, so sieht es jetzt aus, und das ist der Unterschied.“

Warum Git am Anfang verwirrt:

• Du speicherst Dateien im Editor, aber Git weiß davon nicht automatisch alles.
• Du kannst Änderungen stage-n, ohne sie zu committen.
• Du kannst committen, ohne etwas zu GitHub hochzuladen.
• Du kannst mehrere Branches haben, die alle unterschiedliche Projektzustände zeigen.
• Du kannst lokale und entfernte Historie haben, die nicht identisch sind.

Der Rest dieses Lernpfads löst genau diese Verwirrung Schritt für Schritt auf.

4. Die wichtigsten mentalen Modelle

Modell 1: Git arbeitet mit Bereichen

Git wirkt leichter, wenn du immer fragst: In welchem Bereich liegt meine Änderung gerade?

Typischer Denkfehler: „Ich habe gespeichert, also ist es in Git.“
Korrektur: Speichern im Editor verändert nur das Working Directory. Erst git add nimmt Änderungen in die Staging Area. Erst git commit speichert sie in der Git-Historie.

Modell 2: Ein Commit ist ein Snapshot

Ein Commit enthält:

• den Zustand der Dateien,
• eine Commit-Nachricht,
• Autor und Zeit,
• Verweis auf einen oder mehrere Eltern-Commits.

Ein Branch ist kein Ordner. Ein Branch ist ein beweglicher Zeiger auf einen Commit. Wenn du auf Branch main bist und einen neuen Commit machst, wandert main auf diesen neuen Commit weiter.

HEAD zeigt auf deinen aktuellen Arbeitsort. Meist zeigt HEAD auf einen Branch. Wenn du git switch feature/login ausführst, zeigt HEAD danach auf feature/login.

Modell 3: GitHub ist nicht Git

Git ist das Versionskontrollsystem. GitHub ist eine Plattform, die Git-Repositories hostet und Zusammenarbeit organisiert: Pull Requests, Reviews, Issues, Actions, Releases und Berechtigungen.

Du kannst Git komplett ohne GitHub verwenden. Du kannst GitHub aber nicht sinnvoll verwenden, ohne Git-Grundlagen zu verstehen.

5. Setup und erstes Repository

5.1 Git installieren und Identität setzen

Prüfe zuerst, ob Git installiert ist:

git --version

Dann setzt du deinen Namen und deine E-Mail-Adresse. Diese Daten landen in deinen Commits, damit später klar ist, wer welche Änderung gemacht hat.

git config --global user.name "Dein Name"
git config --global user.email "deine-mail@example.com"
git config --global init.defaultBranch main

Prüfen:

git config --global --list

Erklärung:

• --global bedeutet: gilt für deinen Benutzer auf diesem Rechner.
• user.name ist der Name in der Commit-Historie.
• user.email sollte zu deinem GitHub-Konto passen, wenn GitHub deine Commits zuordnen soll.
• init.defaultBranch main sorgt dafür, dass neue Repositories standardmäßig main heißen.

5.2 Erstes Repository anlegen

mkdir git-github-lab
cd git-github-lab
git init
printf "# Git GitHub Lab\n" > _intern/sources/_intern\sources\README.md
git status
git add _intern/sources/_intern\sources\README.md
git commit -m "Initial commit"
git log --oneline

Was passiert hier genau?

1. mkdir erstellt einen Ordner.
2. git init macht aus diesem Ordner ein Git-Repository.
3. _intern/sources/_intern\sources\README.md ist eine normale Datei.
4. git status zeigt, dass Git eine neue Datei sieht.
5. git add _intern/sources/_intern\sources\README.md wählt die Datei für den Commit aus.
6. git commit speichert den ersten Snapshot.
7. git log --oneline zeigt die Historie kompakt.

5.3 Häufiger Setup-Fehler

Problem: Git sagt beim Commit, dass Name oder E-Mail fehlen.
Lösung: Führe die git config-Befehle aus und committe erneut.

Problem: Du bist im falschen Ordner.
Lösung: Nutze pwd beziehungsweise cd, und prüfe mit:

git status

Wenn Git sagt not a git repository, bist du nicht im Repository-Ordner.

6. Working Directory, Staging Area, Commit

Dieser Abschnitt ist zentral. Wenn du diese drei Ebenen wirklich verstehst, werden viele Git-Befehle logisch.

6.1 Beispiel mit einer Datei

Erstelle eine Datei:

printf "Hallo Git\n" > notes.txt
git status

Git sagt sinngemäß: notes.txt ist untracked. Das bedeutet: Die Datei existiert, aber Git verfolgt sie noch nicht in der Historie.

Jetzt stage-n:

git add notes.txt
git status

Die Datei liegt nun in der Staging Area. Noch ist kein Commit entstanden. Du hast Git nur gesagt: „Diese Änderung soll in den nächsten Commit.“

Jetzt committen:

git commit -m "Add notes file"

Erst jetzt ist die Datei dauerhaft in der Git-Historie gespeichert.

6.2 Warum gibt es die Staging Area?

Die Staging Area wirkt am Anfang wie ein unnötiger Zwischenschritt. In der Praxis ist sie sehr wertvoll, weil du einen sauberen Commit zusammenstellen kannst.

Beispiel: Du hast gleichzeitig diese Änderungen gemacht:

• Tippfehler in _intern/sources/_intern\sources\README.md korrigiert,
• neue Login-Funktion in auth.js begonnen,
• Debug-Ausgabe in app.js eingefügt.

Das sollte nicht alles in einen Commit. Du kannst nur den README-Fix stage-n und committen:

git add _intern/sources/_intern\sources\README.md
git commit -m "Fix README typo"

Danach commitest du die Login-Funktion separat. So bleibt die Historie verständlich.

6.3 Einzelne Teile einer Datei stage-n

Wenn in einer Datei mehrere unabhängige Änderungen sind, kannst du interaktiv stage-n:

git add -p

Git zeigt dir Abschnitte, sogenannte Hunks. Du entscheidest pro Abschnitt, ob er in den nächsten Commit kommt.

Merksatz: Ein guter Commit ist nicht „alles, was ich in den letzten drei Stunden gemacht habe“, sondern „eine verständliche fachliche Änderung“.

7. Status, Diff, Add, Commit: der Tagesablauf

Der wichtigste Git-Ablauf besteht aus fünf Fragen:

1. Was ist geändert? → git status
2. Was genau ist geändert? → git diff
3. Was soll in den nächsten Commit? → git add
4. Was ist im Commit vorbereitet? → git diff --staged
5. Wie speichere ich es? → git commit

7.1 Der Standardablauf

git status
git diff
git add <datei>
git diff --staged
git commit -m "Beschreibe die Änderung konkret"

7.2 Beispiel: README erweitern

printf "\n## Start\nDieses Projekt ist ein Git-Lernlabor.\n" >> _intern/sources/_intern\sources\README.md

git status
git diff

git add _intern/sources/_intern\sources\README.md
git diff --staged
git commit -m "Add project start section"

Erklärung zu git diff:

• Zeilen mit + wurden hinzugefügt.
• Zeilen mit - wurden entfernt.
• Ohne Option zeigt git diff Änderungen, die noch nicht gestaged sind.
• Mit --staged zeigt Git Änderungen, die schon für den Commit ausgewählt wurden.

7.3 Wann committen?

Committe, wenn du einen Zustand erreicht hast, den du erklären kannst. Nicht jeder gespeicherte Zwischenstand braucht einen Commit. Aber du solltest auch nicht erst am Ende eines ganzen Tages einen riesigen Commit machen.

Gute Commit-Größe:

• eine kleine Funktion,
• ein Bugfix,
• eine Umbenennung,
• ein Dokumentationsabschnitt,
• eine Testergänzung.

Schlechte Commit-Größe:

• „alles Mögliche“,
• halbfertige Funktion plus Formatierung plus Tests plus unrelated Fix,
• 30 Dateien ohne klare Absicht.

8. Commit-Nachrichten und kleine sinnvolle Schritte

Eine Commit-Nachricht soll nicht nur sagen, was geändert wurde. Sie soll vor allem helfen, später zu verstehen, warum diese Änderung existiert.

8.1 Schlechte und gute Beispiele

Schlecht:

update
fix
changes
final

Besser:

Add checkout validation
Fix null handling in payment response
Document Git rebase workflow
Rename user service for clarity

8.2 Struktur für größere Commit-Nachrichten

Add checkout validation

Reject empty address fields before payment is created.
This prevents invalid orders from reaching the payment service.

Die erste Zeile ist die Zusammenfassung. Danach folgt optional eine Leerzeile und eine Erklärung.

8.3 Warum kleine Commits im Team wichtig sind

Kleine Commits machen Reviews leichter. Reviewer können nachvollziehen, warum etwas passiert ist. Wenn später ein Fehler entsteht, hilft git bisect oder manuelles Prüfen deutlich mehr, wenn die Historie aus sinnvollen Schritten besteht.

Übung: Erstelle drei Commits:

1. Add notes file
2. Add learning log
3. Document first Git commands

Prüfe danach:

git log --oneline --graph --decorate

9. Historie lesen: log, graph, show, blame

Git ist nicht nur zum Speichern da. Git ist auch ein Werkzeug, um Fragen über die Vergangenheit zu beantworten.

9.1 Kompakte Historie

git log --oneline

Zeigt eine kurze Liste von Commits.

9.2 Historie als Graph

git log --oneline --graph --decorate --all

Das ist einer der wichtigsten Befehle überhaupt. Er zeigt:

• Commit-Reihenfolge,
• Branch-Verläufe,
• Branch-Namen,
• Remote-Tracking-Branches wie origin/main,
• Merge-Strukturen.

9.3 Einzelnen Commit ansehen

git show <commit-id>

Damit siehst du die Commit-Nachricht und den Diff dieses Commits.

9.4 Wer hat eine Zeile geändert?

git blame <datei>

git blame zeigt, welcher Commit welche Zeile zuletzt verändert hat. Das ist kein Werkzeug zum Beschuldigen, sondern zum Verstehen. In Teams fragt man danach: „Welcher Kontext steht hinter dieser Zeile?“

9.5 Beispiel-Fragen, die du mit Git beantworten kannst

10. Undo und Rettung: restore, reset, revert, reflog

Undo ist eines der Themen, bei denen Git gefährlich wirken kann. In Wahrheit brauchst du vor allem die richtige Frage:

Wurde die Änderung nur lokal gemacht, gestaged, committed oder bereits gepusht?

10.1 Nicht gestagede Änderung verwerfen

git restore <datei>

Das verwirft lokale Änderungen in einer Datei. Benutze es nur, wenn du diese Änderung wirklich nicht mehr brauchst.

10.2 Gestagede Änderung wieder aus der Staging Area nehmen

git restore --staged <datei>

Die Änderung bleibt in der Datei erhalten, wird aber aus der Staging Area entfernt.

10.3 Letzten lokalen Commit zurücknehmen

git reset --soft HEAD~1

Der Commit wird entfernt, aber die Änderungen bleiben gestaged.

git reset --mixed HEAD~1

Der Commit wird entfernt, die Änderungen bleiben im Working Directory, aber nicht gestaged.

git reset --hard HEAD~1

Der Commit und die Änderungen werden verworfen. Dieser Befehl ist riskant.

10.4 Einen bereits geteilten Commit rückgängig machen

git revert <commit-id>

revert erzeugt einen neuen Commit, der die Änderung eines alten Commits rückgängig macht. Das ist meist die richtige Wahl, wenn der Commit schon gepusht wurde oder andere Personen darauf aufbauen.

10.5 Rettungsanker: reflog

git reflog

reflog zeigt, wo HEAD in letzter Zeit war. Wenn du dich mit reset oder rebase verrannt hast, findest du oft darüber einen alten Stand wieder.

Beispiel:

git reflog
git reset --hard <alter-stand>

Wichtige Sicherheitsregel: Bevor du reset --hard ausführst, prüfe zweimal git status und überlege, ob du die Änderungen vorher auf einen Sicherheitsbranch retten willst:

git branch backup-before-reset

11. Branches wirklich verstehen

Ein Branch ist eine eigene Entwicklungslinie. Du nutzt Branches, um Arbeit zu isolieren: neue Features, Bugfixes, Experimente oder Dokumentationsänderungen.

11.1 Branch erstellen und wechseln

git switch -c feature/login

Das bedeutet:

• Erstelle einen neuen Branch namens feature/login.
• Wechsle direkt auf diesen Branch.

Änderungen auf diesem Branch beeinflussen main nicht, solange du sie nicht integrierst.

11.2 Branch anzeigen

git branch

Der aktuelle Branch ist mit * markiert.

Alle Branches inklusive Remote-Branches:

git branch -a

11.3 Zurück zu main

git switch main

Wenn du uncommittete Änderungen hast, kann Git den Wechsel blockieren. Das ist Schutz. Git will verhindern, dass du Änderungen aus Versehen in einen anderen Kontext mitnimmst.

11.4 Branch löschen

git branch -d feature/login

-d löscht nur, wenn Git glaubt, dass die Arbeit sicher integriert ist. -D erzwingt das Löschen und sollte vorsichtig benutzt werden.

11.5 Branch-Namen im Team

Gute Branch-Namen sind konkret:

feature/checkout-validation
fix/payment-timeout
docs/git-rebase-guide
chore/update-dependencies

Schlecht:

test
new
aydin
final

Ein Branch-Name ist Kommunikation. Andere sollen sofort verstehen, woran gearbeitet wird.

12. Merge ausführlich erklärt

Merge bedeutet: Git integriert die Änderungen eines Branches in einen anderen Branch.

Typischer Ablauf:

git switch main
git merge feature/login

Du sagst damit: „Ich bin auf main. Bitte integriere die Arbeit aus feature/login in main.”

12.1 Fast-forward-Merge

Ein Fast-forward-Merge passiert, wenn main seit dem Abzweigen nicht weitergewachsen ist.

Vorher:

main:          A---B
                    \
feature/login:       C---D

Nachher:

main:          A---B---C---D

Git muss keinen neuen Merge-Commit erstellen. Der Branch-Zeiger main wird einfach nach vorne geschoben.

12.2 Merge-Commit

Ein Merge-Commit entsteht, wenn beide Branches neue Commits haben.

Vorher:

main:          A---B---E
                    \
feature/login:       C---D

Nachher:

main:          A---B---E---M
                    \     /
feature/login:       C---D

M ist ein Merge-Commit mit zwei Eltern. Er sagt: „Hier wurden zwei Entwicklungslinien zusammengeführt.“

12.3 Wann Merge sinnvoll ist

Merge ist sinnvoll, wenn:

• du die echte Branch-Geschichte sichtbar behalten möchtest,
• ein Feature-Branch mehrere Personen oder längere Arbeit enthält,
• du nachvollziehen willst, wann ein Feature als Ganzes integriert wurde,
• dein Team Merge-Commits bewusst nutzt.

12.4 Nachteile von Merge

Merge kann die Historie unruhiger machen, besonders wenn sehr oft kleine Branches gemerged werden. Das ist nicht automatisch schlecht. Eine echte Team-Historie darf Verzweigungen zeigen. Wichtig ist, dass das Team dieselbe Strategie verwendet.

12.5 Kommentiertes Merge-Beispiel

# 1. Auf den Zielbranch wechseln
git switch main

# 2. Neueste Änderungen vom Remote holen und integrieren
git pull

# 3. Feature-Branch integrieren
git merge feature/checkout-validation

# 4. Tests ausführen
npm test

# 5. Ergebnis hochladen
git push

Erklärung: Du mergest nicht „irgendwo“. Du mergest immer in den Branch, auf dem du gerade bist. Deshalb ist git switch main vor git merge feature/... so wichtig.

13. Rebase ausführlich erklärt

Rebase bedeutet: Git nimmt deine Commits und spielt sie neu auf einer anderen Basis ab.

Typischer Ablauf:

git switch feature/login
git fetch origin
git rebase origin/main

Das sagt: „Nimm meine Feature-Commits und setze sie so, als hätte ich sie auf dem aktuellen Stand von origin/main begonnen.”

13.1 Bildlich erklärt

Vor Rebase:

origin/main:   A---B---E
                    \
feature:             C---D

Nach Rebase:

origin/main:   A---B---E---C'---D'

C' und D' sind neue Commits. Inhaltlich entsprechen sie C und D, aber ihre Commit-IDs sind anders, weil ihre Basis anders ist.

13.2 Warum Rebase nützlich ist

Rebase ist nützlich, wenn du deinen eigenen Feature-Branch aktuell halten willst, ohne viele Merge-Commits wie „Merge main into feature“ zu erzeugen.

Beispiel:

git switch feature/checkout-validation
git fetch origin
git rebase origin/main

Danach ist dein Feature-Branch so, als hättest du ihn gerade erst vom aktuellen main abgezweigt.

13.3 Warum Rebase riskant sein kann

Rebase schreibt Historie um. Genauer: Rebase erstellt neue Commit-Kopien mit neuen IDs. Wenn andere Personen bereits auf deinen alten Commits aufbauen, können sie Probleme bekommen.

Faustregel:

• Eigenen lokalen Feature-Branch rebase-n: meistens gut.
• Bereits geteilten Branch rebase-n: nur mit Absprache.
• main rebase-n: normalerweise nicht.

13.4 Rebase-Konflikt lösen

git switch feature/checkout-validation
git fetch origin
git rebase origin/main

Wenn ein Konflikt entsteht:

git status

Datei öffnen, Konflikt lösen, dann:

git add <datei>
git rebase --continue

Wenn du abbrechen möchtest:

git rebase --abort

13.5 Nach Rebase pushen

Wenn dein Branch schon auf GitHub existiert, hat GitHub noch die alte Historie. Nach Rebase brauchst du deshalb oft:

git push --force-with-lease

--force-with-lease ist sicherer als --force, weil Git nur überschreibt, wenn auf dem Remote niemand anderes inzwischen neue Arbeit hinzugefügt hat.

Wichtiger Satz: Force Push ist nicht böse. Unabgesprochener Force Push auf geteilten Branches ist gefährlich.

14. Merge vs. Rebase vs. Squash

Merge, Rebase und Squash lösen ähnliche Probleme, aber sie erzählen unterschiedliche Geschichten.

14.1 Wann nehme ich Merge?

Nimm Merge, wenn du sichtbar behalten möchtest, dass eine Arbeit als Branch entstanden ist. Das ist besonders sinnvoll bei langen Features, größeren Umbauten oder wenn mehrere Personen am Branch gearbeitet haben.

14.2 Wann nehme ich Rebase?

Nimm Rebase, wenn du deinen eigenen Branch vor einem Pull Request aktualisieren oder aufräumen möchtest.

Beispiel:

git switch feature/cart-summary
git fetch origin
git rebase origin/main

Danach kannst du prüfen:

git log --oneline --graph --decorate --all
npm test

14.3 Wann nehme ich Squash?

Squash ist gut, wenn ein Pull Request viele kleine Arbeitscommits enthält:

try fix
fix again
wip
remove console log
final fix

Auf main soll daraus vielleicht nur werden:

Add checkout summary component

Squash macht die Hauptgeschichte lesbarer, verliert aber die feinen Zwischenschritte.

14.4 Entscheidungsregel für Lernende

1. Willst du verstehen, was passiert? Nutze Merge und schau dir den Graphen an.
2. Willst du deinen eigenen Branch aktualisieren? Nutze Rebase.
3. Willst du einen PR sauber in main bringen? Nutze je nach Teamregel Squash oder Rebase and merge.
4. Hat jemand anderes denselben Branch benutzt? Kein Rebase ohne Absprache.

15. Konflikte verstehen und lösen

Ein Konflikt bedeutet nicht, dass du etwas falsch gemacht hast. Ein Konflikt bedeutet: Git konnte zwei Änderungen nicht automatisch zusammenführen.

15.1 Typisches Konfliktbeispiel

Auf main steht in checkout.js:

const shippingCost = 4.99;

Branch A ändert:

const shippingCost = calculateShipping(cart);

Branch B ändert an derselben Stelle:

const shippingCost = user.isPremium ? 0 : 4.99;

Git weiß nicht, welche fachliche Logik richtig ist. Vielleicht soll beides kombiniert werden:

const shippingCost = user.isPremium ? 0 : calculateShipping(cart);

Diese Entscheidung kann Git nicht alleine treffen.

15.2 Konfliktmarker verstehen

Eine Konfliktdatei kann so aussehen:

<<<<<<< HEAD
const shippingCost = calculateShipping(cart);
=======
const shippingCost = user.isPremium ? 0 : 4.99;
>>>>>>> feature/premium-shipping

Bedeutung:

• <<<<<<< HEAD zeigt deinen aktuellen Stand.
• ======= trennt beide Varianten.
• >>>>>>> ... zeigt die andere Variante.

Du musst die Datei so bearbeiten, dass am Ende nur gültiger Code übrig bleibt. Die Marker müssen komplett entfernt werden.

15.3 Konflikt bei Merge abschließen

git status
# Dateien öffnen und Konflikte lösen
npm test
git add checkout.js
git commit

Bei einem Merge erstellt Git meist die Commit-Nachricht automatisch. Du kannst sie übernehmen oder verbessern.

15.4 Konflikt bei Rebase abschließen

git status
# Dateien öffnen und Konflikte lösen
npm test
git add checkout.js
git rebase --continue

Bei Rebase gibt es statt git commit meist git rebase --continue, weil Git gerade dabei ist, alte Commits neu abzuspielen.

15.5 Häufige Fehler bei Konflikten

16. Komplexes Beispiel: Webshop-Checkout im Team

Dieses Beispiel ist bewusst ausführlich. Du sollst nicht nur sehen, welche Befehle benutzt werden, sondern auch warum sie benutzt werden und wie man fachlich denkt, wenn mehrere Personen dieselbe Stelle im Code verändern.

16.1 Fachliches Ziel und Ausgangslage

Ein Team arbeitet an einem Webshop. Im Checkout stehen gleichzeitig drei Aufgaben an:

• Aylin baut Rabattcodes auf feature/coupon-code.
• Mert baut Steuerberechnung auf feature/tax-calculation.
• Sara behebt einen Fehler im Bezahlprozess auf fix/payment-error.
• Alle starten vom damaligen Stand von main.

Warum ist dieses Beispiel realistisch? Weil Teams oft parallel an demselben fachlichen Bereich arbeiten. Genau dort entstehen Konflikte: nicht, weil Git „kompliziert“ sein will, sondern weil zwei gute Änderungen dieselbe Stelle anders weiterentwickeln.

Datei checkout.js am Anfang:

export function calculateTotal(cart) {
  const subtotal = cart.items.reduce((sum, item) => sum + item.price, 0);
  const shipping = 4.99;
  return subtotal + shipping;
}

Wichtiges Denkmodell:

• Der Code ist fachlich noch simpel.
• Es gibt noch keine Rabatte.
• Es gibt noch keine Steuerberechnung.
• Genau deshalb verändern Aylin und Mert später dieselbe Funktion.

16.2 Wer ändert was – und warum kollidiert das später?

Aylins Ziel

Aylin möchte, dass ein Coupon den Gesamtpreis reduziert. Fachlich muss sie:

1. der Funktion einen zweiten Parameter geben,
2. den Rabatt berechnen,
3. den Rückgabewert anpassen.

git switch -c feature/coupon-code

Erster sinnvoller Stand:

export function calculateTotal(cart, coupon) {
  const subtotal = cart.items.reduce((sum, item) => sum + item.price, 0);
  const discount = coupon ? coupon.amount : 0;
  const shipping = 4.99;
  return subtotal - discount + shipping;
}

Dann speichert Aylin ihre Arbeit sauber als Commit:

git add checkout.js
git commit -m "Add coupon discount to checkout total"
git push -u origin feature/coupon-code

Merts Ziel

Mert möchte die Mehrwertsteuer ergänzen. Fachlich muss er:

1. den Zwischensaldo berechnen,
2. darauf Steuer anwenden,
3. den Rückgabewert anpassen.

git switch -c feature/tax-calculation

Merts Version sieht so aus:

export function calculateTotal(cart) {
  const subtotal = cart.items.reduce((sum, item) => sum + item.price, 0);
  const tax = subtotal * 0.19;
  const shipping = 4.99;
  return subtotal + tax + shipping;
}

Dann:

git add checkout.js
git commit -m "Add tax calculation to checkout total"
git push -u origin feature/tax-calculation

Saras Ziel

Sara arbeitet nicht an checkout.js, sondern an payment.js. Ihr Fix wird schnell gemerged. Dadurch ist main bereits weitergelaufen, während Aylin und Mert noch auf ihren Feature-Branches sind.

16.3 Zeitstrahl des Team-Szenarios

Die Schlüsselerkenntnis aus dem Zeitstrahl ist: Konflikte entstehen nicht nur, weil zwei Menschen dieselbe Datei ändern, sondern weil sie dieselben fachlichen Zeilen unterschiedlich weiterentwickeln.

16.4 Aylin aktualisiert ihren Branch sauber mit Rebase

Aylin ist allein auf ihrem Branch. Deshalb ist Rebase für sie ein guter Weg, um ihren Branch auf den neuesten Stand von main zu setzen.

git switch feature/coupon-code
git fetch origin
git rebase origin/main
npm test
git push --force-with-lease

Erklärung Schritt für Schritt:

• git switch feature/coupon-code – sie wechselt auf ihren Arbeitsbranch.
• git fetch origin – sie lädt den neuesten Stand vom Remote, ohne ihn sofort zu integrieren.
• git rebase origin/main – ihre Commits werden „auf den neuen Stand von main oben draufgesetzt“.
• npm test – nach einem Rebase wird geprüft, ob alles noch funktioniert.
• git push --force-with-lease – notwendig, weil Rebase Commit-IDs verändert. --force-with-lease ist dabei sicherer als ein blindes --force, weil Git prüft, ob der Remote inzwischen unerwartet verändert wurde.

Warum ist Rebase hier okay?

Weil Aylin ihren Branch nicht mit anderen teilt. Sie schreibt also niemand anderem die Historie um.

16.5 Merts Konflikt beim Rebase – wirklich Schritt für Schritt

Nachdem Aylins Pull Request gemerged wurde, enthält main bereits die Coupon-Logik. Mert möchte seine Steuerlogik jetzt darauf aufsetzen.

git switch feature/tax-calculation
git fetch origin
git rebase origin/main

Jetzt meldet Git einen Konflikt. Das ist kein Absturz, sondern eine Rückfrage: „Ich sehe zwei konkurrierende Versionen. Bitte entscheide, wie die endgültige fachliche Lösung aussehen soll.“

Wenn Mert jetzt git status ausführt, sieht er sinngemäß:

interactive rebase in progress
You are currently rebasing branch 'feature/tax-calculation' on 'origin/main'.
Unmerged paths:
  both modified: checkout.js

Die Konfliktdatei sieht so aus:

<<<<<<< HEAD
export function calculateTotal(cart, coupon) {
  const subtotal = cart.items.reduce((sum, item) => sum + item.price, 0);
  const discount = coupon ? coupon.amount : 0;
  const shipping = 4.99;
  return subtotal - discount + shipping;
}
=======
export function calculateTotal(cart) {
  const subtotal = cart.items.reduce((sum, item) => sum + item.price, 0);
  const tax = subtotal * 0.19;
  const shipping = 4.99;
  return subtotal + tax + shipping;
}
>>>>>>> Add tax calculation to checkout total

So liest du den Konflikt richtig:

• Bereich zwischen <<<<<<< HEAD und ======= → das ist der Stand, auf den Mert gerade rebased, also hier die bereits gemergte Coupon-Version aus main.
• Bereich zwischen ======= und >>>>>>> ... → das ist Merts Commit, der gerade angewendet werden soll.
• Git fragt nicht, welche Person „gewinnt“, sondern wie die gemeinsame Endversion aussehen soll.

16.6 Fachlich richtige Konfliktlösung

Mert sollte jetzt nicht einfach „oben behalten“ oder „unten behalten“. Er muss fachlich überlegen:

• Soll Steuer vor oder nach Rabatt berechnet werden?
• Darf der Betrag negativ werden?
• Bleibt das Shipping unverändert?

Eine sinnvolle Regel ist: erst Rabatt, dann auf den reduzierten Betrag Steuer berechnen.

export function calculateTotal(cart, coupon) {
  const subtotal = cart.items.reduce((sum, item) => sum + item.price, 0);
  const discount = coupon ? coupon.amount : 0;
  const taxableAmount = Math.max(subtotal - discount, 0);
  const tax = taxableAmount * 0.19;
  const shipping = 4.99;
  return taxableAmount + tax + shipping;
}

Danach:

git add checkout.js
npm test
git rebase --continue
git push --force-with-lease

Warum genau diese Reihenfolge?

1. Datei fachlich lösen.
2. Mit git add sagen: „Der Konflikt ist aufgelöst.“
3. Tests ausführen, bevor die Historie fortgesetzt wird.
4. Mit git rebase --continue den Rebase-Prozess weiterlaufen lassen.
5. Danach den umgeschriebenen Branch erneut pushen.

16.7 Warum entsteht der Konflikt technisch?

Der Konflikt entsteht, weil beide Änderungen dieselben Stellen betreffen:

Git ist also nicht „dumm“. Git ist vorsichtig. Es weiß nicht, ob die richtige Fachregel ist:

• Rabatt vor Steuer,
• Steuer vor Rabatt,
• oder vielleicht sogar steuerfreie Coupons.

Diese Entscheidung muss ein Mensch treffen.

16.8 Alternative: dieselbe Situation mit Merge statt Rebase

Dasselbe Szenario kann auch mit Merge gelöst werden. Dann schreibt Mert seine Historie nicht um.

git switch feature/tax-calculation
git fetch origin
git merge origin/main

Auch hier kann ein Konflikt in checkout.js entstehen. Mert löst ihn fachlich genauso wie oben und führt dann aus:

git add checkout.js
git commit

Git erstellt dabei einen Merge-Commit. Der große Unterschied ist also nicht die Konfliktlösung selbst, sondern die Form der Historie.

Merksatz:

• Willst du eine saubere, lineare Historie auf deinem eigenen Branch? → eher Rebase.
• Willst du nichts an der bestehenden Historie umschreiben? → eher Merge.

16.9 Pull Request und Team-Kommunikation

Nach der Konfliktlösung sollte Mert im Pull Request nicht nur schreiben „Konflikt gelöst“, sondern den fachlichen Hintergrund dokumentieren.

Beispiel für eine gute PR-Beschreibung:

Titel: Add tax calculation to checkout total

Zusammenfassung:
- Steuerberechnung für Checkout ergänzt.
- Branch auf aktuellen main rebased.
- Konflikt mit Coupon-Logik fachlich gelöst.

Fachliche Entscheidung:
- Rabatt wird zuerst vom Subtotal abgezogen.
- Steuer wird danach auf den reduzierten Betrag berechnet.
- Negative Zwischensummen werden mit Math.max(..., 0) verhindert.

Getestet:
- Checkout ohne Coupon
- Checkout mit Coupon
- Coupon größer als Subtotal

Das hilft Reviewerinnen und Reviewern enorm. Sie sehen dann nicht nur den Code, sondern auch die getroffene Fachentscheidung.

16.10 Wie würde das in VS Code oder IntelliJ aussehen?

In VS Code

1. Source Control öffnen.
2. Fetch bzw. Pull (Rebase) ausführen.
3. Bei Konflikt öffnet der Merge Editor die Datei.
4. Nicht blind „Accept Incoming“ oder „Accept Current“ klicken.
5. Die Logik manuell so kombinieren, dass Rabatt und Steuer zusammen funktionieren.
6. Datei speichern, stagen, dann Continue Rebase.

In IntelliJ IDEA

1. Unten rechts Branch-Menü öffnen.
2. Update Project oder Rebase Current onto Selected starten.
3. Bei Konflikt erscheint der Merge-Dialog.
4. Linke, rechte und Ergebnis-Seite vergleichen.
5. Die Ergebnis-Spalte muss die fachlich kombinierte Lösung enthalten.
6. Danach Konflikt bestätigen und Rebase fortsetzen.

Auch in der GUI gilt: Die Oberfläche löst nicht dein Fachproblem – sie zeigt dir nur bequemer, wo das Problem ist.

16.11 Häufige Fehler in genau diesem Szenario

16.12 Was sollst du aus dem Beispiel wirklich mitnehmen?

1. Konflikte sind normal. Sie sind ein Zeichen paralleler Arbeit, nicht von Versagen.
2. Git löst Syntax-Konflikte, Menschen lösen Fachkonflikte.
3. Rebase und Merge lösen dasselbe Integrationsproblem, aber mit unterschiedlicher Historie.
4. git status ist dein Rettungsanker, wenn du unsicher bist.
5. Tests und PR-Kommunikation sind Teil der Konfliktlösung – nicht nur der Code selbst.

17. Remote, origin, fetch, pull, push

Ein Remote ist eine entfernte Kopie deines Repositories. Bei GitHub heißt der Standard-Remote meistens origin.

17.1 Remote anzeigen

git remote -v

Beispielausgabe:

origin  git@github.com:team/shop.git (fetch)
origin  git@github.com:team/shop.git (push)

17.2 Push

git push

Push sendet lokale Commits zum Remote.

Beim ersten Push eines neuen Branches:

git push -u origin feature/login

-u setzt die Upstream-Verbindung. Danach weiß Git, wohin dieser Branch standardmäßig pushen und pullen soll.

17.3 Fetch

git fetch origin

Fetch lädt Informationen vom Remote herunter, integriert sie aber noch nicht in deinen aktuellen Branch. Danach kannst du zum Beispiel origin/main sehen.

17.4 Pull

git pull

Pull bedeutet grob: fetch plus Integration. Je nach Konfiguration integriert Git per Merge oder Rebase.

Viele Teams nutzen für Feature-Branches gerne:

git pull --rebase

Das hält deinen lokalen Feature-Branch linearer.

17.5 main und origin/main unterscheiden

main ist dein lokaler Branch. origin/main ist dein letzter bekannter Stand von main auf dem Remote. Nach git fetch kann origin/main weiter sein als dein lokaler main.

Typischer Ablauf, um lokalen main zu aktualisieren:

git switch main
git fetch origin
git pull

Oder expliziter:

git switch main
git fetch origin
git merge origin/main

18. GitHub-Grundlagen: Repository, Issues, Pull Requests

GitHub ergänzt Git um Kollaboration.

18.1 Repository auf GitHub

Ein GitHub-Repository enthält nicht nur Code, sondern oft auch:

• README,
• Issues,
• Pull Requests,
• Actions-Workflows,
• Releases,
• Wiki oder Discussions,
• Branch-Schutzregeln,
• Berechtigungen.

18.2 Issues

Issues beschreiben Aufgaben, Bugs oder Ideen. Ein gutes Issue beantwortet:

• Was ist das Problem oder Ziel?
• Warum ist es wichtig?
• Welche Akzeptanzkriterien gibt es?
• Welche Dateien oder Bereiche sind betroffen?

Beispiel:

## Ziel
Checkout soll Rabattcodes akzeptieren.

## Akzeptanzkriterien
- Gültiger Rabattcode reduziert den Gesamtpreis.
- Ungültiger Code zeigt eine Fehlermeldung.
- Tests für gültige und ungültige Codes existieren.

18.3 Pull Requests

Ein Pull Request ist ein Vorschlag, Änderungen in einen Zielbranch zu integrieren. Er zeigt:

• welche Commits enthalten sind,
• welche Dateien geändert wurden,
• Diskussionen und Reviews,
• automatische Checks,
• Merge-Optionen.

Ein PR ist nicht nur ein technischer Merge-Knopf. Er ist ein Kommunikationsort.

19. Pull Requests Schritt für Schritt

19.1 Lokalen Branch erstellen

git switch main
git pull
git switch -c feature/checkout-validation

19.2 Arbeiten und committen

# Dateien ändern
git status
git diff
git add src/checkout.js test/checkout.test.js
git commit -m "Add checkout validation"

19.3 Branch pushen

git push -u origin feature/checkout-validation

GitHub zeigt danach oft direkt einen Button zum Erstellen eines Pull Requests.

19.4 Gute PR-Beschreibung

## Was wurde geändert?
- Checkout validiert leere Adressfelder.
- Fehlermeldung wird im Formular angezeigt.
- Tests für ungültige Eingaben ergänzt.

## Warum?
Bisher konnten unvollständige Bestellungen an den Payment-Service gelangen.

## Test
- npm test
- Manuell: Checkout mit leerer Straße geprüft

19.5 Review einarbeiten

Wenn ein Reviewer Änderungen verlangt:

# lokal Dateien ändern
git add .
git commit -m "Address checkout review feedback"
git push

Der Pull Request aktualisiert sich automatisch.

19.6 Merge-Optionen auf GitHub

GitHub unterstützt je nach Repository-Einstellung verschiedene Methoden: Merge commit, Squash and merge und Rebase and merge.

• Merge commit: behält die Branch-Struktur sichtbar.
• Squash and merge: macht aus dem PR einen Commit auf main.
• Rebase and merge: übernimmt die einzelnen Commits ohne Merge-Commit auf den Zielbranch.

Welche Option „richtig“ ist, entscheidet das Team. Wichtig ist Konsistenz.

20. Forks und Open-Source-Workflow

Ein Fork ist eine Kopie eines fremden Repositories unter deinem GitHub-Konto. Du nutzt Forks oft, wenn du keine direkten Schreibrechte im Originalprojekt hast.

20.1 Grundidee

Original-Projekt → dein Fork → dein lokaler Clone → Pull Request zurück zum Original

20.2 Typischer Ablauf

1. Fork auf GitHub erstellen.
2. Deinen Fork lokal klonen:

git clone git@github.com:deinname/projekt.git
cd projekt

3. Original als upstream hinzufügen:

git remote add upstream git@github.com:original/projekt.git
git remote -v

4. Branch erstellen:

git switch -c fix/readme-typo

5. Commit und Push:

git add _intern/sources/_intern\sources\README.md
git commit -m "Fix README typo"
git push -u origin fix/readme-typo

6. Pull Request vom Fork zum Original öffnen.

20.3 Fork aktuell halten

git fetch upstream
git switch main
git merge upstream/main
git push origin main

Oder für Feature-Branch:

git fetch upstream
git switch fix/readme-typo
git rebase upstream/main
git push --force-with-lease

Achtung: Bei Open-Source-Projekten solltest du die Contributing-Regeln lesen. Manche Projekte wollen Squash-Commits, andere klare Einzelcommits.

21. GitHub Actions, Releases, Tags und Schutzregeln

21.1 GitHub Actions

GitHub Actions automatisieren Aufgaben. Häufige Beispiele:

• Tests bei jedem Pull Request,
• Linting,
• Build,
• Deployment,
• Release-Erstellung.

Beispiel für einen einfachen Workflow:

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

Erklärung:

• on sagt, wann der Workflow läuft.
• jobs enthält die Aufgaben.
• runs-on legt die Umgebung fest.
• steps sind einzelne Schritte.

21.2 Tags

Ein Tag markiert einen bestimmten Commit, oft für Versionen.

git tag v1.0.0
git push origin v1.0.0

Annotated Tag mit Nachricht:

git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0

21.3 Releases

Ein GitHub Release baut oft auf einem Tag auf und enthält Release Notes, Downloads oder Artefakte.

Gute Release Notes enthalten:

• neue Features,
• Bugfixes,
• Breaking Changes,
• Migrationshinweise.

21.4 Branch-Schutzregeln

Professionelle Teams schützen main häufig:

• Pull Request erforderlich,
• mindestens ein Review,
• erfolgreiche CI-Checks,
• keine direkten Pushes,
• optional lineare Historie.

Das verhindert, dass versehentlich ungetestete Änderungen direkt in main landen.

22. VS Code Git-Benutzung bildlich erklärt

VS Code hat eine integrierte Source-Control-Ansicht. Sie ist besonders gut, um Änderungen zu sehen, Diffs zu prüfen, einzelne Dateien zu stage-n und Konflikte visuell zu lösen.

22.1 Die wichtigsten Orte in VS Code

22.2 VS Code: Änderung committen

1. Öffne dein Repository in VS Code.
2. Ändere eine Datei, zum Beispiel _intern/sources/_intern\sources\README.md.
3. Klicke links auf Source Control.
4. Öffne den Diff, um die Änderung zu prüfen.
5. Klicke auf +, um die Datei zu stage-n.
6. Schreibe eine Commit-Nachricht.
7. Klicke auf Commit.

Terminal-Übersetzung:

git status
git diff
git add _intern/sources/_intern\sources\README.md
git commit -m "Update README"

22.3 VS Code: Branch erstellen

1. Klicke unten links auf den Branch-Namen.
2. Wähle Create new branch.
3. Gib zum Beispiel feature/profile-page ein.

Terminal-Übersetzung:

git switch -c feature/profile-page

22.4 VS Code: Pull, Push und Sync verstehen

Der Button Sync Changes kann Pull und Push kombinieren. Das ist bequem, aber du solltest verstehen, was passiert.

Vor Sync:

git status
git log --oneline --graph --decorate --all

Wenn du genau steuern willst, nutze im Terminal:

git pull --rebase
git push

22.5 VS Code: Konflikte lösen

Wenn ein Konflikt entsteht, zeigt VS Code Optionen wie:

• Accept Current Change,
• Accept Incoming Change,
• Accept Both Changes,
• Compare Changes,
• Resolve in Merge Editor.

Wichtig: Klicke nicht blind. Lies beide Varianten und entscheide fachlich.

Nach der Lösung:

git add <datei>

Bei Merge:

git commit

Bei Rebase:

git rebase --continue

22.6 VS Code Beispiel: Rebase vor Pull Request

git switch feature/cart-summary
git fetch origin
git rebase origin/main
npm test
git push --force-with-lease

In VS Code kannst du die Konfliktdateien visuell öffnen, aber der Ablauf bleibt derselbe. VS Code ersetzt nicht Git. VS Code zeigt Git nur komfortabler an.

22.7 Wann VS Code besonders hilfreich ist

VS Code ist stark bei:

• Diffs schnell ansehen,
• einzelne Dateien stage-n,
• Merge-Konflikte visuell lösen,
• kleine Pull-Request-Änderungen prüfen,
• Terminal und Editor nebeneinander nutzen.

Für gefährliche Befehle wie reset --hard, rebase -i oder Force Push solltest du trotzdem genau verstehen, welcher Git-Befehl ausgeführt wird.

23. IntelliJ IDEA Git-Benutzung bildlich erklärt

IntelliJ IDEA hat sehr starke Git-Werkzeuge, besonders für Java/Kotlin-Projekte: Commit Tool Window, Git Log, Branch-Widget, Diff-Ansichten, Konflikt-Dialog, Shelve/Stash und integriertes Terminal.

23.1 Die wichtigsten Orte in IntelliJ IDEA

23.2 IntelliJ: Projekt klonen

Typischer Weg:

1. Startfenster öffnen.
2. Get from Version Control wählen.
3. GitHub- oder SSH-URL einfügen.
4. Zielordner wählen.
5. Klonen.

Terminal-Übersetzung:

git clone git@github.com:team/shop.git

23.3 IntelliJ: Commit erstellen

1. Öffne das Commit Tool Window.
2. Prüfe die geänderten Dateien.
3. Öffne Diffs, bevor du commitest.
4. Wähle nur Dateien aus, die fachlich zusammengehören.
5. Schreibe eine konkrete Commit-Nachricht.
6. Klicke Commit oder Commit and Push.

Empfehlung: Für Lernende ist oft besser: erst Commit, danach separat Push. Dann verstehst du den Unterschied zwischen lokalem Speichern und Hochladen.

23.4 IntelliJ: Branch erstellen

1. Klicke auf das Branch/VCS-Widget.
2. Wähle New Branch.
3. Name: feature/order-history.
4. Checkout aktiv lassen.

Terminal-Übersetzung:

git switch -c feature/order-history

23.5 IntelliJ: Pull mit Merge oder Rebase

IntelliJ kann beim Aktualisieren eines Projekts Änderungen per Merge oder Rebase integrieren. Der Unterschied bleibt derselbe:

• Merge: Integration mit sichtbarer Branch-Struktur.
• Rebase: deine lokalen Commits werden auf den neuen Stand gesetzt.

Für Feature-Branches ist Rebase oft sauber. Für geteilte Branches ist Merge sicherer, wenn nicht alle abgesprochen haben.

23.6 IntelliJ: Konflikte lösen

Der Konflikt-Dialog zeigt meist drei Bereiche:

• deine Version,
• eingehende Version,
• Ergebnis.

Du übernimmst nicht einfach „links“ oder „rechts“, sondern baust einen korrekten Endzustand. Danach:

• Datei als gelöst markieren,
• Tests laufen lassen,
• Merge committen oder Rebase fortsetzen.

Terminal-Übersetzung bei Rebase:

git add <datei>
git rebase --continue

23.7 IntelliJ: Git Log sinnvoll nutzen

Das Git Log in IntelliJ ist sehr wertvoll, weil du Branches und Commits visuell siehst. Nutze es, um Fragen zu beantworten:

• Auf welchem Branch bin ich?
• Welche Commits sind nur lokal?
• Welche Commits sind schon auf origin/main?
• Wo wurde ein Branch gemerged?
• Was genau hat ein Commit geändert?

23.8 IntelliJ Beispiel: Merge eines Feature-Branches

git switch main
git pull
git merge feature/order-history
./gradlew test
git push

In IntelliJ entspricht das:

1. main über Branch-Widget auschecken.
2. Projekt aktualisieren.
3. Branch feature/order-history in main mergen.
4. Tests ausführen.
5. Push-Dialog prüfen und pushen.

24. GUI oder Terminal: Entscheidungshilfe

Die beste Strategie ist nicht „nur Terminal“ oder „nur GUI“. Die beste Strategie ist: Begriffe verstehen, Werkzeug passend wählen.

24.1 Nutze GUI für Sichtbarkeit

GUI ist sehr gut für:

• Diffs ansehen,
• Dateien vergleichen,
• einzelne Änderungen stage-n,
• Konflikte visuell lösen,
• Historie grob erfassen.

24.2 Nutze Terminal für Präzision

Terminal ist sehr gut für:

• genaue Befehle lernen,
• Fehlerdiagnose,
• Rebase und Reset bewusst ausführen,
• Skripte,
• reproduzierbare Anleitungen.

24.3 Übersetzungstabelle GUI → Terminal

25. 6-Wochen-Lernplan

Woche 1: Lokale Grundlagen

Ziele: Repository erstellen, Dateien stage-n, committen, Status und Diff verstehen.

Übungen:

git init
git status
git add
git commit
git diff
git log --oneline

Abschluss: Du kannst erklären, warum git add und git commit zwei verschiedene Schritte sind.

Woche 2: Historie und Undo

Ziele: Historie lesen, einzelne Commits ansehen, sichere Undo-Strategien anwenden.

Übungen:

git log --oneline --graph --decorate --all
git show <commit>
git restore <datei>
git restore --staged <datei>
git revert <commit>
git reflog

Abschluss: Du weißt, wann revert sicherer ist als reset.

Woche 3: Branches und Merge

Ziele: Feature-Branches erstellen, wechseln, mergen und löschen.

Übungen:

git switch -c feature/readme-section
git commit -m "Add README section"
git switch main
git merge feature/readme-section
git branch -d feature/readme-section

Abschluss: Du kannst Fast-forward und Merge-Commit unterscheiden.

Woche 4: Rebase und Konflikte

Ziele: Rebase sicher anwenden, Konflikte bewusst lösen.

Übungen:

git fetch origin
git rebase origin/main
git rebase --continue
git rebase --abort
git push --force-with-lease

Abschluss: Du kannst erklären, warum Rebase Commit-IDs verändert.

Woche 5: GitHub und Pull Requests

Ziele: Remote verbinden, Branch pushen, PR erstellen, Review einarbeiten.

Übungen:

git remote -v
git push -u origin feature/name
git pull --rebase
git push

Abschluss: Du kannst eine gute PR-Beschreibung schreiben.

Woche 6: IDEs und professioneller Alltag

Ziele: Git in VS Code und IntelliJ bedienen, GUI-Aktionen auf Terminal-Befehle abbilden, CI und Releases einordnen.

Übungen:

• In VS Code eine Datei stage-n, committen und pushen.
• In IntelliJ Git Log öffnen und einen Branch vergleichen.
• Einen Konflikt visuell lösen und danach per Terminal fortsetzen.
• Einen einfachen GitHub Actions Workflow lesen.

Abschluss: Du kannst erklären, wann du GUI und wann Terminal bevorzugst.

26. Praxisprojekte

Projekt 1: Persönliches Lernjournal

Erstelle ein Repository learning-journal mit:

• _intern/sources/_intern\sources\README.md,
• week-01.md,
• week-02.md,
• Branch docs/add-git-notes,
• Pull Request auf GitHub.

Ziel: Git-Grundlagen ohne komplexen Code üben.

Projekt 2: Kleine Webseite

Erstelle eine HTML/CSS-Webseite mit drei Branches:

feature/header
feature/contact-section
fix/mobile-layout

Übe:

• Branches erstellen,
• getrennte Commits,
• Merge,
• Pull Request,
• Konflikt absichtlich erzeugen.

Projekt 3: Webshop-Simulation

Lege Dateien an:

src/checkout.js
src/payment.js
test/checkout.test.js
_intern/sources/_intern\sources\README.md

Simuliere drei Personen mit drei Branches:

feature/coupon-code
feature/tax-calculation
fix/payment-error

Ziel: Merge/Rebase und Konflikte realitätsnah üben.

Projekt 4: Open-Source-Fork üben

Nutze ein eigenes zweites GitHub-Repository als „Original“. Forke es, ändere im Fork eine Datei und öffne einen Pull Request zurück.

Ziel: Fork, upstream, origin und PR-Richtung verstehen.

27. Cheat-Sheets

27.1 Tägliche Befehle

git status
git diff
git add <datei>
git diff --staged
git commit -m "Nachricht"
git log --oneline --graph --decorate --all

27.2 Branches

git branch
git branch -a
git switch main
git switch -c feature/name
git branch -d feature/name

27.3 Remote

git remote -v
git fetch origin
git pull
git pull --rebase
git push
git push -u origin feature/name

27.4 Merge

git switch main
git pull
git merge feature/name
git push

27.5 Rebase

git switch feature/name
git fetch origin
git rebase origin/main
git add <konfliktdatei>
git rebase --continue
git rebase --abort
git push --force-with-lease

27.6 Undo

git restore <datei>
git restore --staged <datei>
git reset --soft HEAD~1
git reset --mixed HEAD~1
git revert <commit>
git reflog

27.7 VS Code

Source Control öffnen
Diff prüfen
+ zum Stage-n
Commit-Nachricht schreiben
Commit klicken
Sync bewusst benutzen
Bei Konflikt Merge Editor öffnen

27.8 IntelliJ IDEA

VCS Widget für Branches
Commit Tool Window für Commit-Auswahl
Git Log für Historie
Push Dialog vor dem Hochladen prüfen
Resolve Conflicts für Konflikte
Terminal für genaue Git-Befehle

28. Fehlerdiagnose

Problem: Ich weiß nicht, wo ich bin

git status
git branch
git log --oneline --graph --decorate --all -10

Prüfe:

• aktueller Branch,
• uncommittete Änderungen,
• lokale Commits,
• Remote-Stand.

Problem: Pull geht nicht wegen lokaler Änderungen

Git schützt deine Arbeit. Optionen:

1. Änderungen committen:

git add .
git commit -m "Save work before pull"
git pull --rebase

2. Änderungen temporär stashen:

git stash
git pull --rebase
git stash pop

Problem: Ich habe auf dem falschen Branch gearbeitet

Wenn noch nicht committed:

git switch -c richtiger-branch

Wenn schon committed:

git branch richtiger-branch
git switch main
git reset --hard HEAD~1

Nur nutzen, wenn der Commit noch nicht geteilt wurde. Sicherer ist oft Cherry-Pick:

git switch richtiger-branch
git cherry-pick <commit-id>

Problem: Rebase ist chaotisch

git status

Wenn du abbrechen willst:

git rebase --abort

Wenn du schon fertig bist, aber den alten Stand suchst:

git reflog

Problem: Push wird abgelehnt

Wahrscheinlich ist der Remote weiter als dein lokaler Branch.

git fetch origin
git log --oneline --graph --decorate --all

Dann je nach Teamregel:

git pull --rebase
git push

Oder:

git pull
git push

Problem: Force Push nötig nach Rebase

Nur auf deinem eigenen Feature-Branch:

git push --force-with-lease

Nicht blind auf main und nicht auf gemeinsam genutzten Branches.

29. Abschlusscheck

Du bist sicher mit Git/GitHub, wenn du diese Fragen beantworten kannst:

1. Was ist der Unterschied zwischen Working Directory, Staging Area und Repository?
2. Warum ist ein Commit mehr als eine Dateiänderung?
3. Was zeigt HEAD?
4. Was ist der Unterschied zwischen main und origin/main?
5. Wann benutzt du git restore?
6. Wann ist git revert besser als git reset?
7. Was passiert bei einem Fast-forward-Merge?
8. Was ist ein Merge-Commit?
9. Warum verändert Rebase Commit-IDs?
10. Warum sollte man geteilte Branches nicht ohne Absprache rebase-n?
11. Wie löst du einen Konflikt bei Merge?
12. Wie löst du einen Konflikt bei Rebase?
13. Was ist der Unterschied zwischen Pull und Fetch?
14. Was ist ein Pull Request?
15. Wann ist Squash and merge sinnvoll?
16. Wie hältst du einen Fork aktuell?
17. Wofür nutzt du GitHub Actions?
18. Wie findest du Git-Funktionen in VS Code?
19. Wie findest du Git-Funktionen in IntelliJ IDEA?
20. Wann nutzt du GUI, wann Terminal?

Wenn du mindestens 16 Fragen klar beantworten kannst, hast du eine sehr gute Grundlage.

30. Einfach erklärt: alle Themen in Alltagssprache

Dieses Kapitel ist eine zweite Erklärungsebene. Wenn dir ein Thema zu abstrakt vorkommt, lies zuerst die einfache Erklärung hier und gehe dann zurück zum ausführlichen Kapitel.

30.1 Die große Landkarte

30.2 Git-Grundmodell ganz einfach

Git speichert nicht einfach „Dateien“. Git speichert Schnappschüsse deines Projekts. Ein Commit sagt: „Diese ausgewählten Änderungen gehören zusammen und haben einen Sinn.“

Die wichtigste Reihenfolge ist:

ändern → prüfen → auswählen → speichern → teilen

In Git-Befehlen:

git status
git diff
git add datei.js
git commit -m "Beschreibe die Änderung"
git push

Wenn du unsicher bist, beginne fast immer mit:

git status

git status ist wie ein Lagebericht. Er sagt dir, ob du Dateien geändert hast, ob etwas gestaged ist, ob ein Merge/Rebase läuft und was Git als nächsten Schritt erwartet.

30.3 Staging Area ganz einfach

Die Staging Area ist der Bereich zwischen „ich habe etwas geändert“ und „ich speichere es endgültig als Commit“.

Stell dir vor, du hast drei Änderungen gemacht:

1. Login-Text verbessert.
2. CSS-Farbe geändert.
3. Debug-Ausgabe eingefügt.

Vielleicht sollen nur 1 und 2 in den Commit. Dann legst du nur diese Änderungen in die Staging Area. Die Debug-Ausgabe bleibt draußen.

git add login.html styles.css
git commit -m "Improve login text and styling"

Merksatz: Committe nicht alles, was zufällig geändert wurde. Committe das, was logisch zusammengehört.

30.4 Branches ganz einfach

Ein Branch ist eine Arbeitslinie. Du kannst auf einem Branch etwas ausprobieren, ohne main sofort zu verändern.

git switch -c feature/profile-page

Das bedeutet: „Ich öffne eine neue Arbeitslinie für die Profilseite.“

Wenn die Arbeit fertig ist, kommt sie später zurück nach main, meistens über einen Pull Request.

30.5 Merge ganz einfach

Merge heißt: „Nimm die Arbeit aus einem Branch und füge sie in einen anderen Branch ein.“

Beispiel:

git switch main
git merge feature/profile-page

Wenn Git alles automatisch zusammensetzen kann, ist der Merge schnell erledigt. Wenn nicht, entsteht ein Konflikt. Dann musst du die richtige Endversion schreiben.

Merge ist besonders gut, wenn sichtbar bleiben soll, dass ein Feature als eigener Branch entstanden ist.

30.6 Rebase ganz einfach

Rebase heißt: „Nimm meine Commits und spiele sie so ab, als hätte ich erst auf dem neuesten main angefangen.“

git switch feature/profile-page
git fetch origin
git rebase origin/main

Das macht die Historie oft sauberer. Aber Rebase verändert Commit-IDs. Deshalb gilt:

Rebase deine eigenen lokalen oder persönlichen Feature-Branches. Rebase nicht leichtfertig Branches, auf denen andere Menschen bereits arbeiten.

Nach einem Rebase brauchst du beim Push oft:

git push --force-with-lease

Das ist sicherer als --force, weil Git prüft, ob sich der Remote unerwartet verändert hat.

30.7 Konflikte ganz einfach

Ein Konflikt bedeutet: Git konnte nicht sicher entscheiden, welche Endversion richtig ist.

Konfliktmarker sehen so aus:

<<<<<<< HEAD
Version A
=======
Version B
>>>>>>> branch-name

Deine Aufgabe ist nicht, blind A oder B zu wählen. Deine Aufgabe ist:

1. beide Seiten verstehen,
2. fachlich richtige Endversion schreiben,
3. Marker entfernen,
4. testen,
5. Git sagen, dass der Konflikt gelöst ist.

Bei Merge:

git add datei.js
git commit

Bei Rebase:

git add datei.js
git rebase --continue

30.8 GitHub ganz einfach

Git ist das Werkzeug. GitHub ist die Plattform, auf der dein Team Repositories, Pull Requests, Issues, Reviews und Automatisierungen organisiert.

Ein typischer Teamablauf:

Issue → Branch → Commit → Push → Pull Request → Review → Tests → Merge

Der Pull Request ist dabei nicht nur ein technischer Schritt. Er ist ein Gespräch über Code: Was wurde geändert, warum wurde es geändert, wie wurde es getestet?

30.9 VS Code und IntelliJ ganz einfach

VS Code und IntelliJ benutzen im Hintergrund Git. Die GUI ersetzt Git nicht. Sie zeigt dir Git-Zustände visuell.

Merksatz: Wenn du in der GUI unsicher bist, öffne das Terminal und tippe git status. Das erklärt meistens den Zustand.

31. Praxisaufgaben mit Lösungen

Arbeite diese Aufgaben in einem Testordner durch. Du kannst nichts kaputt machen, wenn du ein extra Übungsrepository nutzt.

31.1 Aufgabe 1: Erstes Repository und erster Commit

Ziel: Du verstehst init, status, add, commit.

mkdir git-training
cd git-training
git init
echo "# Git Training" > _intern/sources/_intern\sources\README.md
git status
git add _intern/sources/_intern\sources\README.md
git commit -m "Add README"
git log --oneline

Lösungserklärung:

• Nach git init ist der Ordner ein Git-Repository.
• Nach dem Erstellen von _intern/sources/_intern\sources\README.md zeigt git status eine untracked Datei.
• git add legt sie in die Staging Area.
• git commit speichert sie dauerhaft in der Historie.

31.2 Aufgabe 2: Staging bewusst benutzen

Ziel: Du commitest nur passende Dateien.

echo "Login text" > login.txt
echo "Debug output" > debug.log
git status
git add login.txt
git status
git commit -m "Add login text"

Lösungserklärung:

Nur login.txt wird committed. debug.log bleibt uncommitted. Das zeigt: Git speichert nicht automatisch alle Änderungen, sondern nur das, was du auswählst.

Optional:

git restore debug.log

Damit verwirfst du die Debug-Datei, falls du sie nicht brauchst.

31.3 Aufgabe 3: Branch erstellen und zurückwechseln

Ziel: Du verstehst Branches als getrennte Arbeitslinien.

git switch -c feature/header
echo "Header" > header.txt
git add header.txt
git commit -m "Add header"
git switch main
git status
ls

Lösungserklärung:

Auf main siehst du header.txt eventuell nicht, weil die Datei nur im Feature-Branch committed wurde. Branches können also unterschiedliche Projektstände zeigen.

31.4 Aufgabe 4: Fast-forward-Merge

Ziel: Du verstehst den einfachsten Merge.

git switch main
git merge feature/header
git log --oneline --graph --decorate

Lösungserklärung:

Wenn main seit dem Abzweigen nicht weitergelaufen ist, kann Git einfach den Zeiger von main nach vorne schieben. Das heißt Fast-forward.

31.5 Aufgabe 5: Echter Merge-Commit

Ziel: Du siehst eine verzweigte Historie.

git switch -c feature/footer
echo "Footer" > footer.txt
git add footer.txt
git commit -m "Add footer"

git switch main
echo "Main note" > main-note.txt
git add main-note.txt
git commit -m "Add main note"

git merge feature/footer
git log --oneline --graph --decorate --all

Lösungserklärung:

Jetzt sind beide Branches weitergelaufen. Git erstellt beim Merge wahrscheinlich einen Merge-Commit, weil zwei Linien zusammengeführt werden.

31.6 Aufgabe 6: Konflikt absichtlich erzeugen

Ziel: Du löst einen Konflikt ohne Angst.

echo "Preis: 10" > price.txt
git add price.txt
git commit -m "Add price"

git switch -c feature/discount
echo "Preis: 8 mit Rabatt" > price.txt
git add price.txt
git commit -m "Add discount price"

git switch main
echo "Preis: 10 plus Versand" > price.txt
git add price.txt
git commit -m "Add shipping info"

git merge feature/discount

Jetzt entsteht ein Konflikt in price.txt.

Mögliche Lösung in price.txt:

Preis: 8 mit Rabatt plus Versand

Dann:

git add price.txt
git commit

Lösungserklärung:

Du hast nicht einfach eine Seite gewählt, sondern beide fachlichen Ideen kombiniert: Rabatt und Versand.

31.7 Aufgabe 7: Rebase üben

Ziel: Du verstehst, wie ein Feature-Branch aktualisiert wird.

git switch -c feature/about
echo "About page" > about.txt
git add about.txt
git commit -m "Add about page"

git switch main
echo "Imprint" > imprint.txt
git add imprint.txt
git commit -m "Add imprint"

git switch feature/about
git rebase main
git log --oneline --graph --decorate --all

Lösungserklärung:

Der Commit aus feature/about wird so neu abgespielt, als wäre er nach dem aktuellen main entstanden. Dadurch wirkt die Historie linearer.

31.8 Aufgabe 8: Undo unterscheiden

Ziel: Du wählst das richtige Rettungswerkzeug.

Mini-Übung: Ändere eine Datei, stage sie und entferne sie wieder aus der Staging Area:

echo "temporary" >> _intern/sources/_intern\sources\README.md
git add _intern/sources/_intern\sources\README.md
git restore --staged _intern/sources/_intern\sources\README.md
git status

31.9 Aufgabe 9: Pull Request sauber vorbereiten

Ziel: Du lernst, wie ein PR gut lesbar wird.

git switch -c feature/readme-structure
echo "## Installation" >> _intern/sources/_intern\sources\README.md
echo "## Usage" >> _intern/sources/_intern\sources\README.md
git add _intern/sources/_intern\sources\README.md
git commit -m "Structure README"
git push -u origin feature/readme-structure

Gute PR-Beschreibung:

Zusammenfassung:
- README in Installation und Usage gegliedert.

Warum:
- Neue Nutzer finden schneller den Einstieg.

Test:
- Markdown lokal geprüft.

Lösungserklärung:

Ein guter PR beantwortet nicht nur „was“, sondern auch „warum“ und „wie getestet“.

31.10 Aufgabe 10: Gleiches Problem in VS Code und IntelliJ lösen

Ziel: Du erkennst dieselbe Git-Logik in zwei GUIs.

1. Erzeuge Aufgabe 6 erneut in einem frischen Repo.
2. Öffne den Ordner in VS Code.
3. Löse den Konflikt im Merge Editor.
4. Wiederhole die Aufgabe in IntelliJ IDEA.
5. Löse den Konflikt im 3-Wege-Merge-Dialog.

Lösungserklärung:

Beide Oberflächen zeigen denselben Git-Zustand. Der Unterschied ist nur die Darstellung. Die fachliche Entscheidung bleibt gleich.

31.11 Selbstkontrolle nach jeder Aufgabe

Nach jeder Übung beantwortest du drei Fragen:

1. Was zeigt git status?
2. Was zeigt git log --oneline --graph --decorate --all?
3. Welche Änderung ist nur lokal und welche ist bereits auf GitHub?

Wenn du diese drei Fragen beantworten kannst, verstehst du nicht nur Befehle, sondern den Zustand deines Repositories.

32. Spezialkapitel: Konflikte, Merge und Rebase in VS Code & IntelliJ

Dieses Kapitel vertieft genau den Bereich, der in Teams am meisten Unsicherheit erzeugt: Was mache ich, wenn die IDE einen Konflikt zeigt?

32.1 Wichtigster Grundsatz

VS Code und IntelliJ lösen nicht automatisch dein fachliches Problem. Sie zeigen dir nur besser, wo zwei Änderungen kollidieren.

Die Reihenfolge ist immer:

git status lesen → Konfliktdatei öffnen → fachlich lösen → speichern → stagen → testen → Merge/Rebase fortsetzen

32.2 VS Code: Konflikt bei Merge lösen

Typisches Szenario:

git switch main
git merge feature/checkout-tax

Wenn ein Konflikt entsteht, zeigt VS Code die Datei im Source-Control-Bereich und meistens direkt im Editor.

Ablauf in VS Code:

1. Source Control öffnen.
2. Konfliktdatei anklicken.
3. Im Merge Editor oder direkt im Editor beide Seiten ansehen.
4. Nicht blind Accept Current oder Accept Incoming wählen.
5. Endversion schreiben.
6. Datei speichern.
7. Datei stagen.
8. Commit erstellen.

Terminal-Entsprechung:

git status
# Datei bearbeiten
git add checkout.js
git commit

32.3 VS Code: Konflikt bei Rebase lösen

Typisches Szenario:

git switch feature/checkout-tax
git fetch origin
git rebase origin/main

Wenn ein Konflikt entsteht, pausiert Rebase. Nach dem Lösen klickst du nicht einfach einen normalen Commit wie bei Merge, sondern du setzt den Rebase fort.

Terminal-Entsprechung:

git status
# Datei bearbeiten
git add checkout.js
git rebase --continue

Wenn du dich verrannt hast:

git rebase --abort

Wichtig: Bei Rebase können Begriffe wie „Current“ und „Incoming“ verwirrend sein, weil Git gerade Commits neu abspielt. Verlasse dich deshalb nicht nur auf die Button-Namen. Lies den Code und entscheide fachlich.

32.4 IntelliJ IDEA: Konflikt bei Merge lösen

Typisches Szenario:

git switch main
git merge feature/checkout-tax

In IntelliJ erscheint ein Konflikt meistens im Commit-/Changes-Bereich oder in einem Resolve-Dialog.

Ablauf in IntelliJ:

1. Konflikt in Local Changes/Commit Tool Window öffnen.
2. Resolve oder Merge wählen.
3. Im 3-Wege-Merge-Dialog linke und rechte Seite vergleichen.
4. In der Ergebnis-Spalte die fachlich richtige Endversion bauen.
5. Konflikt als gelöst markieren.
6. Tests ausführen.
7. Merge-Commit abschließen.

Terminal-Entsprechung:

git status
# Datei bearbeiten / im Merge-Dialog lösen
git add checkout.js
git commit

32.5 IntelliJ IDEA: Konflikt bei Rebase lösen

Typisches Szenario:

git switch feature/checkout-tax
git fetch origin
git rebase origin/main

Ablauf:

1. IntelliJ zeigt den Konflikt an.
2. Öffne den Merge-Dialog.
3. Vergleiche beide Seiten.
4. Schreibe die kombinierte Endversion in die Ergebnis-Spalte.
5. Markiere den Konflikt als gelöst.
6. Führe Tests aus.
7. Setze Rebase fort.

Terminal-Entsprechung:

git add checkout.js
git rebase --continue

Abbrechen:

git rebase --abort

32.6 Current und Incoming richtig verstehen

Diese Begriffe sind der häufigste Grund für falsche Konfliktlösungen.

Merksatz: Button-Namen helfen, aber sie ersetzen nicht das Verständnis der Änderung.

32.7 Entscheidung: GUI oder Terminal im Konflikt?

32.8 Komplexes Mini-Szenario für IDEs

Ausgangslage: Zwei Personen ändern checkout.js.

Aylin fügt Coupon-Logik ein:

const discount = coupon ? coupon.amount : 0;
return subtotal - discount + shipping;

Mert fügt Steuerlogik ein:

const tax = subtotal * 0.19;
return subtotal + tax + shipping;

Die richtige kombinierte Endversion kann sein:

const discount = coupon ? coupon.amount : 0;
const taxableAmount = Math.max(subtotal - discount, 0);
const tax = taxableAmount * 0.19;
return taxableAmount + tax + shipping;

In VS Code oder IntelliJ darfst du also nicht nur eine Seite übernehmen. Du musst eine dritte, fachlich bessere Version bauen.

32.9 Checkliste für Konflikte in IDEs

• Habe ich git status gelesen?
• Weiß ich, ob gerade Merge oder Rebase läuft?
• Habe ich beide Seiten des Konflikts verstanden?
• Habe ich die Marker vollständig entfernt?
• Habe ich die fachlich richtige Endversion gebaut?
• Habe ich die Datei gestaged?
• Habe ich Tests ausgeführt?
• Habe ich bei Rebase rebase --continue und bei Merge einen Commit gemacht?
• Habe ich bei Rebase danach mit --force-with-lease gepusht, falls nötig?

32.10 Notfallbefehle

Wenn du nicht weißt, ob du abbrechen oder fortsetzen sollst: zuerst git status, dann entscheiden.

33. Quellen

Die Inhalte orientieren sich an den offiziellen Dokumentationen und stabilen Lernressourcen:

• Git Reference: https://git-scm.com/docs
• Git Rebase Dokumentation: https://git-scm.com/docs/git-rebase
• Pro Git Book – Rebasing: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
• GitHub Docs – Pull Request Merges: https://docs.github.com/articles/about-pull-request-merges
• GitHub Docs – Merge Methods: https://docs.github.com/articles/about-merge-methods-on-github
• VS Code Docs – Source Control: https://code.visualstudio.com/docs/sourcecontrol/overview
• JetBrains IntelliJ IDEA Docs – Commit and Push: https://www.jetbrains.com/help/idea/commit-and-push-changes.html
• JetBrains IntelliJ IDEA Docs – Merge, Rebase, Cherry-pick: https://www.jetbrains.com/help/idea/apply-changes-from-one-branch-to-another.html
• JetBrains IntelliJ IDEA Docs – Set up Git repository: https://www.jetbrains.com/help/idea/set-up-a-git-repository.html

Anhang: Mini-Lernkarten

Karte 1: Was ist git add?
Antwort: Es nimmt Änderungen in die Staging Area auf.

Karte 2: Was ist git commit?
Antwort: Es speichert einen Snapshot in der lokalen Historie.

Karte 3: Was ist git push?
Antwort: Es sendet lokale Commits zum Remote.

Karte 4: Was ist git fetch?
Antwort: Es lädt Remote-Informationen, ohne deinen aktuellen Branch zu verändern.

Karte 5: Was ist git pull?
Antwort: Fetch plus Integration, meistens Merge oder Rebase.

Karte 6: Was ist ein Konflikt?
Antwort: Git kann zwei Änderungen nicht automatisch kombinieren und braucht eine fachliche Entscheidung.

Karte 7: Was ist Rebase?
Antwort: Commits werden als neue Kopien auf eine andere Basis abgespielt.

Karte 8: Warum --force-with-lease statt --force?
Antwort: Es schützt davor, neue Remote-Arbeit anderer versehentlich zu überschreiben.

Offline-Paket. Öffne diese Datei lokal im Browser; die Diagramme sind im Ordner assets vorhanden und zusätzlich direkt in die HTML-Datei eingebettet.