Git

Git ist ein verteiltes Versionskontrollsystem (VCS), das Linus Torvalds 2005 für die Linux-Kernel-Entwicklung geschrieben hat. Im Gegensatz zu zentralen Systemen wie SVN hat jeder Entwickler eine vollständige Kopie der gesamten Projekt-Historie lokal — offline arbeiten, Merges ohne Server und wiederherstellbare Versionen sind dadurch Kerneigenschaften, keine Add-ons. Die Kernbegriffe: Ein Repository (Repo) ist das Projekt mit seiner gesamten Historie. Ein Commit ist eine gespeicherte Änderung mit Autor, Timestamp, Diff und Parent-Pointer — die kleinste atomare Einheit. Branches sind Zeiger auf Commits, die parallel existieren (feature/login, bugfix/hotfix-X, main). Merge und Rebase verbinden Branches, wobei Merge einen "Merge-Commit" erzeugt und Rebase die Historie linearisiert. Remotes (origin, fork) sind andere Kopien des Repos, typischerweise auf GitHub, GitLab, Bitbucket oder Azure DevOps gehostet. Der Standard-Team-Workflow: Feature-Branch von main anlegen → lokale Commits → Push auf Remote → Pull Request (PR) / Merge Request → Code-Review durch Team → Merge in main → CI-Pipeline deployt automatisch. Varianten sind Git Flow (explizite develop/release/hotfix Branches, klassisch für Release-Zyklen), Trunk-Based Development (kurzlebige Feature-Branches, Continuous Deployment) und GitHub Flow (minimal, ideal für Web-Apps). Git-Skills gehören heute zur Grundausstattung jeder professionellen Softwareentwicklung. Für nicht-technische Teammitglieder (Design, Content) sind grafische Clients wie GitHub Desktop, Sourcetree, Fork oder Tower der einfachste Einstieg. Die häufigsten Fallen: vergessene .gitignore (Secrets im Repo), Force-Push auf shared Branches (überschreibt Kollegen-Arbeit), zu große Commits ohne Kontext. Disziplin zahlt sich aus: saubere atomare Commits mit aussagekräftigen Messages sind die Grundlage für Debugging, Code-Review und Audits.