🌿 · Versionskontrolle

Git: Versionskontrolle die jeden Code sicher macht

Git ist das fundamentale Werkzeug jedes Entwicklers – und weit mehr als ein Backup-System. Wer Git versteht, kann Experimente wagen, Fehler rückgängig machen und mit anderen zusammenarbeiten ohne Code zu verlieren.

CommitsBranchesMergeRebaseGitHub

Git-Grundlagen: Commits, Branches, Remotes

Git verwaltet Snapshots (Commits) in einem gerichteten azyklischen Graphen. Die wichtigsten Konzepte:

  • Commits: Snapshots des gesamten Projekts mit Zeitstempel und Autor. Nicht nur "letzte Änderungen" – sondern ein vollständiges Abbild.
  • Branches: Zeiger auf Commits. `main` ist der Hauptbranch, Feature-Branches für neue Entwicklung. Kostenlos und schnell zu erstellen.
  • Staging Area: git add wählt aus was in den nächsten Commit kommt – ermöglicht atomare, logische Commits statt "alles auf einmal"
  • Remotes: GitHub/Gitea/GitLab sind nur Server die Repositories hosten. git push synchronisiert lokale Commits mit dem Remote.
# Täglicher Git-Workflow git status # Was hat sich geändert? git diff # Konkrete Änderungen sehen git add -p # Interaktiv Teile zum Commit auswählen git commit -m "feat: neue Funktion" git push origin main

Branching-Strategie und Merge vs. Rebase

Für Solo-Projekte und kleine Teams: einfache Strategien gewinnen immer.

  • Feature Branches: Für jede neue Funktion oder jeden Bug-Fix ein eigener Branch von `main`. Merge zurück wenn fertig.
  • Merge: Erhält die komplette Branch-History – gut für öffentlichen Code wo die Entstehungsgeschichte wichtig ist.
  • Rebase: Schreibt History um, macht sie linear – saubererer Log, aber nie auf geteilten/öffentlichen Branches verwenden.
  • Commit-Messages: Konvention type: beschreibung (feat, fix, docs, refactor) macht CI/CD-Pipelines und Changelogs einfacher.

Für Server-Deployments: Ein Push auf `main` triggert via CI/CD-Pipeline automatisch den Deploy. Oder direktes `git pull` auf dem Server per Webhook.

Git für Infrastruktur: Configs, Dotfiles und IaC

Git ist nicht nur für Code. Die besten Einsätze jenseits von Sourcecode:

  • Dotfiles: `.bashrc`, `.vimrc`, SSH-Config in einem Git-Repo – auf jedem neuen Rechner sofort heimisch fühlen
  • Server-Configs: Compose-Dateien, Nginx-Configs, Traefik-Konfigurationen in Git. Änderungen nachvollziehbar, Rollback möglich.
  • Privates Gitea: Self-hosted Git-Server auf eigenem Server – kein GitHub-Dependency, volle Datenkontrolle. Compose-basiertes Setup in Minuten.
  • .gitignore: Secrets, `.env`-Dateien, Build-Artefakte – immer ignorieren. git secret oder git-crypt für Repos wo Secrets versioniert werden müssen.

Häufige Fragen zu Git

Noch nicht gepusht: `git reset HEAD~1` (behält Änderungen) oder `git reset --hard HEAD~1` (verwirft alles). Bereits gepusht: `git revert HEAD` erstellt einen neuen Commit der die Änderungen rückgängig macht – sicherer als rewrite der öffentlichen History.

Konflikte sind normal – keine Panik. Dateien mit `<<<<<<`-Markierungen öffnen, beiden Versionen verstehen, manuelle Entscheidung treffen. VS Code zeigt Konflikte mit UI. Nach Auflösung: `git add` und `git merge --continue`. Häufige kleine Merges verhindern große Konflikte.

GitHub für: Open Source, Zusammenarbeit, CI/CD-Ökosystem (Actions). Gitea für: private Projekte mit Datenkontrolle, kein Cloud-Dependency, läuft auf einem 1€/Monat VPS. Beide können gleichzeitig als Remotes existieren – lokales Gitea als Primär, GitHub als Spiegel.

`.env`, `*.key`, Credentials, `node_modules/`, `__pycache__/`, `.venv/`, Build-Outputs, IDE-Ordner (`.vscode/`, `.idea/`). gitignore.io generiert passende Templates für jede Sprache/Framework. Einmal global konfigurieren: `git config --global core.excludesfile ~/.gitignore_global`.