Kontrola wersji dla game dev

Wersjonowanie, które rozumie assety.

Repozytorium gry to setki gigabajtów binariów, których nie da się mergować, i artyści, którzy chcą po prostu wziąć plik i pracować. Git tego nie udźwignie, Perforce potrafi — ale kosztuje i nie wie nic o Twoim kodzie. TouchQuill robi jedno i drugie: na plikach 200 MB commit trwa ułamek sekundy, a lock bierzesz jedną komendą.

15×
szybszy commit binarki 200 MB niż w Gicie
8 ms
commit po zmianie jednego assetu (repo 400 MB)
~10×
mniej miejsca na dysku serwera na commit
BLAKE3
każdy plik weryfikowalny hashem
Dlaczego TouchQuill

Problemy, które znasz z produkcji

Każdy, kto wersjonował grę, zna ten ból: git lfs który ciągle się psuje, dwie osoby edytujące ten sam .uasset, merge który staje na binarce o 17:00 w piątek. TouchQuill powstał, żeby te sytuacje przestały się zdarzać.

Binaria bez bólu

Pliki trafiają do magazynu adresowanego treścią (BLAKE3). Bez kompresji, która dusi Git na binariach, bez osobnego LFS. Duplikaty przechowywane raz, transfer tylko tego, czego brakuje.

Lock z kolejką

Bierzesz plik — jest Twój. Ktoś drugi chce? Staje w kolejce i dostaje go automatycznie, gdy skończysz. Serwer pilnuje locków przy push, więc nie da się ich ominąć „przypadkiem".

Konflikt nie zatrzymuje pracy

Integracja zawsze przechodzi. Konflikt zostaje zapisany jako osobny obiekt: można go przypisać koledze, odłożyć na jutro albo rozwiązać pluginem. Zespół pracuje dalej.

Historia funkcji, nie plików

Lens śledzi konkretny symbol — funkcję, klasę — przez zmiany nazw plików i refaktoringi. Pytasz „kto ruszał calculate_damage" i dostajesz odpowiedź, nawet jeśli plik trzy razy zmienił nazwę.

Zmiana ma stały adres

Change ID (ch-…) nie zmienia się przy amend ani rebase. Review, locki i powiadomienia trzymają się zmiany — a nie hasha, który jutro będzie inny.

Audyt, któremu można ufać

Dziennik zdarzeń administracyjnych spięty hash-chainem i podpisany Ed25519, z kotwicami wysyłanymi poza serwer. Manipulację widać — także taką, którą próbowałby zrobić admin.

Wydajność

Zmierzyliśmy to samo w trzech systemach

Identyczne dane i operacje, mediana z pięciu prób, Perforce na żywym p4d Helix Core. Metodyka i pełne wyniki są na osobnej stronie — skrypt do powtórzenia pomiarów leży w repo.

TouchQuill Git Perforce
Jak to wygląda w praktyce

Kilka komend i jedziesz

Jedna binarka klienta na Linux, Windows i macOS. Serwer stawia się w kwadrans.

# start — lokalnie, bez żadnej konfiguracji
tq init MojaGra
tq commit -m "pierwszy miecz"

# dołącz do zespołu
tq remote https://vcs.studio.com
tq login tqt_...
tq push

# weź binarkę na wyłączność
tq lock Content/Weapons/sword.uasset
✓ Lock zajęty. Marta jest #2 w kolejce.

# kto ruszał tę funkcję?
tq lens blame --symbol calculate_damage

Channele zamiast branchy

Task na zadanie, release na wydanie, personal na eksperymenty. Wirtualny channel pokaże artystom same assety, bez kodu. Zasady — kto pushuje, co wymaga locka — trzymasz w pliku tq-channel.toml, który podlega review jak każda inna zmiana.

Skala nie boli

Drzewo hierarchiczne sprawia, że serwer rośnie z liczbą zmian, a nie z rozmiarem repo razy liczba commitów. Indeks worktree i demon fsmonitor (Linux i Windows) utrzymują status oraz commit szybkie także przy stu tysiącach plików.

Wypróbuj na własnym repo

Przewodnik startowy, typowe workflow zespołowe i referencja komend — wszystko w dokumentacji.