Git für saubere Versionierung und nachvollziehbare Releases

Einordnung

Überblick

Git ist die Grundlage für nachvollziehbare Entwicklung: Änderungen sind versioniert, Reviews werden reproduzierbar und Releases lassen sich sauber taggen. In Teams entscheidet ein guter Workflow darüber, wie schnell Features sicher in Produktion kommen.

Schwerpunkt

Workflows, die im Alltag funktionieren

Ich setze auf klare Branching‑Strategien (trunk‑based oder GitFlow, je nach Team), Pull‑Request‑Reviews und automatisierte Checks, bevor etwas gemerged wird. So bleibt die Historie verständlich, und Qualitätssicherung passiert kontinuierlich statt „am Ende“.

Schwerpunkt

Release- und Automations‑Setup

Mit Tags, Changelogs und semantischer Versionierung werden Releases planbar. CI/CD integriert Linting, Tests und Deployments direkt in den Merge‑Prozess, sodass der Weg von Commit zu Produktion transparent ist. Ergänzend helfen Issue‑Templates, PR‑Vorlagen und klare Contribution‑Guidelines beim Onboarding.

Git ist mehr als ein Tool, es ist ein Prozess. Mit den richtigen Konventionen wird Entwicklung schneller, sicherer und für alle Beteiligten nachvollziehbar.

Praxis

Was das für dein Projekt bedeutet

Für Auftraggeber ist das Repository der eigentliche Wert hinter einem Webprojekt. Dort liegt die vollständige Historie: wer wann was geändert hat, warum eine Entscheidung so gefallen ist und welcher Stand zu welchem Zeitpunkt live war. Fehlt diese Historie, wird jede spätere Änderung zur Rekonstruktion.

Deshalb gehört das Repository dem Unternehmen, nicht dem Dienstleister. Bei neuen Projekten lege ich es auf Wunsch direkt in eurer Organisation an, sonst wird es zum Projektende vollständig übergeben, inklusive Branches, Tags und Pipelines. Das macht einen Wechsel jederzeit möglich, ohne bei null anzufangen.

Im Alltag zahlt sich das vor allem dann aus, wenn etwas schiefgeht: Ein fehlerhaftes Release lässt sich gezielt zurücknehmen, statt hektisch nachzubessern, und der Stand von vor der Änderung ist in Sekunden wiederhergestellt.

Aus einem Projekt

Wie diese Website versioniert wird

Jede Änderung an wigandt.tech läuft über einen Feature-Branch und einen Pull Request. Vor dem Commit prüft ein Husky-Hook den Code, im Pull Request laufen Linting, Typprüfung, Unit-Tests, ein vollständiger Build und eine Prüfung der strukturierten Daten gegen das erzeugte HTML. Erst wenn alles grün ist, wird gemerged.

Dadurch ist jede Veröffentlichung nachvollziehbar: Welcher Commit hat welchen Text geändert, wann wurde eine Weiterleitung ergänzt, welcher Stand war zu welchem Zeitpunkt live. Dieselbe Arbeitsweise richte ich in Kundenprojekten ein, auch dort, wo vorher direkt auf dem Server gearbeitet wurde.