Einführung in Git

Warum speichern Teams ihre Arbeit nicht einfach in Ordnern mit Datum im Namen? Dieses Modul zeigt den Unterschied zwischen zentraler (SVN) und dezentraler Versionskontrolle (Git) und erklärt, warum sich Git als Standard durchgesetzt hat. Am Ende wissen Sie, welche Probleme Git löst und wie ein verteiltes Repository aufgebaut ist.

Sie installieren Git auf Ihrem System (Windows, macOS oder Linux) und richten Ihre Identität mit git config ein: Name, E-Mail und bevorzugter Editor. Danach konfigurieren Sie die Authentifizierung per HTTPS mit Credential Manager oder per SSH-Key und testen die Verbindung zu GitHub. Jeder Teilnehmer hat am Ende eine funktionierende Git-Installation.

Sie erstellen Ihr erstes Repository mit git init, legen Dateien an und durchlaufen den kompletten Zyklus: Working Directory, Staging Area und Repository. Mit git add und git commit speichern Sie Ihre ersten Snapshots. Dieses Drei-Stufen-Modell ist das Fundament für alles Weitere, deshalb arbeiten Sie es Schritt für Schritt in der eigenen Cloud-Umgebung durch.

Welche Dateien haben sich geändert, was genau wurde geändert und wer hat es wann gemacht? Mit git status, git diff und git log beantworten Sie diese Fragen in Sekunden. Außerdem legen Sie eine .gitignore-Datei an, damit Build-Artefakte, IDE-Konfigurationen und Credentials gar nicht erst ins Repository gelangen.

Nicht jede Git-Aktion muss im Terminal passieren. Sie führen dieselben Operationen (Commit, Diff, Log) in VS Code mit der GitLens-Extension durch und sehen, wo die GUI Vorteile bietet: Blame-Annotationen pro Zeile, visuelle Diff-Ansichten und interaktive Commit-Historie. Profis nutzen beides, je nach Aufgabe.

Branches sind der Grund, warum Teams parallel an Features arbeiten können, ohne sich gegenseitig zu blockieren. Sie erstellen Branches mit git branch, wechseln mit git switch (dem modernen Ersatz für git checkout) und räumen mit git branch -d auf. Dabei sehen Sie, dass ein Branch in Git nur ein leichtgewichtiger Zeiger auf einen Commit ist, kein Kopiervorgang.

Was passiert, wenn zwei Personen dieselbe Zeile ändern? Sie führen Fast-Forward- und 3-Way-Merges durch, provozieren absichtlich Konflikte und lösen sie sowohl im Terminal als auch in VS Code. Nach diesem Block ist ein Merge-Konflikt für Sie eine Routineaufgabe.

Lokale Commits sind nur die halbe Wahrheit. Sie klonen ein bestehendes Repository mit git clone, holen Änderungen mit git fetch, integrieren sie mit git pull und veröffentlichen eigene Arbeit mit git push. Dabei klären wir den Unterschied zwischen fetch und pull, den viele Einsteiger verwechseln.

GitHub ist mehr als ein Remote-Speicher für Repositories. Sie erstellen Issues zur Aufgabenplanung, öffnen Ihren ersten Pull Request, fügen Reviewer hinzu und geben strukturiertes Code-Feedback. Dieser Workflow ist der Standard in den meisten Entwicklungsteams weltweit, egal ob mit GitHub, GitLab oder Gitea.

Drei Werkzeuge, die Ihren Alltag erleichtern: Mit git rebase linearisieren Sie Ihre Commit-Historie, statt sie durch Merge-Commits aufzublähen. Mit git stash parken Sie halbfertige Arbeit, um kurz den Branch zu wechseln. Und mit git tag markieren Sie Release-Stände wie v1.0.0, die später leicht auffindbar bleiben.

Welcher Workflow passt zu welchem Team? Sie vergleichen drei etablierte Modelle: GitFlow (formale Releases, gut für versionierte Software), GitHub Flow (einfach, ein Hauptbranch plus Feature-Branches) und Trunk-Based Development (kurze Branches, schnelle Integration). Statt ein Modell als "richtig" zu verkaufen, erarbeiten Sie Kriterien, wann welcher Ansatz passt.

Nicht jedes Team will seinen Code bei einem US-Anbieter hosten. Gitea ist eine leichtgewichtige, quelloffene Git-Plattform, die Sie auf eigener Infrastruktur betreiben. Sie richten eine Gitea-Instanz ein, erstellen ein Repository, pushen Code und vergleichen die Oberfläche direkt mit GitHub. So können Sie später bewusst entscheiden, welche Plattform für Ihr Team passt.

Der Schritt vom eigenen Projekt zur Mitarbeit an fremdem Code folgt einem klaren Muster: Fork erstellen, lokalen Clone anlegen, upstream Remote hinzufügen und synchron halten. Sie durchlaufen den kompletten Zyklus an einem echten Open-Source-Repository: Branch erstellen, Änderung umsetzen, Pull Request öffnen und die ungeschriebenen Regeln guter PR-Beschreibungen kennenlernen.

Alles zusammen in einem realistischen Szenario: Ihr Team arbeitet an einem gemeinsamen Repository, erstellt Feature-Branches, öffnet Pull Requests, reviewt gegenseitig Code und löst dabei auftretende Merge-Konflikte. Diese Übung simuliert einen typischen Arbeitstag mit Git und festigt alle Konzepte der letzten drei Tage.

Zum Abschluss ein Blick über den Tellerrand: git cherry-pick überträgt einzelne Commits zwischen Branches, git bisect findet per binärer Suche den Commit, der einen Bug eingeführt hat. Außerdem ordnen wir ein, was Git 3.0 (SHA-256, Reftable) für bestehende Repositories bedeutet, und werfen einen kurzen Blick auf neue Tools wie jj und GitButler.