- Definition: Versionskontrolle (VCS) ist ein System, das Änderungen an Dateien (meist Code) über die Zeit speichert und verwaltet.
- Kernbegriffe: Repository (Projektablage), Commit (Speichern einer Änderung), Branch (Nebenlinie/Zweig für Entwicklung), Merge (Zusammenführen).
- Zusammenarbeit: Entwickler teilen Änderungen über Remote-Repositories (push/pull), lösen Konflikte und prüfen Änderungen.
- Beispiele: Beliebte Systeme sind Git, Subversion (SVN) und Mercurial — Git ist heute am weitesten verbreitet.
- Möglichkeit Änderungen rückgängig zu machen
- Historie (wer hat was wann geändert)
- Zusammenarbeit: parallele Arbeit dank Branches
- Nachvollziehbarkeit: Code Reviews & Pull Requests (PRs)
- Experimentieren ohne Risiko (dank Branches, Tags, Releases)
- Reproduzierbarkeit (checke konkreten Zwischenstand aus und teste)
- Git = verteiltes Versionskontrollsystem (lokales Tool)
- GitHub, GitLab oder Codeberg = Hosting-Plattformen + Web-UI
- Zusatzfunktionen (Issues, PRs/MRs (Merge Requests), Actions, Wikis, bearbeiten in Web-UI-Editor)
- Plattformen bieten Kollaboration, Sichtbarkeit, Berechtigungen, CI/CD, Web-Review-UI.
- Git installieren
- VSCode installieren
# Ist Git installiert?
git --version
# Setze einmalig globale Konfiguration.
git config --global user.name "Vorname Nachname"
git config --global user.email "me@beispiel.de"
git config --global init.defaultbranch main
# Zeige globale Konfiguration an.
git config --global --list- ⚙️ Settings setzen:
terminal.integrated.defaultProfile.windowszu "Git Bash" - 🧩 Extension installieren:
- "Git History" (by Don Jayamanne)
- "GitLens — Git supercharged" (by GitKraken)
- "Markdown All in One" (by Yu Zhang)
mkdir git-tryout-sven
cd git-tryout-sven
git init
# Oder: git init --initial-branch=main
# wird aber nicht gebraucht, weil wir global den main branch
# als default definiert haben.# Lege PowerShell Skript mit Inhalt an.
New-Item -Path . -Name "beautiful-script.ps1" -ItemType "file" -Value "Write-Host 'Hi SDT folks'"# Aktuellen Git Status prüfen ==> eine Datei ist "untracked".
git status
# Diese Datei hinzufügen, zu Staging Area.
git add beautiful-script.ps1
# Oder: git add .
# um alle unstages Dateien hinzuzufügen.
# Commit mit Message
git commit -m "Added: Beautiful PowerShell script."- Dies machen wir zusammen über die Web-UI.
- Im wesentlichen einfach den übersichtlichen Buttons der GitHub Web-UI folgen.
- Repository Namen
git-tryout-svenvergeben (so wie der Ordner am Anfang (kein muss, nur Empfehlung)).
# verbinden
git remote add origin https://github.com/sven-seyfert/git-tryout-sven.git
# pushen
git push -u origin mainHinweis: Es muss keine GitHub Organisation sein. Einfach ein Repository was einem nicht gehört.
# Nach dem Clone liegt das Repo. lokal im Ordner wo der Befehl abgesetzt wird.
# Daher ggf. den Ordner danach verschieben.
git clone https://github.com/big-direkt/software-development-training.git- Code schreiben (fizz-buzz.ps1) und pushen wiederholen (direkt auf main).
- Der push wird verweigert - branch rules (protected default branch) policy greift.
- Was also stattdessen tun 🤔 ?
- Fork in GitHub Web-UI erstellen.
- Damit ist das Ziel-Repo. im eigenen GitHub Bereich verfügbar.
- Dieses Repo wird dann ge'clone't (clone des Forks nach lokal).
- Sync (upstream) einrichten.
# Sein geforktes Repo. referenzieren
# oder das des Original-Repos., welches wir vorher ge'clone't hatten, setzen.
git remote set-url origin https://github.com/sven-seyfert/software-development-training.git
# Upstream setzen, damit überhaupt ein Pull Request (PR) möglich sein kann.
git remote add upstream https://github.com/big-direkt/software-development-training.gitNun muss, da auf den allermeisten Repositories eine branch policy liegt, die verhindert das man von "main" auf "main" push kann, über einen extra Zweig (branch) gegangen werden. Von diesem aus kann man dann den PR erstellen.
# Create new branch.
git checkout -b add-fizz-buzz-example
# Arbeiten und dann:
git add .
git commit -m "Added: Awesome fizz-buzz example code."
git push -u origin add-fizz-buzz-example- Auf GitHub: Compare & pull request (Web-UI).
- Reviewer zuweisen (approval principle).
- Einfach der Nutzerführung auf GitHub folgen.
- Reviewer kommentiert (optional aber in der Praxis üblich).
- (Optional) fordert der Reviewer weitere Änderungen beim PR-Steller an.
- Dieser pusht weitere commits auf denselben Branch (kein neuer PR nötig).
- Dann wird erneut reviewed.
- Wenn alles gut, dann gibt der Reviewer sein okay, "approval".
- Danach folgt der Merge via Web-UI.
- Lokal: nach Merge → git checkout main → git pull upstream main oder falls Fork: git fetch upstream && git merge upstream/main oder git rebase upstream/main.
# Zurück auf main wechseln.
git checkout main
# Prüfen was potenziell geholt wird (welche Dateien und Änderungen).
git fetch --all --prune
git fetch upstream --prune
# Den aktualisierten Code-Stand von main holen (sync/pull).
git pull upstream main
# Oder: git pull origin main
# Lokalen branch löschen.
git branch -d add-fizz-buzz-example# Auflistung lokal
git branch
# Auflistung remote
git branch -r
# Auflistung all
git branch -a- git stash, git stash pop erläutern
- siehe Cheat-Sheet und folgendes 🎬 stash Video
- praktisches Beispiel zeigen
Dies kann via Terminal oder einfach in VSCode (besser) dargestellt werden.
Angenommen der Ursprungstext der Commit Message war "Changed: Color of login submit button to red.", ist aber falsch, denn der Button wurde grün, nicht rot. Dann:
# ==> --amend
git commit --amend -m "Changed: Color of login submit button to green."Hier erstellen wir einen neuen Branch, der den Code-Stand des vorher ausgewählten Commit-Standes hat. Somit können wir einen alten Stand nochmal testen, nachvollziehen ohne das wir den aktuelleren Stand verlieren.
Im neuen Branch ist dann also alles "alt", kann aber mit git checkout main (also wechseln zwischen den Branches) wieder zu main zurückgesprungen werden.
# Zu welchem Stand soll zurück gegangen werden?
# Commit hash kopieren.
git log
# Branch anlegen mit dem Stand des commit hashs.
# git checkout -b <branch-name> <commit-hash>
git checkout -b specific-commit-branch dcabfb9- Git TAGs und Releases: für GitHub allgemein sinnvoll und für automatisch generierte CHANGELOG.md Dateien ebenfalls praktisch.
- Beispiel: eines meiner privaten Projekte
- Hier spielt dann auch Keep a Changelog und Semantic Versioning eine große Rolle.
Zu einem pull request commit weitere Commits hinzufügen, bevor der PR gemerged wird.
# Get PR by pull request identifier (hier pr-1).
git fetch origin pull/1/head:pr-1
git checkout pr-1
# Commit changes.
git add .
git commit -m "Styled: Trival formatting change."
# Add remote fork (zum lokalen Repo).
git remote add kneofo git@github.com:kneofo/software-development-training.git
# Push back to PR.
git remote set-url kneofo https://github.com/kneofo/software-development-training.git
git push kneofo pr-1:patch-1
# Clean-up
git remote remove kneofo
git remote -v # optional, dient nur zur Kontrolle
git branch -vv # optional, dient nur zur Kontrolle
git branch -D pr-1