GitHub in VS Code

Dein erster Push — ohne Terminal-Angst

Nur das eingebaute Source-Control-Panel. Keine Extension nötig. 🦀

Was du brauchst

  • VS Code — hast du
  • Ein GitHub-Konto — kostenlos auf github.com
  • Git — das richten wir jetzt Schritt für Schritt ein ↓

VS Code bringt die GitHub-Anbindung schon mit — es fehlt nur Git.

Git auf Windows installieren

git-scm.com → Download for Windows → .exe starten. Meiste Defaults passen — diese drei prüfen:

  • Default editor → VS Code (statt Vim)
  • PATH → „Git from the command line…" (mittlere, empfohlene Option)
  • Line endings → „Checkout Windows-style…" (Default)

Rest: Weiter → Install. Alles andere auf Standard lassen.

Läuft's? Kurz prüfen

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 einmalig einrichten

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.

Ein Repo starten — git init

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.

Oder: ein Klick in VS Code

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.

Wo alles passiert

Links in der Leiste das Verzweigungs-Symbol — oder Strg+Shift+G.

SOURCE CONTROL Deine Änderungen erscheinen hier ↑

Kleiner Zähler am Symbol = so viele Dateien haben sich geändert.

Projekt hochladen — 1 Klick

Ordner offen, noch kein Repo? Dann steht da Publish to GitHub:

SOURCE CONTROL Repository initialisieren Publish to GitHub ← der blaue macht die Arbeit

VS Code fragt Login + privat/öffentlich — Repo ist online.

Bestehendes Repo? Clone Repository → GitHub-Link.

Der ganze Alltag = 4 Schritte

✏️ Ändern→ Stage (add)→ Commit→ Sync (push/pull)

Mehr ist es nicht. Der Rest sind Details.

Stage — was kommt mit?

Geänderte Dateien stehen unter Changes. Das + nimmt sie mit.

SOURCE CONTROL Nachricht (Strg+Enter zum Commit) CHANGES 2 app.js M + README.md U + M = geändert · U = neu (untracked)

Alles auf einmal

Das + neben der Überschrift Changes staged alles zusammen.

Staged heißt: „das nehme ich in den nächsten Commit". Noch nichts gespeichert.

Commit — Schnappschuss + Notiz

Login-Formular gebaut ✓ Commit Kurz & im Präsens: „macht X" — nicht „hab X gemacht".

Nachricht rein → Commit (oder Strg+Enter). Lokal gespeichert. ✅

Ein Commit ist ein Speicherpunkt, zu dem du immer zurück kannst.

Sync — hoch & runter

WasWann
Pushdeine Commits hoch zu GitHubnach dem Commit
PullNeues von GitHub runterbevor du startest

Sync macht beides in einem: erst Pull, dann Push.

Der Sync-Knopf

Unten links in der Statusleiste — Branch + die zwei Pfeile:

main 1 ↑ 0 ↓ ← klicken = Sync (Pull + Push)

„1 ↑" heißt: ein Commit wartet auf den Weg nach oben.

Warum Pull und Push?

GitHub ist die gemeinsame Mitte — jeder hat eine eigene lokale Kopie:

Dein PC lokale Kopie GitHub die Mitte Kollegin lokale Kopie push → ← pull pull → ← push

Push = deine Commits hoch · Pull = die der anderen runter.

Zu zweit am Projekt

Der typische Ablauf — ein Hin und Her über GitHub:

  1. Kollege ändert → Commit → Push (liegt jetzt auf GitHub)
  2. Du Pullst → hast seinen Stand
  3. Du arbeitest → Commit → Push
  4. Er Pullt → hat deinen Stand

Goldene Regel: immer erst Pull, dann Push. Sonst weist Git dich ab — dein Stand ist veraltet.

Merge — Zusammenführen

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.

Merge-Konflikt

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.

Branches — parallele Linien

Ein Branch ist eine eigene Arbeitslinie. main = der stabile Hauptzweig:

main feature abzweigen → arbeiten → zurück in main mergen

So baust du ein Feature, ohne main anzufassen — main bleibt immer lauffähig.

Branch-Ablauf

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.

Im Team: der Pull Request

Statt direkt in main zu mergen, pushst du deinen Branch und öffnest auf GitHub einen Pull Request:

  1. Branch pushen → „Compare & pull request"
  2. Team reviewt + kommentiert
  3. Merge in main → alle pullen den neuen Stand

PR = „bitte anschauen und einbauen". So arbeiten Teams sauber zusammen.

Dein Rhythmus

  1. Sync — hol dir den neuesten Stand
  2. arbeiten, speichern
  3. Stage → Commit mit klarer Nachricht
  4. Sync — dein Stand liegt auf GitHub

Klein & oft committen schlägt einmal alles.

Kurz im Kopf behalten

  • Strg+Shift+G → Source Control
  • + = Stage · Commit = speichern · Sync = tauschen
  • M geändert · U neu · immer erst Pull

Verhakt? Rechtsklick auf eine Datei zeigt „Discard" — Änderungen zurücknehmen.

Das war GitHub in VS Code

Ä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. 🦀