Unser Git-Workflow in der Agentur

Git ist das Rückgrat jeder professionellen Softwareentwicklung — aber Git allein ist kein Workflow. Wie ein Team mit Branches umgeht, wie Commits strukturiert werden und wie Code-Reviews ablaufen, macht den Unterschied zwischen einem Repository, das Klarheit schafft, und einem, das zur Blackbox wird. Bewährt hat sich ein übersichtlicher Workflow, der so viel Struktur vorgibt wie nötig — und nicht mehr, als ein Projekt tatsächlich braucht.

Unser Grundprinzip: main ist immer deploybar. In Kundenprojekten arbeiten wir nach diesem Grundsatz: kein direktes Committen auf main, keine halbfertigen Änderungen, keine „kurz mal schnell”-Fixes ohne Branch. Das klingt streng, schützt aber davor, dass der Produktionsstand unklar wird — und hat uns mehrfach davor bewahrt, versehentlich unfertige Features in die Live-Umgebung zu schieben.

Feature Branches und Commit-Konventionen

Jede neue Funktion, jeder Bugfix und jede größere Änderung bekommt einen eigenen Branch. Die Benennung folgt einem einfachen Schema: feature/kurze-beschreibung, fix/was-behoben-wird, chore/was-aufgeraeumt-wird. Das macht auf einen Blick klar, worum es geht — sowohl im Repository als auch in der Kommunikation im Team. Branches werden klein gehalten: ein Branch, eine Aufgabe. Große Branches mit vielen Änderungen sind schwer zu reviewen und schwer zu mergen.

Für Commits empfehlen sich Conventional Commits — ein standardisiertes Format, das mit einem Typ beginnt: feat:, fix:, docs:, refactor:, chore:. Der Vorteil: Aus der Git-Historie lässt sich sofort ablesen, welche Art von Änderung vorgenommen wurde. Das erleichtert die automatische Generierung von Changelogs und hilft beim Debuggen, wenn man verstehen will, wann und warum eine bestimmte Verhaltensänderung eingeführt wurde.

Code-Reviews als Lerngelegenheit

Pull Requests werden von mindestens einer weiteren Person reviewed, bevor sie in main gemergt werden. Das ist keine Formalität — es ist einer der wertvollsten Lernprozesse im Team. Ein gutes Review kommentiert nicht nur Fehler, sondern stellt Fragen, macht Alternativvorschläge und erklärt den Kontext. Reviews sollten als Gespräch verstanden werden, nicht als Prüfung. Das senkt die Hemmschwelle, offen zu kommentieren, und führt zu besserer Codequalität.

• main ist immer deploybar — in Kundenprojekten keine direkten Commits
• Feature Branches: klein, fokussiert, gut benannt
• Conventional Commits für eine lesbare Git-Historie
• Pull Requests immer mit mindestens einem Review
• Automatisierte Tests und Linting als Pflichtschritt vor dem Merge

Dieser Workflow ist kein Dogma — er ist eine Grundlage, die wir bei Bedarf anpassen. Für sehr kleine Projekte mit wenig Gleichzeitigkeit kann der Overhead reduziert werden. Für größere Teams oder komplexere Deployments braucht es mehr Struktur. Aber die Prinzipien — Klarheit, Nachvollziehbarkeit, Qualitätskontrolle — bleiben immer gleich.