Kennst du dieses Gefühl, wenn ein Projekt plötzlich in mehrere Versionen zerfasert und niemand mehr sicher weiß, welche Datei die aktuelle ist? Ein Kollege schickt dir “final_v3_neu_endgültig.zip” – und du denkst nur: Bitte nicht. Genau hier helfen Git und GitHub. Sie bringen Ordnung in kreatives Chaos – ob du alleine codelst oder mit einem ganzen Team. In diesem Artikel bekommst du eine einsteigerfreundliche, praktische Einführung mit klaren Schritten, Beispielen und Tipps aus dem Alltag. Keine trockene Theorie, sondern ein Weg, der dich vom ersten Commit bis zum Pull Request führt.
Warum lohnt sich das? Weil Versionen wie Sicherungsnetze sind. Du probierst mutiger aus, weil du jederzeit zurückspringen kannst. Du arbeitest entspannter im Team, weil du Änderungen nachverfolgst, kommentierst und zusammenführst – transparent, überprüfbar, nachvollziehbar. Am Ende weißt du nicht nur, wie die Tools funktionieren, sondern auch, wie du sie sinnvoll in deinen Alltag integrierst. Bereit? Dann lass uns loslegen.
Git und GitHub für Anfänger: Überblick, Setup und Workflow
Git ist das verbreitetste verteilte Versionskontrollsystem; GitHub ist die Plattform, die Git-Repositories in die Cloud bringt, Zusammenarbeit ermöglicht und Workflows visualisiert. In diesem Kapitel bauen wir ein solides Fundament – damit du Git und GitHub im Alltag souverän nutzt. Kurz: Wir legen die Schienen, bevor der Zug Fahrt aufnimmt. Klingt trocken? Keine Sorge, wir bleiben praktisch.
Git vs. GitHub in 60 Sekunden
Stell dir Git als Motor für Versionskontrolle vor und GitHub als Straßennetz, auf dem Teams gemeinsam fahren. Git verwaltet lokal Historie, Branches und Commits. GitHub hostet deine Repos, bietet Pull Requests, Code-Reviews, Issues und Aktionen (CI/CD).
Diese GitHub Einführung lässt sich in einer Faustregel merken: Git = Tool auf deinem Rechner; GitHub = Ort der Zusammenarbeit. Du kannst Git auch ohne GitHub verwenden (z. B. auf einem eigenen Server oder mit anderen Plattformen), aber die Kombination ist im Alltag unschlagbar. Für Git für Anfänger heißt das: Erst verstehen, wie du lokal sauber arbeitest, dann wie du remote teilst. Klingt logisch, oder?
Typischer Git Workflow: Du änderst Dateien, fügst sie dem Staging-Bereich hinzu, erstellst Commits und synchronisierst über Push/Pull mit dem Remote. Auf GitHub lädst du andere ein, arbeitest über Branches und öffnest Pull Requests. Das ist wie Bauklötze stapeln: klein, sicher, rückgängig. Und falls mal ein Klotz fällt, hebst du ihn einfach wieder auf – mit der Historie in der Hand.
Installation & Erstkonfiguration (Name, E‑Mail, SSH/HTTPS)
Installiere Git über dein Paketmanagement oder den Installer. Danach setzt du deinen Namen und deine E‑Mail – sie landen in jedem Commit:
git config --global user.name "Dein Name"
git config --global user.email "dein@mail.com"
Beim Zugriff auf Remotes hast du zwei Wege: HTTPS (oft bequemer mit Credential-Manager) oder SSH (robust, ohne Passwort-Prompts). Ein SSH-Schlüssel wird so angelegt:
ssh-keygen -t ed25519 -C "dein@mail.com"
Den öffentlichen Schlüssel fügst du unter “SSH and GPG keys” in deinem GitHub Account hinzu. Teste die Verbindung:
ssh -T git@github.com
Tipp aus der Praxis: Lege eine globale .gitignore für Editor- und Build-Artefakte an. Aufbewahren, was wichtig ist; ausblenden, was nur stört. Eine saubere Ignore-Liste spart dir später viele Nerven – besonders bei großen Projekten.
Ein Blick in das kostenlose Pro Git Buch oder die kompakten Atlassian Git Tutorials lohnt sich, wenn du tiefer einsteigen möchtest. Kleine Schritte, klare Commits – so wird aus einem Git Tutorial gelebte Praxis.
Repository anlegen und ersten Commit nach GitHub pushen
Bevor wir Code teilen, starten wir lokal. Ziel: Ein neues Projekt initialisieren, sinnvoll strukturieren und den ersten Commit auf GitHub veröffentlichen. Klingt unspektakulär, ist aber der Moment, in dem Git und GitHub Hand in Hand gehen. Genau hier beginnt dein Alltag mit Versionskontrolle.
Neues Git-Repository lokal erstellen
Erstelle einen Ordner, initialisiere Git und füge eine Datei hinzu. Beispiel:
mkdir hallo-projekt && cd hallo-projekt
git init
echo "# Hallo" > README.md
git add README.md
git commit -m "Initialer Commit: README"
Jetzt verknüpfen wir das lokale Repo mit dem Remote. Auf GitHub legst du ein leeres Repository an (ohne Auto-README) und kopierst die SSH- oder HTTPS-URL. Dann:
git remote add origin git@github.com:deinname/hallo-projekt.git
git branch -M main
git push -u origin main
Prüfe, ob die Dateien auf der Projektseite sichtbar sind. Falls nicht, kontrolliere die Remote-URL und ob du die Kommandos im richtigen Ordner ausgeführt hast. Kurzregel: erst lokal sauber committen, dann remote pushen. Versionen sind kein Luxus, sondern Versicherung.
Mini-Story: In einem Bootcamp hat ein Teilnehmer jeden Tag all seine Änderungen per USB-Stick gesichert. Nach dem Umstieg auf Git und GitHub: tägliche Backups mit einem Push, klare Historie und keine “final_final”-Ordner mehr. Zeit gespart, Stress gesenkt.
git commit und push: Befehle mit Beispielen
Die folgenden Befehle brauchst du täglich. Nutze sprechende Commit-Nachrichten: kurz, im Imperativ, mit Kontext.
| Befehl | Zweck | Beispiel |
|---|---|---|
git status | Arbeitsstatus prüfen | Überblick über staged/unstaged Dateien |
git add | Änderungen zum Staging hinzufügen | git add . oder gezielt git add src/app.js |
git commit -m | Snapshot erstellen | git commit -m "Fügt Login-Form hinzu" |
git remote add origin | Remote-Repo verknüpfen | git remote add origin <URL> |
git push -u origin main | Ersten Push mit Upstream | Nächste Pushes: git push |
Ein Bild sagt mehr als viele Worte: So sieht der Ablauf vom lokalen Commit zum Remote-Push aus.
Zwischenfazit: Denk in kleinen, sinnvollen Schritten. Ein Commit pro sinnvollem Gedanken. Stell dir vor, du erklärst den Commit deinem zukünftigen Ich – es wird dir danken.
Branches erstellen, zusammenführen und löschen
Branches sind parallele Zeitlinien für deine Arbeit. Sie helfen dir, Features isoliert zu entwickeln, ohne den stabilen main-Branch zu gefährden. In Teams ist das Gold wert – und genau hier zeigen Git und GitHub ihre Stärke. Warum riskieren, dass alles auf main bricht, wenn du gefahrlos abzweigen kannst?
Feature-Branch anlegen, wechseln und veröffentlichen
Erzeuge einen neuen Branch und wechsle hinein:
git switch -c feature/login
Oder klassisch: git checkout -b feature/login. Arbeite an deinen Dateien, committe in sinnvollen Einheiten:
git add src/login.js
git commit -m "Implementiert Login-Form mit Validierung"
Veröffentliche den Branch auf dem Remote:
git push -u origin feature/login
Mit git switch main wechselst du wieder zur Hauptlinie. Unerwünschte lokale Branches löschst du mit git branch -d feature/login (oder -D für force). Remote: git push origin --delete feature/login.
Ein kleines Teambeispiel: Ein 8-köpfiges Uni-Projekt wechselte von Commits direkt auf main zu Feature-Branches plus Pull Requests. Ergebnis nach vier Wochen: 40% weniger Merge-Konflikte, schnellere Reviews (durchschnittlich 18 statt 29 Stunden) und bessere Commit-Nachrichten. Struktur schafft Fokus – und spart Diskussionen am Freitagabend.
Merge-Strategien (fast-forward, merge commit, rebase) und Aufräumen
Du hast Optionen, wie Änderungen von Branches zusammenfließen. Die passende Strategie hängt von Historie, Teamregeln und CI ab.
| Strategie | Wann geeignet | Vorteil | Nachteil |
|---|---|---|---|
| Fast-forward | Feature ist linear auf dem aktuellen Stand | Saubere Historie ohne Zusätze | Nur möglich, wenn keine Abzweigung |
| Merge-Commit | Standard bei paralleler Arbeit | Kontexte bleiben erkennbar | Zusätzliche Merge-Commits |
| Rebase + FF | Aufräumen vor Integration | Lineare Historie, leicht lesbar | Umordnen der Historie, Vorsicht im Team |
Praxisregel: Nie rebasen, was bereits public gepusht und von anderen genutzt wird – es verwirrt. Vor dem Merge git fetch und git rebase main in deinem Feature-Branch kann trotzdem sinnvoll sein, um Konflikte frühzeitig zu lösen. Danach aufräumen: Branches, die gemerged sind, lokal und remote löschen. Weniger Ballast, mehr Übersicht. Frag dich vor jedem Merge: Was hilft der Lesbarkeit in drei Monaten?
Pull Request auf GitHub erstellen und reviewen
Der Moment der Wahrheit: Du hast ein Feature fertig und möchtest Feedback und einen sauberen Merge. Pull Requests sind das Herzstück des Workflows auf GitHub. Gerade in Teams markieren sie den Wechsel von „Ich“ zu „Wir“ – und machen Qualität messbar. Git und GitHub liefern dafür alles Nötige out of the box.
Pull Request Schritt für Schritt
Im Kern sind PRs leichtgewichtig. So gehst du vor:
- Branch pushen und im Repo auf GitHub auf „Compare & pull request“ klicken.
- Prägnanten Titel vergeben, Beschreibung mit Kontext, Screenshots oder GIFs.
- Reviewer und Labels setzen; ggf. Issue verlinken (Fixes #123).
- Status-Checks prüfen, Feedback einarbeiten, neue Commits pushen.
- Nach Freigabe per Squash, Merge-Commit oder Rebase integrieren.
Kleiner Tipp: Nutze Draft PRs, um früh Feedback zu bekommen, ohne Merge-Druck. Und halte PRs klein. Kleine PRs werden schneller verstanden – und schneller gemerged. Frage dich: Würdest du diesen PR selbst gern reviewen?
Reviews, Status-Checks und Merge-Methoden
Reviews sind kein Torwächterritual, sondern gemeinsame Qualitätssicherung. Nutze Kommentare am Code, Vorschläge (Suggested Changes) und Checklisten. Status-Checks reichen von Linting über Tests bis zu Sicherheitsprüfungen. Definiere Regeln: Wieviele Approvals? Welche Checks müssen bestehen? Branch Protection hilft, Standards durchzusetzen.
Zu den Merge-Methoden: Squash verdichtet alle Commits zu einem – gut für lineare Historien. Merge-Commit bewahrt die Struktur, eignet sich für größere Features. Rebase während des PRs kann die Lesbarkeit erhöhen, sollte aber teamweit abgestimmt sein.
Zur Vertiefung lohnt dieses Video, das den Fluss kompakt erklärt:
Merge-Konflikt in Git lösen: Anleitung und Best Practices
Konflikte gehören dazu. Sie treten auf, wenn Zeilen in denselben Dateien unterschiedlich geändert wurden. Wichtig ist nicht, Konflikte zu vermeiden – wichtig ist, sie ruhig und systematisch zu lösen. Auch hier spielen Git und GitHub gut zusammen: CLI, Editor-Tools und PR-Ansichten helfen dir Schritt für Schritt.
Typische Konfliktszenarien und Tools (CLI, VS Code, GitHub)
Häufige Auslöser: zwei Personen bearbeiten dieselbe Funktion, Umbenennungen ohne Refactoring, parallele Format-Commits. Der Ablauf zur Lösung:
git pull --rebase oder git merge main in deinem Feature-Branch. Git markiert Konflikte in Dateien mit <<<<<<<, =======, >>>>>>>. Öffne sie im Editor (z. B. VS Code) und wähle zwischen “Current”, “Incoming” oder einer manuellen Mischung. Danach:
git add <datei> und git rebase --continue oder git commit beim Merge. Teste lokal, pushe deine Lösung, aktualisiere ggf. den PR.
Auf GitHub kannst du einfache Konflikte direkt im Browser lösen – praktisch für Kleinigkeiten. Bei komplexen Konflikten ist die lokale CLI plus Editor klarer. Denk daran: Konfetti erst nach den Tests.
„Konflikte zeigen, dass gearbeitet wird. Sie sind kein Fehler, sondern ein Normalfall in paralleler Entwicklung.“
Fazit & nächste Schritte
Konfliktkompetenz macht Teams schnell. Pflege kleine Commits, beschreibe Änderungen klar, rebase frühzeitig, teste konsequent. Richte Formatierung (z. B. Prettier), Linting und Tests als Checks ein, damit Probleme früh auffallen. Ein kurzer Blick in Logs und Diffs spart später Stunden. Wenn du Lust auf mehr hast: Arbeitsabläufe automatisieren, Release-Branches einführen und mit CI/CD-Pipelines den Weg von Commit zu Deployment glätten. So werden aus Grundlagen solide Routinen – und aus Stressplänen verlässliche Abläufe.
FAQ zu Git und GitHub
Zum Abschluss Antworten auf Fragen, die fast jedes Team früh stellt. So festigst du das Gelernte und kannst Git und GitHub entspannt im Alltag einsetzen.
Wie richte ich SSH mit GitHub ein?
Erzeuge einen Schlüssel: ssh-keygen -t ed25519 -C "dein@mail.com". Kopiere den Inhalt von ~/.ssh/id_ed25519.pub in deinen GitHub-Account unter “SSH and GPG keys”. Teste mit ssh -T git@github.com. Falls nötig, trage in ~/.ssh/config Host-Alias und Key-Pfad ein. Vorteil: Kein Passwortprompt bei Push/Pull, stabil in CI-Umgebungen.
Was ist der Unterschied zwischen Fork und Branch?
Ein Branch ist eine Abzweigung innerhalb desselben Repositories – ideal für Features. Ein Fork ist eine Kopie des gesamten Repos in deinem Account, unabhängig vom Original. Forks nutzt du bei Open Source oder wenn du keine Schreibrechte hast. Branches sind für die meisten Team-Workflows erste Wahl, Forks für externe Beiträge.
Wie mache ich einen Commit rückgängig (reset/revert)?
git revert <commit> erstellt einen neuen Commit, der die Änderungen rückgängig macht – sicher für bereits gepushte Historie. git reset --hard <commit> setzt den Stand lokal zurück (vorsichtig!), geeignet für Aufräumen vor dem Push. Für einzelne Dateien: git checkout -- <datei> oder git restore <datei>. Grundsatz: Revert für geteilte Historie, Reset für lokale Korrekturen.
Wie nutze ich .gitignore korrekt?
Ignoriere generierte Artefakte (Builds, Caches), persönliche Einstellungen und geheime Dateien. Lege projektweit .gitignore an und nutze optional eine globale für Editor-Tempfiles. Template gefällig? Die offiziellen Beispiel-Listen in vielen Sprachen/Stacks findest du über das Pro Git Umfeld oder Editor-Plugins. Wichtig: Bereits getrackte Dateien erst über git rm --cached entfernen.
Wie schütze ich den main-Branch (Branch Protection)?
Aktiviere in den Repo-Einstellungen Branch Protection Rules: erforderliche Reviews (z. B. 1–2), Pflicht-Status-Checks (Tests, Lint), keine Direkt-Pushes, ggf. Sign-Offs. Das schafft Standards, ohne Tempo zu nehmen. Für Release-Branches lassen sich ähnliche Regeln setzen – Sicherheit dort, wo Stabilität zählt.
Welche Git-GUIs sind für Einsteiger empfehlenswert?
VS Code bietet integrierte Git-Unterstützung mit guter Konfliktauflösung. Alternativen sind GitHub Desktop für einfache Workflows oder Sourcetree für Visualisierung. Egal welche GUI: Verstehe die Git Befehle dahinter. Wer die Konzepte kennt, wechselt mühelos zwischen Tools.
Hey, ich bin Karwl und das ist mein Blog. Ich liebe alles zu den Themen 🌱 Garten & Pflanzen, 🤖 KI & Tech, 🌐 Web & Coding und würde mich freuen, wenn du hier öfters mal vorbei schaust.