Mini-Projekt: Git lokal (Terminal + VS Code)
Dauer: 30-45 Minuten (optional bis 60)
Ziel: Lokalen Git-Workflow verstehen und anwenden
- Git nur lokal (keine Remotes, keine Branches)
- Erstes Durchlaufen mit Terminal-Befehlen
- Zweites Durchlaufen mit der Git-Ansicht in VS Code
In dieser Übung arbeiten wir an einem kleinen CLI-Programm.
Die Dateiänderungen sind bewusst einfach, damit der Fokus auf Git liegt.
Wir arbeiten nur lokal: kein GitHub, kein git push, keine Branches.
Setup (einmalig)
- Neuen Ordner erstellen und in VS Code öffnen.
- Im VS-Code-Terminal:
npm init -y- In
package.jsondie Zeile mit"type": …ändern zu"type": "module". - Abhängigkeit installieren:
npm install readline-sync- Git initialisieren und
.gitignoreerstellen:
git init.gitignore ist eine normale Textdatei, die du in VS Code erstellst und bearbeitest:
node_modules/
.envWarum?
node_modules/ enthält installierte Abhängigkeiten und wird nicht versioniert.
.env enthält oft sensible Daten (API-Keys, Passwörter) und gehört nie ins Repo.
- Status prüfen:
git status- Setup committen:
git add -A
git commit -m "Projekt-Setup"Dabei sollten package.json, package-lock.json und .gitignore im Commit enthalten sein.
Hinweis: git add -A nimmt alle Änderungen auf, inklusive Löschungen.
git add . bezieht sich auf den aktuellen Ordner und kann Änderungen außerhalb
dieses Ordners übersehen.
Checkpoint: Das Projekt ist lokal git-initialisiert.
Falls Git nach Name/E-Mail fragt:
git config user.name "Dein Name"
git config user.email "deine@email.de"Diese Angaben erscheinen in jedem Commit. Möglichkeiten:
- Name: Klarname, Nickname oder fiktiv
- E-Mail: fiktive Mail, DHBW-Mailadresse oder GitHub
noreply-Adresse (unter Settings → Emails)
Für rein lokales Arbeiten reicht auch eine fiktive Adresse (z.B. name@localhost).
Vor dem Veröffentlichen auf GitHub sollte sie angepasst werden. Die Angaben lassen sich
jederzeit mit denselben Befehlen ändern.
Drei Zustände in Git:
Working Tree = Änderungen, die noch nicht vorgemerkt sind
Staged = Änderungen für den nächsten Commit vorgemerkt
Commit = gespeicherter Snapshot im lokalen Verlauf
Warum gibt es Staging?
Du kannst gezielt auswählen, was in einen Commit kommt.
Das macht Commits klein, sauber und nachvollziehbar.
Durchlauf A: Terminal-Git
Schritt A1: Erste Datei
Lege app.js an:
import { question } from 'readline-sync';
const name = question('Dein Name: ');
console.log(`Hallo, ${name}!`);Git im Terminal:
git status
git diff
git add app.js
git commit -m "CLI Begrüßer"Kurz erklärt:
git statuszeigt, was neu/geändert ist und was staged ist.git diffzeigt die Änderungen, die noch nicht staged sind.git diff --stagedzeigt, was im nächsten Commit landen würde.git addverschiebt Änderungen in den Staging-Bereich.git commitspeichert einen Snapshot im lokalen Verlauf.
Wann committen?
- nach einer kleinen, abgeschlossenen Änderung
- wenn das Programm wieder lauffähig ist
- nach einem sinnvollen Zwischenziel
Schritt A2: Logik auslagern
Lege greetings.js an und passe app.js an.
greetings.js:
const greetings = ['Hallo', 'Hi', 'Moin', 'Servus'];
export function pickGreeting() {
const index = Math.floor(Math.random() * greetings.length);
return greetings[index];
}app.js:
import { question } from 'readline-sync';
import { pickGreeting } from './greetings.js';
const name = question('Dein Name: ');
console.log(`${pickGreeting()}, ${name}!`);Git im Terminal:
git diff
git add -A
git commit -m "Greetings ausgelagert"Tipp: git add -A nimmt alle Änderungen (neue, geänderte, gelöschte Dateien) in die Stage auf.
Schritt A3: README anlegen
Lege README.md an:
# CLI Begrüßer
Start:
node app.jsGit im Terminal:
git status
git add README.md
git commit -m "README hinzugefügt"
git log --onelineKurz erklärt:
git log --onelinezeigt die Commit-Historie kompakt.- Nutze
git diff --staged, wenn du sehen willst, was genau im nächsten Commit landet.
Durchlauf B: Git in VS Code
Ab jetzt: Änderungen stagen und committen nur über die Git-Ansicht
(Source Control) in VS Code. Im Terminal darfst du weiterhin git status
oder git log ausführen.
Schritt B1: Utility-Datei
Lege utils.js an und passe app.js an.
utils.js:
export function normalizeName(name) {
return name.trim();
}app.js:
import { question } from 'readline-sync';
import { pickGreeting } from './greetings.js';
import { normalizeName } from './utils.js';
const name = normalizeName(question('Dein Name: '));
console.log(`${pickGreeting()}, ${name}!`);Jetzt in VS Code:
Source Controlöffnen- Diff ansehen
- Dateien stagen
- Commit erstellen (z. B. “Utilities hinzugefügt”)
Schritt B2: Kleine Änderung
Erweitere app.js um eine kleine Zusatz-Ausgabe:
console.log(`Buchstaben: ${name.length}`);Commit wieder nur in der VS-Code-Git-Ansicht.
Optional: Unstage/Discard üben
- Ändere
app.jsabsichtlich (z. B. Tippfehler). - Stage die Datei.
- Unstage (eine Variante wählen):
In VS Code: Datei in Source Control → Rechtsklick → Unstage Changes.
Im Terminal:
git reset app.jsKurz erklärt: git reset <datei> entfernt die Datei aus der Stage, lässt die Änderung aber im Working Tree.
Nur diese Form verwenden (kein --hard).
- Änderung verwerfen (eine Variante wählen):
In VS Code: Datei in Source Control → Rechtsklick → Discard Changes.
git restore app.jsKurz erklärt: git restore verwirft lokale Änderungen und stellt den letzten Commit wieder her.
- Ergebnis mit
git statusprüfen.
Ziel erreicht, wenn:
- du mehrmals staged/committed hast (Terminal + VS Code)
- du
git status,git diff,git logundgit resetpraktisch genutzt hast - du verstehst, was in den drei Zuständen passiert (working tree, staged, commit)