Git & GitHub: die ersten Schritte

1. Git einrichten

Nach der Installation von Git hinterlegst du einmalig Name und E-Mail — sie erscheinen später in jedem Commit.

git config --global user.name "Dein Name"
git config --global user.email "[email protected]"

2. Ein Repository anlegen

mkdir mein-projekt && cd mein-projekt
git init

3. Änderungen committen

Ein Commit ist ein gespeicherter Stand. Mit „add“ wählst du aus, was gespeichert wird, mit „commit“ hältst du es mit einer Nachricht fest.

git add .
git commit -m "Erster Commit"
git status   # zeigt jederzeit den aktuellen Stand

4. Zu GitHub pushen

1. 1.Auf GitHub ein leeres Repository erstellen (ohne README).
2. 2.Die angezeigte Remote-URL kopieren.
3. 3.Lokales Projekt mit dem Remote verbinden und hochladen.

git remote add origin https://github.com/DEIN-NAME/mein-projekt.git
git branch -M main
git push -u origin main

5. Was NICHT ins Repository gehört

Nicht jede Datei soll in die Versionskontrolle. Abhängigkeiten wie der Ordner node_modules lassen sich jederzeit neu installieren und blähen das Repository nur auf. Zugangsdaten in einer .env-Datei haben online erst recht nichts zu suchen. Eine Datei namens .gitignore listet solche Ausnahmen auf — Git ignoriert dann alles, was darin steht. Diese Datei legt man am besten gleich zu Beginn an, denn einmal hochgeladene Secrets bleiben in der Historie.

node_modules/
.env
.DS_Store
dist/

6. Der tägliche Ablauf im Team

In der Zusammenarbeit wiederholt sich ein fester Rhythmus. Bevor man loslegt, holt man mit „git pull“ den aktuellen Stand der anderen. Für eine neue Aufgabe legt man einen eigenen Branch an, arbeitet dort in kleinen Commits und lädt ihn mit „git push“ hoch. Auf GitHub eröffnet man dann einen Pull Request: Die Kollegen sehen die Änderungen, kommentieren sie und geben sie frei, bevor sie in den Hauptzweig übernommen werden. Dieser Ablauf hält den Hauptcode stabil und macht jede Änderung nachvollziehbar.

7. Die Historie durchsuchen

Der eigentliche Wert der Versionsgeschichte zeigt sich beim Nachschlagen. „git log“ listet die Commits auf; in der kompakten Form mit Graph erkennt man auf einen Blick, wie Branches entstanden und wieder zusammengeführt wurden. „git show“ zeigt zu einem einzelnen Commit alle Änderungen im Detail, „git diff“ vergleicht zwei Stände miteinander. Besonders nützlich ist „git blame“: Es schreibt neben jede Zeile einer Datei, aus welchem Commit sie stammt. Damit findet man in Sekunden heraus, wann eine merkwürdige Zeile hinzukam — und liest in der zugehörigen Commit-Nachricht nach, warum.

git log --oneline --graph   # kompakte Übersicht mit Verzweigungen
git show <commit>           # Details zu einem Commit
git diff main..mein-branch  # Unterschiede zwischen zwei Ständen
git blame datei.ts          # Herkunft jeder einzelnen Zeile

8. Fehler wieder ausbügeln

Es gibt für jede Art von Missgeschick den passenden Handgriff. Eine Datei, die man versehentlich verändert hat, holt „git restore“ zurück auf den letzten Commit-Stand. Ist ein Commit noch nicht hochgeladen, lässt er sich mit „git commit --amend“ nachbessern — praktisch, wenn nur die Nachricht einen Tippfehler enthält. Ist er dagegen schon beim Remote, gilt eine eiserne Regel: Historie, die andere bereits geholt haben, wird nicht umgeschrieben. Stattdessen erzeugt „git revert“ einen neuen Commit, der die Änderung rückgängig macht. Der Fehler bleibt sichtbar, die Korrektur ebenso — und niemandem bricht der Stand weg.