Ten sam Git, który nie nadaje się do pliku Maya, jest dokładnie tym, czego potrzeba do kodu narzędzi, które ten plik Maya otwierają.
Rozdział 5 poświęciliśmy na wyjaśnienie, dlaczego Git nie nadaje się do plików, z którymi pracują artyści. To nie oznacza, że Git jest w VFX niepotrzebny — wręcz przeciwnie. Każde narzędzie, o którym pisaliśmy w poprzednich rozdziałach — skrypt publikujący z Rozdziału 7, integracja z systemem śledzenia z Rozdziału 8 — samo jest napisane w kodzie, a kod to czysty tekst. Dokładnie ten przypadek, do którego Git został zaprojektowany.
„Kod pipeline'u" brzmi abstrakcyjnie, ale w praktyce to konkretny, rosnący zbiór plików: skrypty publikujące i loadery z Rozdziału 7, wtyczki dodające menu i przyciski do Mayi, Houdiniego i Nuke, integracje z API systemu śledzenia z Rozdziału 8, pliki konfiguracyjne opisujące konwencje nazewnictwa z Rozdziału 4. Wszystko to żyje w repozytorium Git, dokładnie tak jak kod dowolnej innej aplikacji — z tą różnicą, że jego „użytkownikami" nie są klienci zewnętrzni, tylko artyści w tym samym budynku, którzy klikają przycisk „Publish" kilkadziesiąt razy dziennie.
Zespół pipeline'owy bywa w studiu zaskakująco mały — czasem to dwie, trzy osoby obsługujące narzędzia dla stu kilkudziesięciu artystów. Można by pomyśleć, że przy tak małej skali formalności w rodzaju branchy czy code review to zbędny ceremoniał, właściwy dużym zespołom open source'owym. Jest odwrotnie: to właśnie mała skala zespołu przy ogromnej skali „klientów" podnosi stawkę błędu. Literówka w skrypcie publikującym, wypchnięta bezpośrednio na branch, z którego korzystają wszystkie stacje robocze, potrafi zablokować cały dział lightingu w środku dnia zdjęciowego — nie ma nikogo, kto po cichu naprawi to lokalnie, jak zrobiłby to jeden zirytowany programista. Dlatego zmiany w kodzie pipeline'u niemal zawsze przechodzą przez osobny branch, a przed połączeniem z główną gałęzią — przez code review drugiej osoby, nawet jeśli ten zespół liczy tylko dwie osoby w sumie.
Studio pracujące równolegle nad kilkoma produkcjami staje przed problemem, którego mały projekt open source rzadko doświadcza: show A jest tydzień przed oddaniem materiału i absolutnie nie może pozwolić sobie na żadną niespodziankę w narzędziach, podczas gdy show B dopiero się rozkręca i chętnie skorzystałby z nowej funkcji, którą zespół pipeline'owy właśnie skończył. Rozwiązaniem jest tag — nazwana, zamrożona wersja kodu, do której konkretny show jest „przypięty" (Rozdział 17 pokaże mechanizm, który to fizycznie egzekwuje). Zespół pipeline'owy może więc mergować nowe funkcje na główną gałąź codziennie, nie ryzykując niczego u showu A, dopóki ten świadomie nie zaktualizuje swojego przypięcia — zwykle dopiero między produkcjami, nie w ich trakcie.
Część IV zmienia temat: jak dane w ogóle wędrują między różnymi programami DCC. Zaczynamy od Alembic — formatu, który zamraża geometrię w czasie tak, żeby dowolna aplikacja mogła ją odczytać bez znajomości tej, w której powstała.