Die meisten Teams wählen den falschen Workflow, weil sie nur auf Commit-Strukturen schauen. Entscheidend ist, ob externe Reviewer ohne Account revisionssicher eingebunden werden können, und genau dort sind linkbasierte Freigabeprozesse oft sinnvoller als ein klassisches Git-Setup.
Ein typischer Agentur-Morgen beginnt mit fünf Dateinamen für dasselbe Motiv, Feedback in Slack, einer Korrektur per E-Mail und einer Sprachnachricht in WhatsApp. Der Kunde hat bereits eine finale Version gesehen, während die Designerin noch an einer älteren Kopie arbeitet. Niemand kann sicher sagen, welche Datei freigegeben wurde oder ob der letzte Kommentar überhaupt in den aktuellen Stand eingeflossen ist.
Ein Version-Control-Workflow löst deshalb nicht zuerst ein Toolproblem. Er legt fest, wer wann eine Version erzeugt, wie Änderungen geprüft werden, wer freigibt und wie das Ergebnis später nachweisbar bleibt. Die historische Entwicklung von SCCS über RCS, CVS und Subversion bis zu Git zeigt, wie wichtig nachvollziehbare Änderungen, frühere Stände und klare Verantwortlichkeiten geworden sind. Eine historische Einordnung moderner Versionsverwaltung zeigt diese Entwicklung von zentralen zu verteilten Systemen.
Inhaltsverzeichnis
- Warum ein klarer Workflow über Erfolg oder Chaos entscheidet
- Die drei Grundbausteine jedes Version-Control-Workflows
- Git-Flow, Feature-Branch und trunk-based im Vergleich
- Versionierung von Designs, Videos und PDFs im kreativen Alltag
- Was Revision Control im deutschen Compliance-Kontext leisten muss
- Linkbasiertes Proofing als Alternative zum klassischen Git-Setup
- Best Practices für revisionssichere Freigabeprozesse
- Den passenden Workflow für dein Team finden
Warum ein klarer Workflow über Erfolg oder Chaos entscheidet
Drei Designerinnen arbeiten an einer Kampagne. Eine Datei heißt Social_Ad_final.psd, eine zweite Social_Ad_final_neu.psd, die dritte Social_Ad_final_neu2.psd. Währenddessen kommentiert der Kunde einen PDF-Export, der nicht aus dem aktuellen Layout stammt. Die Projektleitung versucht, die Rückmeldungen aus mehreren Kanälen zusammenzuführen, doch die verantwortliche Designerin sieht die entscheidende Anmerkung erst nach dem Export.
Das Problem liegt nicht darin, dass jemand unaufmerksam arbeitet. Der Prozess bietet schlicht keinen verlässlichen Ort für Version, Feedback und Freigabe. Ohne definierte Regeln erzeugt jede Person ihre eigene Wahrheit: eine lokale Datei, einen E-Mail-Anhang oder einen Screenshot im Chat.
Versionierung beginnt vor dem ersten Commit
Ein brauchbarer Workflow beantwortet zunächst vier einfache Fragen:
- Wer arbeitet daran? Die verantwortliche Person oder das zuständige Team muss erkennbar sein.
- Was hat sich geändert? Ein Dateistand braucht eine verständliche Beschreibung, nicht nur einen neuen Dateinamen.
- Welche Version wird geprüft? Kommentare müssen eindeutig einem konkreten Asset-Stand zugeordnet sein.
- Wer darf freigeben? Review und verbindliche Abnahme sind unterschiedliche Zustände.
Diese Logik gilt für Quellcode genauso wie für ein Kampagnenmotiv, einen Videoschnitt oder eine Druckdatei. Die Plattform Frictionless Sharing für kreative Abstimmungen beschreibt den praktischen Kern dieses Problems: Feedback muss dort ankommen, wo die Datei und ihre Version bereits liegen.
"Praktische Regel: Wenn dein Team nicht innerhalb kurzer Zeit sagen kann, welche Datei freigegeben wurde, ist der Workflow nicht belastbar genug.
Ein bewusster Prozess reduziert doppelte Arbeit, weil Änderungen nicht aus mehreren Kanälen rekonstruiert werden müssen. Er senkt auch die Gefahr, dass jemand eine alte Kopie weiterbearbeitet oder eine nicht freigegebene Fassung veröffentlicht. Das ist der strategische Punkt: Die Wahl zwischen Git-Flow, Feature-Branch, trunk-based Development und linkbasiertem Proofing sollte erst erfolgen, nachdem klar ist, welche Art von Arbeit und welche Beteiligten der Prozess abbilden muss.
Für ein Entwicklerteam kann ein Pull Request mit technischem Review ausreichen. Für eine Agentur mit Kundinnen, Druckerei, Videoabnahme und mehreren externen Kommentierenden braucht es zusätzlich einen verständlichen, assetbezogenen Freigabeverlauf. Ein guter Workflow passt sich der Arbeit an, nicht umgekehrt.
Die drei Grundbausteine jedes Version-Control-Workflows
Bevor du einzelne Modelle vergleichst, müssen Commit, Branch und Merge sitzen. Du kannst sie dir wie einen Aktenordner vorstellen, der fortlaufend bearbeitet wird. Jeder wichtige Stand wird dokumentiert, Varianten entstehen separat, und geprüfte Änderungen kehren kontrolliert in die Hauptakte zurück.
Commit als nachvollziehbarer Schnappschuss
Ein Commit speichert einen konkreten Arbeitsstand. In Git gehören dazu typischerweise die geänderten Dateien, die verantwortliche Person, ein Zeitstempel und eine kurze Beschreibung. Für ein Entwicklungsteam kann die Nachricht lauten: „Validierung der Upload-Datei ergänzt“. Bei einem kreativen Asset wäre eine Prozessnotiz wie „Logoabstand nach Kundenfeedback angepasst“ verständlicher als final2.
Der Commit ist kein Kommentar und keine Freigabe. Er beantwortet zunächst nur die Frage, welcher Stand wann gespeichert wurde. Eine spätere Abnahme braucht zusätzliche Informationen, etwa den Prüfer, den Status und den Bezug zum Auftrag.
Branch als geschützter Arbeitsweg
Ein Branch ist ein separater Entwicklungspfad. Du kannst darin eine neue Funktion, eine Layoutvariante oder eine alternative Schnittfassung bearbeiten, ohne die Hauptversion sofort zu verändern. Die Hauptakte bleibt stabil, während die Kopie auf dem Nebentisch entsteht.
Ein Feature-Branch könnte bei Code checkout-payment heißen. Für ein Design wäre kampagne-layout-variante-b sinnvoller. Wichtig ist nicht der Name allein, sondern die Regel, wann der Branch geprüft und zurückgeführt werden darf.
Merge als kontrollierte Rückführung
Beim Merge werden Änderungen aus einem Branch in die Hauptlinie übernommen. In Git können dabei Konflikte entstehen, wenn zwei Personen dieselbe Textzeile oder Datei unterschiedlich verändert haben. Ein Review vor dem Merge hilft, Fehler und unbeabsichtigte Änderungen zu erkennen.
Bei kreativen Binärdateien funktioniert das anders. Zwei PSD-Dateien lassen sich nicht zuverlässig wie Textdateien zusammenführen. Du entscheidest meist, welche Variante weitergeführt wird, und speicherst diesen Übergang als neue Version. Commit, Branch und Merge liefern also die Grundlogik, aber nicht automatisch das passende Proofing.
Git-Flow, Feature-Branch und trunk-based im Vergleich
Die drei bekannten Modelle unterscheiden sich vor allem durch ihren Umgang mit paralleler Arbeit, Releases und Prüfungen. Git-Flow organisiert viele feste Branches und eignet sich für geplante Versionierungsstufen. Feature-Branch-Workflows halten die Struktur schlanker. Trunk-based Development reduziert die Zeit, die Änderungen außerhalb des Hauptzweigs verbringen.
| Kriterium | Git-Flow | Feature-Branch | trunk-based |
|---|---|---|---|
| Release-Zyklus | Geplante Releases mit getrennten Release- und Hotfix-Phasen | Regelmäßige Integration einzelner Aufgaben | Sehr häufige Integration in den Hauptzweig |
| Komplexität | Hoch, da mehrere Branch-Typen und Übergaben gepflegt werden | Mittel, da pro Aufgabe ein Branch entsteht | Niedrigere Branch-Komplexität, aber hohe Anforderungen an Tests |
| Geeignete Teamgröße | Teams mit klaren Rollen und parallelen Release-Stufen | Kleine bis mittelgroße Teams | Reife Teams mit automatisierter Absicherung |
| Stärke | Klare Trennung von Entwicklung, Release und Hotfix | Verständlicher Mittelweg für kontrollierte Zusammenarbeit | Schnelles Feedback und kurze Integrationswege |
| Grenze | Mehr Pflege, mehr Übergabepunkte und höheres Konfliktrisiko | Branches können trotzdem lange offen bleiben | Unfertige Änderungen müssen sicher verborgen oder abgesichert werden |
| Passender Kontext | Produkte mit geplanten Releases und mehreren Wartungslinien | Produktentwicklung mit kontinuierlicher Integration | Hochfrequente Auslieferung mit stabiler CI/CD-Pipeline |
Git-Flow für geplante Release-Stufen
Git-Flow trennt Feature-, Release- und Hotfix-Branches. Das ist hilfreich, wenn ein Team eine Version vorbereitet, parallel an neuen Funktionen arbeitet und dringende Korrekturen unabhängig davon ausliefert. Der Preis ist organisatorischer Aufwand. Jede zusätzliche Linie braucht Regeln, Zuständigkeiten und eine klare Entscheidung, wann sie zurückgeführt wird.
Feature-Branch als pragmatischer Mittelweg
Beim Feature-Branch-Workflow arbeitet jede Aufgabe in einem eigenen Branch. Nach Review und automatisierten Tests wird sie in den Hauptzweig gemergt. Das Modell funktioniert gut, wenn Aufgaben überschaubar bleiben und das Team nicht für jede Änderung eine umfangreiche Release-Struktur benötigt.
Trunk-based Development für reife Lieferketten
Beim trunk-based Ansatz landen Änderungen häufig direkt im Hauptzweig. Feature-Flags, automatisierte Tests und disziplinierte Reviews verhindern, dass unfertige Arbeit sichtbar oder auslieferbar wird. Das Modell kann sehr schnell sein, verlangt aber eine stabile technische Absicherung und ein Team, das kleine Änderungen konsequent integriert.
Die passende Workflow-Automatisierung für Kreativteams muss deshalb nicht dieselbe Struktur wie eine CI/CD-Pipeline nachbilden. Für kreative Arbeit zählt vielmehr, dass Assets, Kommentare und Abnahmen sauber zusammenbleiben.
Versionierung von Designs, Videos und PDFs im kreativen Alltag
Git behandelt eine PSD-, INDD- oder MP4-Datei im Wesentlichen als Binärdatei. Das System kann speichern, dass sich der Blob geändert hat, wer ihn abgelegt hat und welcher Stand davor existierte. Es kann jedoch nicht wie bei einer Textdatei sinnvoll anzeigen, welches Pixel verschoben, welche Ebene umbenannt oder welcher Bildausschnitt neu geschnitten wurde.
Ein Design-Branch bleibt eine Auswahlentscheidung
Nehmen wir ein Photoshop-Layout für eine Social-Kampagne. Die Designerin erstellt aus der Originaldatei einen Branch für eine alternative Bildkomposition. In der technischen Logik entspricht das einer isolierten Variante. Nach dem Review wird nicht automatisch Ebene für Ebene gemergt. Das Team entscheidet, ob Variante A oder B weitergeführt wird, oder überträgt die gewünschte Änderung manuell in einen neuen Hauptstand.
Die Versionskette sollte dabei verständlich bleiben: Original, Layoutvariante, geprüfter Korrekturstand und freigegebene Fassung. Ein Name wie kampagne_de_feed_v1.3.psd kann helfen, reicht allein aber nicht aus. Die zugehörige Review-Historie muss erklären, welche Änderung zu diesem Stand geführt hat und wer sie bestätigt hat.
Video braucht Zeitbezug statt Dateivergleich
Bei einem Videoschnitt gehört Feedback an eine konkrete Stelle. Ein Kommentar wie „Bitte den Übergang anpassen“ ist unpräzise. Ein Marker mit Timecode, Shot-Status und klarer Anweisung macht daraus eine bearbeitbare Aufgabe.
Nach der Korrektur entsteht eine neue Version. Der alte Schnitt bleibt erhalten, der neue Kommentar wird geschlossen oder erneut geöffnet, und die Abnahme bezieht sich auf genau diesen Export. Ein Repository kann die Dateien aufbewahren, aber es liefert nicht automatisch framegenaue Marker oder eine visuelle Diskussion direkt am Bild.
PDF-Druckdaten folgen einer ähnlichen Kette. Korrekturen an Beschnitt, Text oder Farbflächen sollten mit einem eindeutig benannten Stand verbunden sein. Das Team braucht eine Zuordnung zwischen markierter Stelle, Änderungsauftrag, neuer Datei und Freigabe.
Die Strategien für Versionskontrolle bei Dokumenten helfen bei dieser Übertragung, solange du technische Archivierung und inhaltliches Proofing nicht verwechselst.
"Git ist für kreative Binärdateien ein gutes Archiv und ein Etikett. Es ist kein vollständiges Proofing-Werkzeug.
Klassische VCS bieten kein natives Pixel-Diff, keine verlustfreie Zusammenführung zweier Designvarianten und ohne Spezialtool keinen präzisen Kommentar an einer Bild- oder Videostelle. Für Code ist das Modell stark. Für visuelle Abnahmen brauchst du eine zusätzliche Ebene.
Was Revision Control im deutschen Compliance-Kontext leisten muss
Ein Ordner mit Dateien wie v1_final_v2_TODO.psd beweist weder die Freigabe noch den Anlass einer Änderung. Er zeigt höchstens, dass jemand Dateien gespeichert hat. Ein revisionssicherer Workflow muss dagegen nachvollziehbar machen, was geändert wurde, wann die Änderung erfolgte, wer sie durchgeführt hat und auf welcher Grundlage sie erfolgte.
Das BSI verlangt im sicheren Software-Lebenszyklus ein Versionierungswerkzeug, mit dem Entscheidungen, Änderungen und Verantwortlichkeiten festgestellt und zurückverfolgt werden können. Die Projektdokumentation soll Fachleuten außerdem ermöglichen, Code, Architektur und Bedrohungsmodellierung nachzuvollziehen und weiterzuentwickeln, wie die BSI-Richtlinie zum sicheren Software-Lebenszyklus beschreibt.
| Anforderung | Quelle | Workflow-Funktion |
|---|---|---|
| Änderung, Zeitpunkt, Urheber und Anlass nachvollziehen | BSI-Grundschutz-Standard | Unveränderbarer Audit-Trail mit Metadaten |
| Aktuelle Stände kurzfristig zugänglich halten | BSI-Grundschutz | Zentraler Zugriff auf den gültigen Arbeitsstand |
| Vorgängerversionen archivieren | BSI-Grundschutz | Geschützte Historie und Wiederherstellung früherer Stände |
| Review systematisch und dokumentiert durchführen | V-Modell XT Bund | Festgelegte Rollen, Prüfkriterien und aufgezeichnete Ergebnisse |
| Freigabe an einen erfolgreichen Prüfschritt knüpfen | BSI-Regelung zu Softwaretests und Freigaben | Getrennter Status für Prüfung und verbindliche Freigabe |
Review und Approval sind nicht dasselbe
Ein Review sammelt Einwände und Korrekturen. Eine Approval-Aktion bestätigt, dass ein bestimmter Stand verwendet, veröffentlicht oder produziert werden darf. Diese Zustände sollten getrennt sichtbar sein. Sonst wird aus einem beiläufigen Kommentar schnell eine vermeintliche Abnahme.
Für deutsche Teams gehören deshalb mindestens ein nachweisbarer Verlauf, rollenbasierte Rechte, unveränderbare freigegebene Stände, zentrale Archivierung und ein exportierbarer Genehmigungsnachweis zum Prozess. Lösch- und Aufbewahrungsregeln müssen ebenfalls festgelegt werden, statt von einzelnen Postfächern oder privaten Laufwerken abzuhängen.
Eine revisionssichere Dokumentation wird dadurch nicht zu einem bürokratischen Zusatz. Sie schützt das Team, wenn später die Frage entsteht, welche Fassung verbindlich war und wer sie auf welcher Grundlage freigegeben hat.
Linkbasiertes Proofing als Alternative zum klassischen Git-Setup
Sobald externe Stakeholder beteiligt sind, zeigt Git seine praktische Grenze. Kundinnen, Redaktionen, Druckereien oder freie Mitarbeitende sollen häufig nur eine Datei prüfen. Ein Repository-Account, Branch-Regeln und technische Review-Oberflächen schaffen dann mehr Zugangshürden als Klarheit.
Ein linkbasierter Proofing-Workflow setzt an einer anderen Stelle an. Die verantwortliche Person teilt eine Review-URL, der Gast öffnet das Asset ohne Konto, markiert eine konkrete Stelle und hinterlässt den Kommentar direkt am Design, PDF oder Video. Die neue Datei wird als nächste Version abgelegt, während Status und Zuständigkeit sichtbar bleiben.
Der Unterschied liegt im Review, nicht im Dateispeicher
Klassische VCS lösen vor allem die technische Zusammenarbeit an Dateien. Linkbasiertes Proofing löst die Kommunikation rund um das Asset. Das ist besonders relevant, wenn Reviewer kein Git-Know-how besitzen, mobil kommentieren oder nur einen einzelnen Korrekturlauf erledigen sollen.
Der Prozess kann so aussehen:
- Link teilen: Die externe Person erhält direkten Zugriff auf den vorgesehenen Prüfstand.
- Stelle markieren: Kommentare sitzen am Bild, auf der PDF-Seite oder an einem Videoframe.
- Status setzen: Offen, in Bearbeitung, erneut prüfen oder freigegeben bleiben klar getrennt.
- Version ersetzen: Der neue Export wird als eigener Stand gespeichert, nicht über die alte Datei gelegt.
- Abnahme protokollieren: Prüfer, Zeitpunkt, Kommentar und Dateistand bleiben zusammen auffindbar.
Das vermeidet Merge-Konflikte im kreativen Review, weil nicht mehrere Personen dieselbe Binärdatei parallel technisch zusammenführen müssen. Es ersetzt Git nicht überall. Für Quellcode, automatisierte Tests und Entwicklerzweige bleibt Git die passendere Grundlage.
Für Agenturen, Marketingteams und externe Produktionspartner ist deshalb ein kombinierter Ansatz oft sinnvoll. Code bleibt in Git, kreative Assets durchlaufen einen visuellen Proofing-Prozess mit nachvollziehbarer Freigabe.
Die Plattform Freigabe per Link für Kreativprojekte steht exemplarisch für diese Ergänzung. Sie bündelt Kommentare, Versionen und Freigaben direkt am Asset und ermöglicht externen Reviewern den Zugang ohne Registrierung. Entscheidend bleibt die Prozessgestaltung: Ein Link allein ist noch kein Audit-Trail. Erst die Zuordnung zu Version, Rolle, Status und Zeitpunkt macht daraus einen belastbaren Ablauf.
Best Practices für revisionssichere Freigabeprozesse
Ein funktionierender Prozess trennt technische Versionierung von inhaltlicher Freigabe. Git kann die Entwicklung von Code sichern, während ein Proofing-System die visuelle Prüfung und Abnahme kreativer Assets dokumentiert.
- Code und Assets getrennt verwalten: Nutze Git für Quellcode und geeignete Asset- oder Proofing-Strukturen für PSD, INDD, MP4 und PDF. So zwingst du nicht beide Dateiwelten in dasselbe Modell.
- Eindeutige Versionsnummern vergeben: Jede Datei erhält eine nachvollziehbare Kennzeichnung und bleibt einem Projekt, Auftrag oder Produktionsschritt zugeordnet.
v1.3ist dabei nur dann aussagekräftig, wenn die Änderung im Verlauf beschrieben wird. - Freigegebene Stände unveränderbar speichern: Nach der Abnahme darf niemand die zugrunde liegende Datei still ersetzen. Eine neue Korrektur erzeugt einen neuen Stand und erhält die frühere Fassung.
- Prüferidentität und Zeitstempel erfassen: Der Verlauf muss zeigen, wer kommentiert, geprüft und freigegeben hat. Externe Reviewer sollten ohne Konto teilnehmen können, ohne dass die Nachweisführung verloren geht.
- Review und Approval trennen: Ein offener Korrekturhinweis ist keine Freigabe. Definiere klare Statuswerte und erlaube die verbindliche Abnahme nur den dafür benannten Rollen.
- Ein zentrales Archiv führen: E-Mail-Anhänge und lokale PDF-Kopien gehören nicht zur führenden Dokumentation. Das Archiv sollte den gültigen Stand, frühere Versionen und den Genehmigungsverlauf gemeinsam auffindbar machen.
- Regelmäßig prüfen: Vergleiche abgeschlossene Projekte mit den definierten Regeln. Ein kurzer Audit zeigt, ob finale Dateien, Freigaben und Zuständigkeiten tatsächlich zusammen archiviert wurden.
Die BSI-Anforderungen machen deutlich, warum ein einfacher Dateiordner nicht genügt. Ein Proofing-Tool muss zusätzlich Kommentare am richtigen Objekt, Versionen, Rollen und Abnahmen verbinden. Damit bleibt die kreative Arbeit beweglich, während die Dokumentation auch nach Abschluss des Projekts verständlich bleibt.
Den passenden Workflow für dein Team finden
Die Entscheidung beginnt nicht mit der Frage, welcher Workflow in der Entwicklerwelt am beliebtesten ist. Kläre zuerst, wie viele Personen parallel arbeiten, wie häufig ihr veröffentlicht, wie viele externe Reviewer beteiligt sind und welche Nachweise eure Kunden oder Prüfstellen erwarten.
Trunk-based Development passt zu kleinen, technisch reifen Teams mit kurzen Lieferzyklen, automatisierten Tests und konsequenter Integration. Git-Flow ist sinnvoll, wenn mehrere Release-Stufen, Wartungslinien und geplante Auslieferungen getrennt verwaltet werden müssen. Feature-Branches bleiben der pragmatische Mittelweg für Teams, die Aufgaben isolieren und nach einem Review kontrolliert in den Hauptzweig übernehmen möchten.
Für Design-, Video-, Foto- und Content-Teams liegt die entscheidende Grenze bei der Abnahme. Wenn externe Personen ohne Entwicklerkonto kommentieren, visuell markieren und einen konkreten Stand freigeben sollen, ist ein linkbasierter Proofing-Workflow oft ehrlicher als ein Git-Setup, das diese Beteiligten in technische Strukturen zwingt.
"Wenn dein Team mehr Zeit mit Commit-Namen, Dateisuche und Merge-Konflikten verbringt als mit der eigentlichen kreativen Arbeit, passt der Workflow wahrscheinlich nicht zur Aufgabe.
Die tragfähige Lösung ist häufig eine Kombination: Code in Git, kreative Assets in einer versionierten Proofing-Umgebung, klare Rollen für Review und Freigabe sowie ein zentrales Archiv. So bekommt jede Arbeitsart das Modell, das sie tatsächlich unterstützt.
Mit draftgo bündelst du Kommentare, Versionen und Freigaben für Designs, Videos, Fotos und PDFs direkt am jeweiligen Asset, externe Reviewer greifen per Link ohne Konto zu. Wenn du deinen Freigabeprozess nachvollziehbar strukturieren und verstreutes Feedback ersetzen willst, besuche draftgo und richte deinen nächsten Review-Lauf zentral ein.
Written by
Emilia
Content Producer
Ready to streamline your approval processes?
Get started with draftgo today and see how easy professional collaboration can be.