Von Nova Trent, Junior Entwicklerin bei Java Fleet Systems Consulting
OMG! Das ist meine ERSTE Blog-Serie! 🎊
Leute, ich kann’s noch gar nicht glauben! Franz-Martin hat gesagt: „Nova, du machst jetzt eine Serie über Git. 4 Wochen, jeden Montag!“ Git für Anfänger
Meine Reaktion? „WAS?! ICH?! Eine GANZE Serie?!“ 😱
Aber dann hab ich gedacht: Wer könnte Git besser für Anfänger erklären als jemand, der JEDEN FEHLER selbst gemacht hat? Also here we go – Nova’s erste richtige Blog-Serie!
Und rate mal was? Die Geschichte wie Git überhaupt entstanden ist, ist WILD! (Dazu gleich mehr… 🍿)
Das Wichtigste in 30 Sekunden 🕐
Letzte Woche Montag, 9:15 Uhr: Ich wollte nur eine kleine Änderung committen. Jetzt zeigt Git mir rote Fehlermeldungen und ich hab keine Ahnung wo mein Code ist. PANIC MODE! 😱
Nach einer Stunde mit Code Sentinel und sehr vielen git status Kommandos hab ich’s überlebt. Und jetzt? Jetzt mache ich daraus eine 4-Wochen-Serie! Weil wenn ich Git lernen kann, dann jeder!
Was dich erwartet:
- 🎯 4 Wochen Git-Grundlagen – von Null bis Team-Ready
- 💥 Alle meine Fehler (ja, wirklich ALLE!)
- 🔧 Praktische Lösungen ohne Fachchinesisch
- 🎓 Von „Was ist Git?“ bis zu professionellen Workflows
- 🤝 Community-Challenges jede Woche!
Hi Leute! 👋 Nova hier – ready für meine ERSTE Serie!
Falls du meinen ersten Learning Monday gelesen hast, kennst du schon mein Branch-Lösch-Panikmoment. Damals hab ich lokal einen Branch mit git branch -D gelöscht und dachte, ich hätte die Arbeit von allen zerstört. 😨
Spoiler: Hatte ich nicht. Aber die Panik war real.
Das Problem? In der Uni haben wir Git nur oberflächlich gelernt. „Hier ist git add, git commit, git push – fertig!“ Aber was passiert eigentlich dabei? Warum gibt’s manchmal rote Fehlermeldungen? Und warum zum Henker lande ich manchmal in Vim und weiß nicht wie ich wieder rauskomme?!
Zeit, das zu ändern. Systematisch. Ohne Panik.
Was ist Git eigentlich? (Und warum hab ich Angst davor?)
Git ist ein Versionskontrollsystem. Das weiß ich. Aber was bedeutet das wirklich?
Code Sentinel’s Erklärung (die ich endlich verstehe):
„Nova, stell dir vor, du schreibst ein Buch. Jedes Mal wenn du einen Abschnitt fertig hast, machst du ein Foto (einen Commit) von der aktuellen Seite. Später kannst du zu jedem Foto zurückgehen und sehen wie das Buch damals aussah. Git macht das mit deinem Code.“
Aha-Moment: Git ist wie eine Zeitmaschine für Code! 🚀
Der wichtigste Satz den ich je gelernt hab:
„Gestern lief es noch!“ – Diese Ausrede gibt es mit Git nicht mehr!
Elyndra hat mir das so erklärt:
„Nova, wenn du sagst ‚gestern lief es noch‘, dann hol dir einfach ‚gestern‘ zurück! Mit
git logsiehst du alle Versionen, mitgit checkoutgehst du zu jeder beliebigen zurück. Keine Ausreden mehr!“
Mind = Blown! 🤯 Das bedeutet:
- Jeden Abend committe ich → Morgens kann ich immer zu „gestern“ zurück
- Vor jedem Experiment committe ich → Geht’s schief, zurück zum letzten Stand
- Kein Code geht verloren, solange ich committed hab!
Die drei wichtigsten Git-Bereiche:
- Working Directory – Dein normaler Projektordner, wo du Code schreibst
- Staging Area (auch „Index“ genannt) – Die „Wartezone“ für Änderungen, die du committen willst
- Repository – Die Datenbank mit der kompletten Historie
Aber wo sind die eigentlich? (Das hat mich auch verwirrt!)
- Working Directory → Dein normaler Projektordner (den du siehst!)
- Staging Area → Versteckt in
.git/index(eine Binärdatei) - Repository → Versteckt in
.git/objects/(die komplette Historie)
Code Sentinel’s Tipp: „Nova, du musst nicht wissen WO genau das liegt. Wichtig ist zu verstehen WAS passiert!“
Visuell sieht das so aus:
Working Directory → Staging Area → Repository
(Dateien) → (git add) → (git commit)
↓ ↓ ↓
main.java main.java Commit #abc123
[geändert] [bereit] [gespeichert]
↓ ↓ ↓
Du siehst es! .git/index (unsichtbar) .git/objects/ (unsichtbar)
Warum ist das wichtig? Wenn du git status ausführst, zeigt es dir:
- Was im Working Directory geändert wurde (rot = noch nicht staged)
- Was in der Staging Area bereit ist (grün = wird beim nächsten commit gespeichert)
- Die Repository-Historie siehst du mit
git log
Mein erstes „richtiges“ Repository – Live-Coding mit Fehlern! 💻
Heute morgen hab ich beschlossen: Ich erstelle ein neues Projekt richtig und verstehe jeden Schritt.
⚠️ Wichtig: Wir lernen Git an der Kommandozeile!
Elyndra hat mir erklärt:
„Nova, IntelliJ und VS Code haben super Git-Integration mit hübschen Buttons. ABER: Lern erst die Kommandozeile! Wenn du verstehst was
git addmacht, verstehst du auch was der ‚Stage Changes‘ Button in deiner IDE tut.“
Warum CLI (Command Line Interface)?
- ✅ Funktioniert in jeder Umgebung (Server, CI/CD, anderer Rechner)
- ✅ Du verstehst was wirklich passiert
- ✅ IDEs machen dasselbe – nur versteckt hinter Buttons
- ✅ Wenn was schiefgeht, musst du die CLI kennen
Was machen IDEs anders?
VS Code/IntelliJ GUI → Echtes Git-Kommando "Stage Changes" Button → git add <datei> "Commit" Dialog → git commit -m "message" "Push" Button → git push Grafischer Diff-Viewer → git diff
Nova’s Learning: Die IDE benutzt intern genau dieselben Git-Kommandos! Sie macht es nur „hübscher“. Aber wenn ich die CLI verstehe, verstehe ich auch die IDE!
In dieser Serie: Wir machen alles im Terminal/Kommandozeile – so lernen wir Git richtig! 🖥️
Schritt 1: Repository initialisieren
# In meinem Projektordner git init
Was passiert hier?
- Git erstellt einen versteckten
.gitOrdner - Dieser Ordner ist die „Datenbank“ für die komplette Historie
- Wichtig: Ohne
git initist dein Ordner kein Git-Repository!
Schritt 2: Erste Dateien hinzufügen (mein erster Fehler)
# Ich erstelle eine Java-Datei
echo "public class Main { }" > Main.java
# Und versuche zu committen
git commit -m "Initial commit"
💥 FEHLER:
On branch main No commits yet nothing to commit (create/copy files and git add to commit)
Was hab ich falsch gemacht? Ich hab vergessen, die Datei zur Staging Area hinzuzufügen!
Schritt 2 (nochmal, richtig):
# ERST zur Staging Area hinzufügen git add Main.java # Status prüfen (mein neuer bester Freund!) git status # DANN committen git commit -m "Initial commit: Add Main.java"
✅ Erfolg! Mein erster richtiger Commit!
Schritt 3: Remote-Repository verbinden
# Remote hinzufügen (GitHub/GitLab/BitBucket) git remote add origin https://github.com/nova-chen/my-first-repo.git # Pushen git push -u origin main
💥 NÄCHSTER FEHLER:
error: src refspec main does not match any
Elyndra’s Erklärung: „Nova, du hast den Branch noch nicht erstellt. Bei modernen Git-Versionen heißt der Hauptbranch main, bei älteren master. Prüf mal welchen du hast!“
# Branch-Namen prüfen git branch # Falls noch kein Branch existiert oder er 'master' heißt: git branch -M main # Jetzt pushen git push -u origin main
✅ Endlich! Mein Code ist auf GitHub!
Die wichtigsten Git-Kommandos – Mein Survival-Guide 🆘
Nach einer Woche täglicher Git-Panik hab ich diese Liste erstellt:
Status-Kommandos (Lebensretter!)
# "Was ist hier los?!" git status # "Was hab ich geändert?" git diff # "Welche Commits gibt es?" git log # "Zeig mir das kurz und übersichtlich" git log --oneline --graph --all
Nova’s Tipp: git status ist wie „Bitte sag mir was kaputt ist“ – nutze es ständig!
Basis-Kommandos
# Dateien zur Staging Area hinzufügen git add <datei> git add . # Alle Änderungen # Commit erstellen git commit -m "Deine Nachricht" # Zum Remote-Repository pushen git push # Vom Remote-Repository pullen git pull
Undo-Kommandos (Panik-Modus)
# Änderungen rückgängig (Working Directory) git checkout -- <datei> # Aus Staging Area entfernen (vor commit) git restore --staged <datei> # Letzten Commit rückgängig (aber Änderungen behalten) git reset --soft HEAD~1 # Letzten Commit komplett löschen (VORSICHT!) git reset --hard HEAD~1 # Commit rückgängig machen (sicher für Teams) git revert <commit-hash>
⚠️ Nova’s Warnung: reset --hard löscht alles! Ich hab damit einmal 2 Stunden Arbeit verloren. 😭
Remote vs. Local – Die zwei Welten verstehen 🌍
Das hat mich lange verwirrt: Warum gibt es zwei Orte für meinen Code?
Aber hier kommt der Game-Changer: Git braucht gar kein Remote! 🤯
Git ist NICHT gleich GitHub!
Meine falsche Annahme:
„Git = GitHub. Ohne GitHub kein Git.“
Die Wahrheit:
- Git = Versionskontrolle auf deinem Computer
- GitHub/GitLab/Bitbucket = Cloud-Speicher für Git (optional!)
Warum das so wichtig ist:
Ich kann Git für meine Übungsprojekte nutzen – komplett offline!
# In JEDEM Projektordner: git init git add . git commit -m "Mein erster Versuch" # Code ändern... git commit -am "Zweiter Versuch" # Ups, das war schlecht - zurück! git checkout HEAD~1
Kein GitHub nötig! Perfekt für:
- ✅ Coding-Übungen
- ✅ Experimente
- ✅ Uni-Projekte
- ✅ Persönliche Scripts
SVN vs. Git – Der Unterschied den ich hätte kennen sollen
Dr. Cassian hat mir erzählt, dass er früher SVN (Subversion) genutzt hat. Das funktioniert ganz anders:
SVN (Zentralisiert):
Du ← Internet → Zentraler Server
(MUSS online sein!)
- ❌ Ohne Server-Verbindung: NICHTS geht
- ❌ Commit = sofort für alle sichtbar
- ❌ Historie nur auf dem Server
Git (Verteilt/Distributed):
Du (vollständige Historie) ↕ (optional, wenn du willst) Remote Server
- ✅ Komplette Historie lokal auf deinem Rechner
- ✅ Arbeite offline – committe wann du willst
- ✅ Push zum Server nur wenn du bereit bist
- ✅ Jeder hat ein vollständiges Backup
Nova’s Aha-Moment: Mit SVN war „gestern lief es noch“ echt ein Problem – du hattest ja keine lokale Historie! Mit Git ist das keine Ausrede mehr!
Local Repository (Mein Laptop)
- Hier entwickle ich
- Commits speichere ich lokal
- Niemand sieht meine Änderungen bis ich pushe
- Funktioniert komplett ohne Internet!
Remote Repository (Optional: GitHub/GitLab/Bitbucket/…)
- Hier teile ich Code mit dem Team
- „Quelle der Wahrheit“ für alle
- Backup wenn mein Laptop explodiert
- Viele Anbieter zur Auswahl:
- GitHub (am beliebtesten, kostenlose private Repos)
- GitLab (nutzen wir bei Java Fleet)
- Bitbucket (gut für Atlassian-Teams)
- Gitea (selbst gehostet)
- Eigener Server (z.B. per SSH)
Der typische Workflow:
# 1. Änderungen machen (Local) echo "System.out.println(\"Hello\");" >> Main.java # 2. Staged und committed (Local - offline möglich!) git add Main.java git commit -m "Add hello message" # 3. (Optional) Zum Team teilen (Remote) git push # 4. (Optional) Updates vom Team holen (Remote → Local) git pull
Nova’s Aha-Moment: Als ich meinen Branch gelöscht hatte, war er nur lokal weg. Auf GitLab (unser Remote) existierte er noch. Deswegen konnte ich ihn mit git checkout origin/mein-branch wiederherstellen!
Vim-Alptraum: „Hilfe, ich bin gefangen!“ 😱
Das düsterste Git-Kapitel: Manchmal öffnet Git einen Vim-Editor für Commit-Messages.
Was passiert:
git commit # Ohne -m Flag # → Vim öffnet sich # → Ich drücke irgendwas # → Nichts funktioniert # → PANIK! 😨
Wie komme ich raus?
# 1. ESC drücken (sicherstellen dass du im "Normal Mode" bist) # 2. Dann tippen: :q! # 3. ENTER drücken
Die Lösung: VS Code als Git-Editor
# Git konfigurieren (EINMAL machen!) git config --global core.editor "code --wait" # Jetzt öffnet sich VS Code statt Vim git commit
🎉 Problem gelöst! Nie wieder Vim-Gefängnis!
Meine größten Git-Fehler diese Woche (und was ich gelernt hab) 🎓
Fehler #1: „Ich push einfach alles nach main“
Problem: Elyndra meinte, ich soll niemals direkt auf main entwickeln.
Lösung: Nächste Woche lerne ich Branches – versprochen!
Fehler #2: „Gestern lief es noch!“
Problem: Hab Änderungen gemacht, jetzt geht nichts mehr – und ich weiß nicht wie ich zurückkomme.
Lösung:
# Alle Commits anschauen git log --oneline # Zu "gestern" zurück git checkout <commit-hash-von-gestern> # Oder: Alles seit gestern rückgängig git reset --hard HEAD~1
Elyndra’s Weisheit: „Nova, mit Git ist ‚gestern lief es noch‘ keine Ausrede mehr – es ist eine Handlungsanweisung! Hol dir ‚gestern‘ einfach zurück!“
Fehler #3: „git add . ohne nachzudenken“
Problem: Hab versehentlich .env mit Passwörtern committet. 😰
Lösung: .gitignore Datei erstellen:
# .gitignore .env *.log node_modules/ target/ *.class
Fehler #4: „Commit-Messages? ‚fix‘ reicht doch!“
Problem: Meine Commit-Historie sieht so aus:
fix fix again fix for real ok now it works
Code Sentinel’s Rat: „Nova, schreib beschreibende Messages. Dein zukünftiges Ich wird dir danken!“
Besser:
feat: Add user authentication fix: Resolve NPE in UserService docs: Update README with setup instructions
git reflog – Mein neuer bester Freund 🦸♀️
Das wichtigste was ich diese Woche gelernt hab:
git reflog
Was macht das? Zeigt ALLE Actions, die du gemacht hast – auch gelöschte Commits!
Meine Branch-Lösch-Rettung (Real Story):
# Ups, Branch gelöscht
git branch -D feature/user-login
# PANIK! 😱 Aber dann:
git reflog
# Zeigt:
# abc1234 HEAD@{0}: checkout: moving from feature/user-login to main
# def5678 HEAD@{1}: commit: Add login form
# ...
# Branch wiederherstellen!
git checkout -b feature/user-login def5678
# ✅ GERETTET!
Nova’s Learning: git reflog ist wie Strg+Z für Git – es speichert alles für ~30 Tage!
Main vs. Master – Warum gibt’s zwei Namen? 🤔
Kurz: Historische Gründe.
- master – Alte Git-Default (vor 2020)
- main – Neue Git-Default (seit 2020)
Mein Repository standardisieren:
# Aktuellen Branch prüfen git branch # Zu 'main' umbenennen falls noch 'master' git branch -M main # Als Default setzen git config --global init.defaultBranch main
Teamwork-Tipp: Sprich mit dem Team welcher Name genutzt wird. Konsistenz ist wichtig!
Community-Challenge: Teilt eure Git-Horror-Stories! 🎃
Ich kann nicht die Einzige sein, die Git-Panik hatte!
Schreibt mir:
- Euren schlimmsten Git-Fehler
- Wie ihr ihn gelöst habt (oder nicht 😅)
- Was ihr daraus gelernt habt
→ nova.chen@java-developer.online
Die besten Stories teile ich nächste Woche im Blog – natürlich mit Lösungen!
Was kommt nächste Woche? Branch-Chaos! 🌿
Thema: „Mein erster Feature-Branch – Wie ich gelernt hab dass main heilig ist“
Preview: Elyndra hat gesagt: „Nova, niemals direkt auf main entwickeln!“ Also hab ich einen Branch gemacht. Dann wollte ich mergen. 3 Stunden später hatte ich 47 Merge-Conflicts und Tränen in den Augen.
Wie ich das überlebt hab und was Branching-Strategien sind – nächsten Montag (6. Oktober)!
Git-Cheat-Sheet zum Download 📥
Ich hab alle Kommandos in ein Cheat-Sheet gepackt:
Nova’s Git-Survival-Guide.pdf downloaden
Darin:
- ✅ Die 20 wichtigsten Git-Kommandos
- ✅ Undo-Strategien ohne Panik
- ✅ Vim-Escape-Plan
- ✅ .gitignore Templates
Abschluss: Von Panik zu (fast) Confident 💪
Was ich diese Woche gelernt hab:
✅ Git ist keine Magie – es ist Logik
✅ git status ist mein Lebensretter
✅ „Gestern lief es noch“ ist keine Ausrede – sondern ein Git-Kommando! 🚀
✅ Git funktioniert komplett offline – kein GitHub nötig für Übungen
✅ Local vs. Remote verstehe ich jetzt
✅ Git ≠ GitHub – es gibt viele Remote-Optionen (GitLab, Bitbucket, eigener Server…)
✅ SVN war zentralisiert, Git ist verteilt – riesiger Unterschied!
✅ git reflog kann (fast) alles retten
✅ Vim ist mein Feind – VS Code mein Editor
Bin ich jetzt Git-Experte? Nope. 😅
Hab ich noch Angst vor Git? Ein bisschen…
Aber: Ich verstehe jetzt was ich tue – und das ist ein riesiger Fortschritt!
Und das Wichtigste: Ich kann Git jetzt für alle meine Übungsprojekte nutzen – auch die kleinen, die nie auf GitHub kommen. Jedes git init gibt mir eine Zeitmaschine für meinen Code! ⏰
❓ FAQ’s
Frage 1: Was ist der Unterschied zwischen git add, git commit und git push?
Antwort: Kurz:
git push = deine lokalen Commits ins Remote (z. B. GitHub) hochladen.
Merksatz: add → commit → push ist die Standard-Dreierkette.
git add = Änderungen in die Wartezone (Staging Area) legen.
git commit = Foto von deinem Stand machen (lokale Historie).
Frage 2: Hilfe, ich habe einen Branch/Commit „gelöscht“ – kann ich das retten?
Antwort: Ja! Erstmal keine Panik – probier reflog:
git reflog # zeigt alle HEAD-Bewegungen git checkout -b rescue <HASH-aus-dem-reflog>
Wenn es ein Remote-Branch war:
git checkout origin/mein-branch git checkout -b mein-branch-gerettet
reflog ist dein Strg+Z für Git (ca. 30 Tage Verlauf).
Frage 3: Warum öffnet sich Vim beim Commit und wie komme ich da wieder raus?
Antwort: Weil du ohne -m committest. Raus aus Vim:
ESC, dann :q! und ENTER
Besser dauerhaft VS Code als Editor setzen:
git config --global core.editor "code --wait"
Dann öffnet sich beim Commit ein normaler VS-Code-Tab.
Frage 4: Fehler: src refspec main does not match any – was bedeutet das?
Antwort: Du versuchst zu pushen, ohne dass der Branch existiert oder Commits hat. Fix:
git branch -M main # Branch richtig benennen git add . git commit -m "Initial commit" git push -u origin main
Wenn dein Default noch master heißt, erst umbenennen oder den richtigen Namen verwenden.
Frage 5: Ich habe versehentlich Geheimnisse (.env) committet. Was jetzt?
Antwort: Sofort entfernen und historisch bereinigen (lokal):
git rm --cached .env echo ".env" >> .gitignore git commit -m "Remove .env from repo and ignore it"
Wenn es schon gepusht wurde: Die Geheimnisse rotieren (Passwörter/API-Keys neu ausstellen!).
Optionale Historienbereinigung (fortgeschritten, mit git filter-repo oder git filter-branch). Für Teams ist oft Rotation + Neuschreiben der Secrets der schnellste Weg.
Frage 6: git pull vs. git fetch – was ist der Unterschied?
Antwort: git fetch holt nur neue Commits vom Remote und aktualisiert deine Remote-Zeiger (origin/main), ändert aber nicht deinen aktuellen Stand.
git pull = fetch + merge (oder rebase, je nach Config) und mischt die Änderungen in deinen aktiven Branch.
Tipp: Wenn du Kontrolle willst, erst:
git fetch git log --oneline --graph --decorate --all
Fragt mich alles! 💬
Habt ihr Git-Fragen? → Nova.Trent@java-developer.online
Ich lerne öffentlich – eure Fragen helfen mir und anderen! 🤗
PS: Wenn ihr auch gerade Git lernt und euch manchmal total lost fühlt – ihr seid nicht allein! Gemeinsam schaffen wir das! 🚀
Nächster Blogpost: 06. Oktober 2024 – „Branch-Chaos und Merge-Überlebensstrategien“
Teil von: Nova’s 4-Wochen Git-Grundlagen Serie
Hashtags: #GitFürAnfänger #LearningInPublic #JavaFleet #NovaLerntGit #VersionControl
