Versiegeschiedenis is het overzicht van wat een tekst vroeger was. Programmeurs vertrouwen er al tientallen jaren op; de meeste romanschrijvers werken nog zonder, of met een map vol bestanden die hoofdstuk-7-definitief, hoofdstuk-7-definitief-v2 en hoofdstuk-7-ECHT-definitief heten. Zo'n map is een poging om het juiste idee te verwezenlijken. Een boek verandert vele malen van vorm op weg naar de voltooiing, en een schrijver die eerdere vormen kan zien en erheen kan terugkeren, herziet gedurfder en nauwkeuriger dan een schrijver die dat niet kan. Deze gids behandelt waarom dat zo is, hoe je in de praktijk met checkpoints werkt en waar vertakkende ideeën passen.
Waarom een roman een geheugen van zichzelf nodig heeft
Een kort verhaal kan in je hoofd leven. Een roman niet. Ergens rond het tweede bedrijf wordt een boek te groot om in één keer te overzien, en vanaf dat moment is elke herziening deels blind: je verandert een scène in hoofdstuk veertien zonder op datzelfde moment te kunnen zien wat hoofdstuk zes erover beloofde.
Versiegeschiedenis geeft het boek een geheugen buiten jezelf. Je kunt er vragen mee beantwoorden die anders van herinnering afhangen. Wat stond er in dit hoofdstuk voordat ik de onthulling verplaatste? Wanneer hield de mentor op de verrader te zijn? In welke versie van de opening stond de zin waar mijn schrijfpartner zo van hield? Zonder overzicht zijn dat antwoorden die je moet raden, en gissingen over je eigen boek blijken verrassend vaak onjuist.
Het geheugen is het belangrijkst voor de delen van een roman die zich uitstrekken. Een wijziging in het motief van één personage kan doorwerken in twintig hoofdstukken. Kunnen terugkijken naar het boek zoals het voor die wijziging was, is de manier om te controleren of die doorwerking terechtkwam waar je haar wilde hebben, en om de continuïteit niet te laten wegglijden naarmate het manuscript groeit.
De angst die grote herzieningen tegenhoudt
Het duurste wat een ontbrekende geschiedenis je kost, is lef. De meeste schrijvers kennen het gevoel: je kijkt naar een structureel probleem - het middelpunt komt te laat, een bijplot is dood gewicht, het boek zou een hoofdstuk eerder moeten beginnen - en je besluit het niet op te lossen, omdat de oplossing betekent dat je hoofdstukken moet slopen die al werken, en als de ingreep mislukt, is er geen weg terug.
Zo krimpt de herziening tot iets veiligs. De zinnen worden gepolijst terwijl de structuur blijft zoals ze is. Veel boeken die bijna goed aanvoelen, zitten precies daar vast.
Een checkpoint verandert de rekensom. Als de huidige staat van het boek is opgeslagen en gedateerd, is de grote ingreep geen gok meer. Je kunt de bijplot schrappen, de onthulling verplaatsen, twee personages samenvoegen en het resultaat eerlijk lezen, wetend dat de eerdere versie er nog is om mee te vergelijken en om stukken uit terug te halen. Een schrijver met een betrouwbare geschiedenis kan het zich veroorloven meer te proberen, en in dat proberen worden structurele problemen opgelost.
Checkpoints op de momenten die ertoe doen
Een checkpoint is een bewuste opslag: een benoemde, gedateerde momentopname van het boek of van de hoofdstukken die je hebt aangepast, gemaakt op een moment dat je zelf kiest. Automatische geschiedenis die elke toetsaanslag vastlegt heeft zijn nut, maar checkpoints zijn waar je daadwerkelijk op navigeert, omdat elk ervan een staat markeert die je bewust wilde bewaren.
De momenten die een checkpoint verdienen, zijn die vóór een beslissing waar je spijt van kunt krijgen:
- Vóór een structurele wijziging. Hoofdstukken verplaatsen, samenvoegen of schrappen, de volgorde van gebeurtenissen veranderen, het einde herschrijven.
- Vóór je het manuscript aan iemand geeft. Een proeflezer, een redacteur of een schrijfgroep reageert op een specifieke versie, en je wilt precies kunnen zien wat zij lazen wanneer hun aantekeningen binnenkomen.
- Aan het einde van een versie. Een volledige ronde afronden is een mijlpaal; door die op te slaan krijg je een vast punt om de volgende ronde aan af te meten.
- Vóór je een hulpmiddel tekst laat herschrijven. Elke keer dat software, een redacteur of een AI op het punt staat in bulk tekst te wijzigen.
Geef elk checkpoint een naam naar wat er gaat gebeuren, niet naar de datum, want die houdt het overzicht toch al bij. 'Vóór het schrappen van de Lissabon-bijplot' zegt je over drie maanden nog iets. 'Zaterdag' niet.
Lezen wat een hoofdstuk vroeger was
Het tweede gebruik van versiegeschiedenis is stiller en in het dagelijks werk gebruikelijker: terugkeren om te lezen.
Herziening kost altijd iets. Een hoofdstuk dat viermaal is herschreven, kan het ene beeld verliezen dat de eerste versie liet werken, of een regel dialoog die iets voorbereidde dat tweehonderd pagina's verderop plaatsvindt. De eerdere versie naast de huidige openen is de manier om te vinden wat eruit is gevallen. Vaak is het antwoord om een alinea mee te nemen naar de nieuwe versie in plaats van de hele herziening ongedaan te maken.
Het helpt ook bij het plan, niet alleen bij de tekst. Als je een outline maakt - als je hoofdstukken zijn opgebouwd uit verhaalbeats, de kleine eenheden waarin iets gebeurt en iets verandert - dan laat een eerdere versie van een hoofdstuk zien wat het moest doen, en niet alleen hoe het geschreven was. De beats van twee versies naast elkaar leggen vertelt je of een herziening het verhaal veranderde of alleen de zinnen, en dat is nuttig om te weten wanneer een hoofdstuk plotseling anders leest en je niet kunt zeggen waarom.
Waar vertakken past
Vertakken is het volgende idee. In plaats van één lijn van versies laat een vertakking je het boek een andere kant op sturen - de versie waarin de zus de verrader is, de versie die vanuit de tegenstander wordt verteld - en die naast de hoofdversie uitwerken, om daarna te bewaren wat het beste werkt.
Voor een romanschrijver is vertakken het nuttigst bij vragen die te groot zijn om door erover na te denken te beslechten. Je kunt wekenlang met jezelf discussiëren over de vraag of een boek met de moord moet openen of met de ochtend ervoor, of je kunt beide openingen schrijven en ze lezen. Zolang een vertakking niet door je hulpmiddelen wordt geboden, doet een checkpoint plus een kopie grotendeels hetzelfde werk: sla de huidige staat op, probeer het alternatief en vergelijk.
Vertakken vraagt wel om discipline. Elke vertakking is een tweede versie van een deel van je boek, en twee versies van hetzelfde verhaal drijven snel uit elkaar. Houd vertakkingen kort van duur en gericht op één vraag, besluit, en voeg het antwoord weer samen.
Versiegeschiedenis als AI meeschrijft
Schrijven met AI maakt dit alles belangrijker, omdat AI tekst in grotere, snellere halen wijzigt dan een mens. Een assistent kan in seconden een hoofdstuk herschrijven, een reeks scènes herordenen of een personage door het hele boek heen bijwerken, en zo'n brede wijziging is moeilijk te beoordelen zonder te kunnen zien wat er eerder stond.
De gewoonten zijn dezelfde, maar worden vaker toegepast: maak een checkpoint voordat je om een bulkwijziging vraagt, lees de oude en de nieuwe versie naast elkaar en bewaar uit elk de delen die het boek dienen. Een geschiedenis die bijhoudt welke wijzigingen van jou kwamen en welke van de AI is als bijkomend voordeel ook een vastlegging van je eigen auteurschap.
Novelmint bouwt dit in het boek zelf in: je kunt een checkpoint opslaan van de hoofdstukken die je hebt gewijzigd, elke eerdere versie van een hoofdstuk openen om het plan en de tekst te lezen en eruit te kopiëren, en de meest recente ronde wijzigingen van de AI-assistent met één klik ongedaan maken. Een volledig checkpoint in één stap terugzetten en een boek vertakken om een alternatieve plot te verkennen staan op de roadmap. De pagina over versiegeschiedenis legt uit hoe het vandaag werkt. Waarmee je ook schrijft, houd een geschiedenis bij die je kunt vertrouwen, en de grote herzieningen die je boek nodig heeft worden herzieningen die je je kunt veroorloven te proberen.