Git dla pisarzy – jak przestać gubić własną książkę (czyli dlaczego mój świat SF żyje na GitHubie)

## Wstęp: plik „final_final_poprawiony3.docx”
Jeśli piszesz dłużej niż kilka miesięcy, prawdopodobnie znasz ten stan. W katalogu projektu zaczynają mnożyć się pliki o coraz bardziej desperackich nazwach: „rozdział1_poprawiony”, „rozdział1_final”, „rozdział1_final2”, „rozdział1_ostateczny”, „rozdział1_ostateczny_serio”. Obok leży osobny plik z notatkami, osobny z kanonem świata, jeszcze inny z poprawkami od redaktora. Do tego dochodzą wersje wygenerowane przez modele LLM, kolejne alternatywy dialogów, scen i opisów.
W pewnym momencie pojawia się pytanie, które brzmi niewinnie, ale potrafi sparaliżować pracę: *która wersja jest tą właściwą?* A czasem jeszcze gorsze: *dlaczego bohater w rozdziale drugim ma inne imię niż w czwartym?*
Ten tekst jest o tym, dlaczego narzędzie stworzone dla programistów – git – rozwiązuje dokładnie ten problem. I dlaczego od pewnego czasu używam go nie tylko do kodu, ale do pisania powieści i budowania świata science fiction.
—
## Czym git jest naprawdę
Git nie jest w swojej istocie „narzędziem do kodu”. Kod to tylko jeden z rodzajów tekstu, jaki można w nim przechowywać. W praktyce git jest systemem pamięci decyzji. Zapamiętuje nie tylko aktualny stan projektu, ale również całą drogę, którą do niego przeszliśmy: każdą zmianę, każdy powrót, każdy eksperyment, który okazał się ślepą uliczką.
Daje możliwość cofania czasu, porównywania wersji, sprawdzania kto i kiedy zmienił dany fragment, oraz prowadzenia kilku wariantów tej samej rzeczywistości równolegle. To dokładnie te same operacje, które wykonuje pisarz, tylko zwykle robi je ręcznie, chaotycznie i z dużym stresem.
Programiści byli po prostu pierwszą grupą, która potrzebowała takiego narzędzia na masową skalę.
—
## Problem pisarza w epoce LLM
Modele językowe zwielokrotniły tempo pracy twórczej. W ciągu jednego wieczoru można wygenerować pięć wersji tej samej sceny, trzy alternatywne biografie bohatera i dwie koncepcje technologii, która zmienia zasady świata przedstawionego. Kreatywnie to raj. Organizacyjnie – potencjalna katastrofa.
Bez systemu wersjonowania bardzo łatwo stracić spójność świata, nadpisać dobry fragment gorszym albo – co zdarza się częściej – bać się większych zmian tylko dlatego, że „wszystko się rozjedzie”. Git działa w przeciwną stronę. Zachęca do eksperymentów, bo każdą decyzję można cofnąć. Każdą gałąź fabularną można porzucić bez niszczenia reszty projektu.
—
## Jak wygląda pisanie z gitem w praktyce
### Repozytorium jako świat
Projekt zaczynam od stworzenia repozytorium, które nie jest po prostu folderem z rozdziałami, ale mapą całego uniwersum. Osobne katalogi trzymają opisy postaci, biologii obcych gatunków, technologii, osi czasu, lokacji i same rozdziały powieści. Wszystko zapisane w zwykłych plikach tekstowych, najczęściej w Markdownie.
Repozytorium staje się jedynym źródłem prawdy o świecie. Edytor tekstu, model LLM, notatnik czy kartka papieru są tylko narzędziami wejścia i wyjścia. Kanon żyje w gicie.
### Commit jako decyzja twórcza
Zwykłe „zapisz plik” zostaje zastąpione świadomym aktem: „zatwierdzam zmianę”. Commit nie jest wtedy techniczną czynnością, ale zapisem decyzji fabularnej lub światotwórczej. Może opisywać zmianę modelu biologii obcego gatunku, przebudowę relacji między dwojgiem bohaterów albo przesunięcie wydarzeń na osi czasu.
Po kilku miesiącach historia commitów staje się dziennikiem rozwoju świata – zapisem tego, jak zmieniały się pomysły i dlaczego.
### Branch jako alternatywna rzeczywistość
Kiedy chcę sprawdzić inną wersję fabuły albo radykalnie zmienić jakieś założenie, nie niszczę głównej linii projektu. Tworzę nową gałąź – osobny wariant rzeczywistości. Mogę w niej uśmiercić kluczową postać, zmienić prawa fizyki albo wprowadzić inną genezę choroby, która napędza fabułę.
Jeśli eksperyment okaże się ślepą uliczką, gałąź można porzucić. Jeśli okaże się lepsza – połączyć z główną wersją świata. To bardzo dosłowne urzeczywistnienie idei wielu światów w literaturze.
### Diff jako lupa pisarza
Git potrafi pokazać różnice między wersjami tekstu zdanie po zdaniu. Dzięki temu widać nie tylko *że* coś się zmieniło, ale *jak*. Czy narracja stała się bardziej techniczna? Czy dialog stracił napięcie? Czy opis został skrócony za bardzo? To narzędzie redakcyjne o precyzji, której nie daje żaden klasyczny edytor tekstu.
### Rollback jako źródło odwagi
Największa zmiana jest psychologiczna. Kiedy wiesz, że możesz w każdej chwili wrócić do dowolnego momentu w historii projektu, przestajesz bać się zepsucia tekstu. Ta świadomość radykalnie zwiększa odwagę w eksperymentowaniu i pozwala podejmować ryzykowne decyzje fabularne bez paraliżu.
—
## Git i LLM: stabilny układ
Modele językowe zmieniają się co kilka miesięcy. Zmieniają się ich możliwości, styl, ograniczenia i polityki bezpieczeństwa. To wszystko jest niestabilne.
Repozytorium nie jest. Jest Twoje, lokalne, pod Twoją kontrolą. Model może wygenerować scenę, ale to Ty decydujesz, czy trafi ona do kanonu świata. Git zapisuje ją w historii projektu. Model zniknie, subskrypcja się skończy, a świat pozostanie.
—
## Dlaczego pisarze rzadko używają gita
W środowisku literackim git wciąż kojarzy się z terminalem, programowaniem i techniczną barierą wejścia. Przez dekady przyzwyczLLMliśmy się do modelu pracy opartego na plikach Worda i ręcznym wersjonowaniu nazwami plików. Mało kto uczy pisarzy myślenia o tekście jak o systemie, który ewoluuje i wymaga kontroli zmian.
Tymczasem przy długich cyklach, rozbudowanym lore, współautorach i intensywnym użyciu LLM brak takiego systemu szybko staje się źródłem frustracji.
—
## Minimalny próg wejścia
Nie trzeba znać linii poleceń ani rozumieć wewnętrznej magii gita. Wystarczy graficzny klient, podstawowe pojęcia commitów i gałęzi oraz decyzja, by pisać w zwykłych plikach tekstowych zamiast zamkniętych formatach.
Kilka godzin nauki zamienia się w lata spokojniejszej pracy.
—
## Pisarz jako inżynier świata
Świat przedstawiony jest systemem. Ma zależności, historię zmian, poprawki, błędy i wersje. Traktowanie go w ten sposób nie odbiera literaturze magii. Chroni ją przed chaosem.
Git okazuje się w tym kontekście narzędziem zaskakująco naturalnym.
—
—
## Bardziej technicznie: jak to naprawdę wygląda w repozytorium
Poniżej przykład struktury repozytorium, która dobrze sprawdza się przy długich formach, worldbuildingu i pracy z LLM:
„`
project-root/
├─ README.md
├─ canon/
│ ├─ axioms.md
│ ├─ timeline.md
│ ├─ technology.md
│ ├─ biology.md
│ └─ culture.md
├─ characters/
│ ├─ maura.md
│ ├─ veylin.md
│ └─ secondary/
├─ locations/
│ ├─ Aetheria.md
│ ├─ Dragtelia.md
│ ├─ Eneria.md
│ ├─ veridia.md
│ └─ stations/
├─ plot/
│ ├─ arcs.md
│ ├─ open_threads.md
│ └─ discarded_arcs.md
├─ chapters/
│ ├─ draft/
│ ├─ revised/
│ └─ published/
├─ research/
│ ├─ medicine.md
│ ├─ physics.md
│ └─ sociology.md
├─ LLM/
│ ├─ prompts/
│ ├─ generated/
│ └─ rejected/
└─ notes/
„`
Takie rozdzielenie powoduje, że świat nie „rozpływa się” w rozdziałach. Fabuła staje się jedną z warstw systemu, a nie jedynym nośnikiem informacji.
—
## Commit messages jako dokumentacja projektowa
W praktyce commit message staje się krótkim raportem projektowym. Przykłady z życia:
„`
Add Enqual progression scale (v1)
„`
„`
Refactor Veridian neuroanatomy – introduce tri-brain asynchrony
„`
„`
Rewrite chapter 7 to match new timeline constraints
„`
Po roku masz pełną historię ewolucji świata – nie w głowie, nie w mLLMlach, ale w systemie, który da się przeszukiwać i analizować.
—
## Branching jako narzędzie twórcze
Typowe strategie:
– `Mainn` – kanon
– `experiment/*` – krótkie eksperymenty
– `alt/*` – pełnoprawne alternatywne wersje świata
– `rewrite/*` – duże przebudowy fabuły
Przykłady:
„`
alt/no-telekinesis
rewrite/act2
experiment/new-ending
„`
To pozwala prowadzić kilka wariantów książki równolegle bez rozbijania projektu.
—
## Praca z LLM w repozytorium
Dobry wzorzec:
1. LLM generuje tekst.
2. Trafia on do katalogu `LLM/generated/`.
3. Autor ręcznie wybiera fragmenty.
4. Przenosi je do właściwych plików.
5. Robi commit z opisem decyzji.
W ten sposób repozytorium pozostaje kuracją twórczą, a nie wysypiskiem losowych generacji.
## Współautorzy i praca z wydawcą
Git rozwiązuje też problem, który w klasycznym workflow jest koszmarem: współpracę wielu osób na jednym tekście.
### Współautorzy
Każda osoba pracuje na własnej gałęzi:
„`
coauthor/alex-dialogues
coauthor/anna-worldbuilding
„`
Zmiany są łączone do głównej wersji przez `merge` lub `pull request`, co oznacza:
– pełną kontrolę nad tym, co wchodzi do kanonu,
– możliwość dyskusji nad konkretnymi fragmentami,
– historię autorstwa zmian,
– cofanie błędnych decyzji.
To dokładnie ten sam model, który działa w dużych projektach open‑source – tylko że zamiast kodu mamy literaturę.
—
### Redakcja i wydawca jako osobna gałąź
Bardzo praktyczny wzorzec:
„`
publisher/editing-round-1
publisher/proofreading
„`
Redaktor wprowadza poprawki w swojej gałęzi.
Autor:
– widzi dokładnie każdą zmianę (diff),
– może ją zaakceptować lub odrzucić fragmentami,
– nie traci własnej wersji roboczej.
To eliminuje klasyczne „tu jest nowy plik z poprawkami, porównaj ręcznie”.
—
### Ślad decyzyjny
Każda decyzja redakcyjna ma swój commit:
„`
Simplify medical terminology in chapter 5
„`
Po latach wiadomo:
– kto zmienił dany fragment,
– dlaczego,
– w jakim kontekście.
Dla literatury to rzecz niemal rewolucyjna.

—

## Git w terminalu vs narzędzia GUI
### CLI (terminal)
Zalety:
– pełna kontrola nad każdym aspektem repozytorium,
– dostęp do wszystkich opcji gita,
– szybkość przy dużych projektach,
– łatwe skrypty i automatyzacja,
– brak „magii w tle”.
Typowy zestaw poleceń pisarza:
„`
git status
git diff
git add
git commit
git branch
git checkout
git log
„`
Po kilku tygodniach wchodzą w pamięć mięśniową.
### GUI (GitHub Desktop, GitKraken, SourceTree)
Zalety:
– niski próg wejścia,
– wizualne drzewo commitów i branchy,
– łatwe rozwiązywanie konfliktów,
– brak strachu przed terminalem.
Wady:
– część operacji jest uproszczona albo ukryta,
– trudniej zrozumieć, co naprawdę się dzieje,
– mniej kontroli przy skomplikowanych merge’ach.
### W praktyce
Wiele osób zaczyna od GUI, a z czasem przechodzi do CLI. Nie dlatego, że musi, ale dlatego, że przy dużych światach i dziesiątkach branchy terminal staje się po prostu wygodniejszy i bardziej precyzyjny.
—
## Format plików ma znaczenie
Najlepiej sprawdzają się:
– Markdown (`.md`)
– zwykły tekst (`.txt`)
Unikałabym:
– `.docx`
– zamkniętych formatów binarnych
Git działa na różnicach w tekście. Im prostszy format, tym lepszy diff i historia zmian.
—
## Automatyzacja (opcjonalnie)
Dla bardziej technicznych:
– hooki gita do walidacji spójności nazw postaci,
– skrypty sprawdzające niespójności osi czasu,
– automatyczne generowanie indeksów świata,
– eksport do PDF/EPUB z repozytorium.
To już poziom „pisarz-inżynier”, ale jest zaskakująco osiągalny.
—
## Przykłady prostych skryptów dla pisarza
Poniżej kilka przykładów automatyzacji, które realnie pomagają przy większym świecie przedstawionym. To nie są narzędzia „dla programistów”, tylko małe zabezpieczenia przed chaosem.
### Sprawdzanie spójności imion postaci
Przykład w Pythonie (skan wszystkich plików i wypisanie nieznanych imion):
„`python
import re
from pathlib import Path
characters = set()
for p in Path(„characters”).glob(„*.md”):
characters.add(p.stem.lower())
unknown = set()
for p in Path(„chapters”).rglob(„*.md”):
text = p.read_text(encoding=”utf-8″)
for word in re.findall(r”[A-Z][a-z]+”, text):
if word.lower() not in characters:
unknown.add(word)
print(„Potentially unknown names:”)
for name in sorted(unknown):
print(name)
„`
Efekt: szybkie wychwycenie literówek i przypadkowych zmian imion bohaterów.
—
### Kontrola osi czasu
Prosty format osi czasu w `canon/timeline.md`:
„`
2204-03-14 | birth of Maura
2231-07-02 | first Enqual symptoms
„`
Skrypt sprawdzający, czy wydarzenia w rozdziałach nie wykraczają poza znane daty:
„`python
# szkic ideowy
# 1. wczytaj timeline
# 2. znajdź wszystkie daty w rozdziałach
# 3. porównaj zakres
# 4. zgłoś rozjazdy

from pathlib import Path
import re
from datetime import datetime

TIMELINE_FILE = Path(„canon/timeline.md”)
CHAPTERS_DIR = Path(„chapters”)

DATE_RE = re.compile(r”(\d{4})-(\d{2})-(\d{2})”)

def parse_timeline(path: Path):
dates = []

for line in path.read_text(encoding=”utf-8″).splitlines():
m = DATE_RE.search(line)
if m:
dates.append(datetime(int(m[1]), int(m[2]), int(m[3])))

if not dates:
raise RuntimeError(„No dates found in canon/timeline.md”)

return min(dates), max(dates)

def scan_chapters(base: Path):
found = []

for file in base.rglob(„*.md”):
text = file.read_text(encoding=”utf-8″)

for m in DATE_RE.finditer(text):
d = datetime(int(m[1]), int(m[2]), int(m[3]))
found.append((file, d))

return found

def main():
min_date, max_date = parse_timeline(TIMELINE_FILE)
chapter_dates = scan_chapters(CHAPTERS_DIR)

print(f”Timeline range: {min_date.date()} → {max_date.date()}\n”)

problems = 0

for file, d in chapter_dates:
if d < min_date or d > max_date:
print(f”[!] {file}: {d.date()} outside timeline”)
problems += 1

if problems == 0:
print(„✓ No timeline conflicts found”)
else:
print(f”\nFound {problems} potential timeline conflicts”)

if __name__ == „__main__”:
main()

To wystarcza, by uniknąć klasycznego błędu „bohater jest w dwóch miejscach naraz”.
—
### Automatyczne generowanie indeksu świata
Skrypt, który buduje plik `WORLD_INDEX.md`:
– listę postaci
– listę technologii
– listę lokacji
– skróty do plików źródłowych

from pathlib import Path

OUTPUT = Path(„WORLD_INDEX.md”)

CHARACTERS_DIR = Path(„characters”)
LOCATIONS_DIR = Path(„locations”)

CANON_FILES = {
„Technologie”: Path(„canon/technology.md”),
„Biologia”: Path(„canon/biology.md”),
„Kultura”: Path(„canon/culture.md”),
}

def collect_md_files(base: Path):
if not base.exists():
return []
return sorted(base.rglob(„*.md”))

def md_link(path: Path):
name = path.stem.replace(„_”, ” „).title()
return f”- [{name}]({path.as_posix()})”

def section_from_directory(title: str, base: Path):
lines = [f”## {title}”]
files = collect_md_files(base)

if files:
for f in files:
lines.append(md_link(f))
else:
lines.append(„*(brak)*”)

lines.append(„”)
return lines

def section_from_file(title: str, path: Path):
lines = [f”## {title}”]

if path.exists():
lines.append(f”- [Opis]({path.as_posix()})”)
else:
lines.append(„*(brak)*”)

lines.append(„”)
return lines

def main():
lines = [„# Indeks świata”, „”]

lines += section_from_directory(„Postacie”, CHARACTERS_DIR)
lines += section_from_directory(„Lokacje”, LOCATIONS_DIR)

for title, path in CANON_FILES.items():
lines += section_from_file(title, path)

OUTPUT.write_text(„\n”.join(lines), encoding=”utf-8″)
print(„✓ WORLD_INDEX.md generated”)

if __name__ == „__main__”:
main()

Dzięki temu repozytorium staje się nawigowalne jak dokumentacja techniczna.
—
### Eksport książki z repozytorium
Typowy pipeline:
„`
chapters/*.md -> pandoc -> book.pdf / book.epub
„`
Jedno polecenie może wygenerować wersję do wysłania wydawcy, bez ręcznego składania dokumentów.
—
—
## Podsumowanie
Git daje pisarzowi:
– kontrolę nad historią świata,
– możliwość bezpiecznych eksperymentów,
– odporność na chaos generowany przez LLM,
– skalowalność projektów wieloletnich,
– realne wsparcie pracy zespołowej,
– automatyzację nudnych, podatnych na błędy czynności.
To nie jest gadżet.
To infrastruktura twórcza.
Nie twierdzę, że każdy pisarz musi korzystać z gita. Ale jeśli pracujesz nad długą formą, budujesz złożony świat, używasz LLM i masz dość bałaganu wersji, to jest to jedno z najbardziej niedocenionych narzędzi twórczych XXI wieku.
Ja do plików w stylu „final_final_v7.docx” już nie wrócę.
I nie tęsknię ani trochę.
—
*Jeśli chcesz, potraktuj ten tekst jako zaproszenie do eksperymentu: jedno repozytorium, jeden świat, pełna historia zmian. Reszta to już tylko pisanie.*