Dein erster Push — ohne Terminal-Angst
Nur das eingebaute Source-Control-Panel. Keine Extension nötig. 🦀
github.comVS Code bringt die GitHub-Anbindung schon mit — es fehlt nur Git.
git-scm.com → Download for Windows → .exe starten. Meiste Defaults passen — diese drei prüfen:
Rest: Weiter → Install. Alles andere auf Standard lassen.
Neue PowerShell oder Eingabeaufforderung öffnen und tippen:
git --version
Kommt git version 2.4x.x zurück → installiert. ✅
Wichtig: das Terminal nach der Installation neu öffnen, sonst kennt es git noch nicht.
Git schreibt Name + E-Mail in jeden Commit — einmal global setzen, sonst meckert Git beim ersten Commit:
git config --global user.name "Maik Kasper"
git config --global user.email "du@example.com"
Am besten die E-Mail, die du auch bei GitHub nutzt.
git config --global init.defaultBranch main
…legt main als Startzweig fest (GitHub-Standard). Prüfen: git config --global --list.
Im Projektordner macht git init aus einem normalen Ordner ein Git-Repository:
cd C:\Pfad\zu\deinem\projekt
git init
Git legt einen versteckten .git-Ordner an — darin lebt die ganze Historie.
Denselben Schritt macht der Button Repository initialisieren im Source-Control-Panel — git init unter der Haube.
CLI verstehen, GUI nutzen: gleiches Ergebnis. Ab hier geht's mit VS Code weiter.
Links in der Leiste das Verzweigungs-Symbol — oder Strg+Shift+G.
Kleiner Zähler am Symbol = so viele Dateien haben sich geändert.
Ordner offen, noch kein Repo? Dann steht da Publish to GitHub:
VS Code fragt Login + privat/öffentlich — Repo ist online.
Bestehendes Repo? Clone Repository → GitHub-Link.
Mehr ist es nicht. Der Rest sind Details.
Geänderte Dateien stehen unter Changes. Das + nimmt sie mit.
Das + neben der Überschrift Changes staged alles zusammen.
Staged heißt: „das nehme ich in den nächsten Commit". Noch nichts gespeichert.
Nachricht rein → Commit (oder Strg+Enter). Lokal gespeichert. ✅
Ein Commit ist ein Speicherpunkt, zu dem du immer zurück kannst.
| Was | Wann | |
|---|---|---|
| Push | deine Commits hoch zu GitHub | nach dem Commit |
| Pull | Neues von GitHub runter | bevor du startest |
Sync macht beides in einem: erst Pull, dann Push.
Unten links in der Statusleiste — Branch + die zwei Pfeile:
„1 ↑" heißt: ein Commit wartet auf den Weg nach oben.
GitHub ist die gemeinsame Mitte — jeder hat eine eigene lokale Kopie:
Push = deine Commits hoch · Pull = die der anderen runter.
Der typische Ablauf — ein Hin und Her über GitHub:
Goldene Regel: immer erst Pull, dann Push. Sonst weist Git dich ab — dein Stand ist veraltet.
Beim Pull mergt Git die Commits der anderen mit deinen. Meist automatisch — ihr habt ja verschiedene Dateien/Zeilen angefasst.
Solange ihr euch nicht in die Quere kommt, merkt ihr vom Merge fast nichts.
Habt ihr dieselbe Zeile geändert, kann Git nicht entscheiden → Konflikt:
<<<<<<< deine Version
const port = 3000
=======
const port = 8080
>>>>>>> von GitHub
VS Code zeigt beide + Buttons Accept Current / Incoming / Both. Du wählst, committest — fertig.
Ein Branch ist eine eigene Arbeitslinie. main = der stabile Hauptzweig:
So baust du ein Feature, ohne main anzufassen — main bleibt immer lauffähig.
git switch -c feature-login # neuer Branch, direkt drauf
# … arbeiten, committen …
git switch main # zurück auf main
git merge feature-login # Feature einbauen
In VS Code: unten links der Branch-Name → anklicken zum Wechseln/Erstellen.
Statt direkt in main zu mergen, pushst du deinen Branch und öffnest auf GitHub einen Pull Request:
main → alle pullen den neuen StandPR = „bitte anschauen und einbauen". So arbeiten Teams sauber zusammen.
Klein & oft committen schlägt einmal alles.
Strg+Shift+G → Source Control+ = Stage · Commit = speichern · Sync = tauschenVerhakt? Rechtsklick auf eine Datei zeigt „Discard" — Änderungen zurücknehmen.
Ändern → Stage → Commit → Sync.
Kein Terminal, keine Magie — nur ein Panel und vier Handgriffe.
Ab hier gilt: einfach machen. Der erste Push ist der schwerste. 🦀