Dein Content verdient dieselbe Versionskontrolle wie dein Code

Einen CMS-Eintrag zu veröffentlichen, fühlt sich aus gutem Grund riskant an: Wenn etwas schiefgeht, ist der Weg zurück zum Ausgangspunkt nicht immer einfach. Manche Plattformen bieten dir nur einen kleinen Undo-Stack. Andere begrenzen die Historie auf eine feste Anzahl an Revisionen oder ein rollierendes 30-Tage-Fenster. Wieder andere behandeln die vollständige Versionshistorie als Enterprise-Feature, das du separat freischalten musst.

Das Ergebnis: Ein Content-Team veröffentlicht mit Vorsicht — nicht, weil es diszipliniert ist, sondern weil es nervös ist. Das ist die falsche Art von Vorsicht.

b10cks behält jede Version für immer, in jedem Plan. Probiere frei aus. Rolle jederzeit souverän zurück.

Jedes Mal, wenn Content in b10cks gespeichert wird — Entwurf, Autosave, Veröffentlichung oder Bearbeitung — wird eine neue Version erstellt und gespeichert. Es gibt keine Aufbewahrungsfrist. Kein Limit für die Anzahl der Revisionen. Kein „ältere Versionen werden nach 30 Tagen gelöscht“.

• Vollständiger Änderungsverlauf: Sieh jede Version, wer sie erstellt hat und wann
• Wiederherstellung mit einem Klick: Stelle jede frühere Version wieder als Entwurf oder live bereit
• Verlauf pro Feld: Prüfe genau, welche Felder sich zwischen zwei Versionen geändert haben
• Audit-Trail: Compliance-freundliche Aufzeichnung darüber, wer was wann geändert hat — über deinen gesamten Content-Space hinweg

Die Versionshistorie deines Contents ist so lang wie die Lebensdauer deines Projekts. Wenn du sehen willst, wie deine Startseite sechs Monate vor einem Rebrand aussah, ist sie da.

Ein Content-Branch ist eine isolierte Arbeitskopie deines Content-Spaces. Editorinnen und Editoren arbeiten frei — strukturieren um, entwerfen neue Seiten, testen neue Content-Typen — ohne Gefahr, die Live-Site zu stören.

So funktionieren Branches in b10cks:

• Einen Branch erstellen aus jedem beliebigen Punkt deiner Content-Historie — vom aktuellen Live-Stand, von einem Tag oder von einem anderen Branch aus
• Unabhängig bearbeiten: Änderungen in einem Branch beeinflussen keinen anderen Branch und auch nicht den Haupt-Space
• Zusammenführen, wenn bereit: Führe Änderungen aus dem Branch zurück in den Haupt-Space ein — mit Konflikterkennung und feldgenauer Merge-Auflösung
• Sicher löschen: Branches, die doch nicht funktioniert haben, kannst du folgenlos verwerfen

Das ist der Workflow, mit dem ein Entwickler das Content-Modell einer Website in Staging neu aufbauen kann, während das Redaktionsteam weiter in Production veröffentlicht. Keine Sperren. Kein „Bitte fasst diese Woche das CMS nicht an.“

Nicht jede Version ist gleich. Manche stehen für einen Meilenstein — einen Produktlaunch, eine saisonale Kampagne, einen Snapshot vor einem Redesign, einen freigegebenen Copy-Review.

Versionstags erlauben es dir, jede Version beliebiger Inhalte mit einem aussagekräftigen Namen zu markieren:

• v2.-launch · black-friday-2025 · pre-rebrand-snapshot · legal-approved-Q1
• Tags sind in deiner Versionshistorie such- und filterbar
• Stelle jederzeit aus einem Tag wieder her oder erstelle daraus einen Branch — ohne dich durch Zeitstempel zu wühlen
• Nutze Tags als stabile Bezugspunkte bei Übergaben zwischen Teams

Wenn der CEO fragt: „Was genau war am Launch-Tag live?“ — hast du sofort die Antwort.

Ein Release in b10cks ist eine benannte Sammlung von Content-Änderungen — über mehrere Einträge, Blocktypen und Sprachversionen hinweg — die gemeinsam vorbereitet und als ein einzelnes, abgestimmtes Ereignis veröffentlicht werden.

• Änderungen bündeln: Packe ein Homepage-Update, eine Überarbeitung der Produktseite und einen neuen Blogbeitrag in ein Release
• Release vorab ansehen bevor es live geht — sieh den gesamten Satz an Änderungen so, wie dein Publikum ihn sehen wird
• Zeitlich planen: Lege eine Go-live-Uhrzeit fest und lehne dich zurück; b10cks veröffentlicht alles im Release atomar

So sieht ein Launch einer Kampagne aus, wenn dein CMS ihn wirklich unterstützt.

Jede Version in der b10cks-Historie kann veröffentlicht werden — nicht nur der aktuelle Entwurf. Wenn du eine Live-Seite auf einen früheren Stand zurücksetzen musst, brauchst du nichts manuell rückgängig zu machen oder aus einem Backup einzufügen. Du wählst einfach die gewünschte Version aus und sie geht live.

• Sofortiges Rollback: Stelle eine frühere Version mit einer einzigen Aktion auf veröffentlicht um
• Selektives Rollback: Setze einen einzelnen Eintrag zurück, ohne sonst etwas auf der Website anzutasten
• Kontrolle pro Sprache: Rolle Inhalte einer bestimmten Sprache unabhängig zurück; deine anderen Sprachversionen bleiben unbeeinflusst
• Aus einem Branch veröffentlichen: Führe einen Branch zusammen und veröffentliche seinen Stand, ohne über die Haupt-Arbeitskopie zu gehen

Kein Prozess zum „Wiederherstellen aus dem Backup“. Kein Entwickler nötig. Wähle einfach die Version, die live sein soll, und veröffentliche sie.

Live-Vorschau jeder Version Richte deine Frontend-Preview-URL auf jede historische Version, jeden Tag oder Branch aus — nicht nur auf den aktuellen Entwurf. Sieh genau, wie ein früherer Content-Stand in deiner echten Website und im echten Layout gerendert wurde, bevor du entscheidest, ob du ihn wiederherstellst oder verwerfst. Funktioniert mit jedem Frontend-Framework über die b10cks Preview-Token-API.

Side-by-Side-Diff Wähle zwei beliebige Versionen eines Eintrags aus und erhalte einen Diff auf Feldebene — was hinzugefügt, geändert oder entfernt wurde. Klar und lesbar dargestellt: kein rohes JSON, keine Wand aus roten und grünen Zeilen.

• Entwurf mit veröffentlicht vergleichen
• Einen Branch mit dem Main vergleichen
• Zwei beliebige Versionen aus der Historie vergleichen
• Ein einzelnes Feld oder den gesamten Eintrag diffen

Wenn jemand aus dem Team fragt: „Was hat sich seit letztem Dienstag geändert?“ hast du die exakte Antwort in drei Klicks.

Für Entwickler
Branch das Content-Modell selbst — nicht nur einzelne Einträge. Teste neue Blocktypen und Schema-Änderungen in einem isolierten Branch, bevor du sie in deinen Live-Space überführst. Schema-Branches sind sofort in der API sichtbar, sodass dein Frontend-Branch parallel gegen die neue Content-Struktur entwickeln kann.

Für Content-Teams
Saisonale Kampagnen, A/B-Copy-Tests und Website-Relaunches profitieren alle von Branches. Isoliert entwerfen, im Kontext prüfen, nach Freigabe zusammenführen. Keine E-Mail-Ketten mehr mit „bitte bis zum Launch nichts veröffentlichen“.

Für Agenturen
Erstelle pro Kunden-Deliverable einen Branch. Baue und prüfe alles isoliert. Führe es nach Freigabe in den Main-Branch zusammen. Die laufende Arbeit jedes Kunden bleibt für die Produktion unsichtbar, bis sie bereit ist.