Artykuł kanoniczny · wersjonowanie narzędzi

Wersjonowanie skryptów Dynamo i Grasshopper. Który plik jest aktualny?

Niestety… nazwy final, final2 i ostateczna_poprawiona nie tworzą historii zmian. Historia pliku pokazuje zapisane zmiany i ich autorów. Numer wersji wskazuje, jak zmiana wpływa na osoby korzystające ze skryptu Dynamo, definicji Grasshoppera albo wtyczki.

Folder _OSTATECZNA_

zestawienia_final.dyn
zestawienia_final2.dyn
zestawienia_STARE_DZIALA.dyn

Który plik zawiera ostatnią poprawkę, kto ją wprowadził i jak wrócić do poprzedniego stanu?

Najpierw ustal, od którego pliku zaczynasz historię

Zrób kopię folderu i porównaj pliki. Przy każdej różnicy zapisz, co się zmieniło i która kopia ją zawiera. Jeżeli potrafisz potwierdzić kolejność zmian, wprowadź kolejne stany do repozytorium. Jeśli nie, rozpocznij historię od ostatniego sprawdzonego pliku. Starsze kopie zachowaj w archiwum z informacją, czego nie udało się ustalić.

Git zapisuje kolejne stany pliku

Rozwiązaniem jest folder, w którym Git zapisuje kolejne zmiany. Taki folder to . Możesz przechowywać go na GitHubie, aby autorzy korzystali z tej samej historii zmian i mieli jej kopię poza jednym komputerem.

Każdy zapis ma autora, datę i opis. Można porównać go z wcześniejszym stanem albo przywrócić starszą wersję. Polskie tłumaczenie Pro Git pokazuje, jak Git zapisuje zmiany w repozytorium.

Dynamo i Grasshopper

Format pliku wpływa na to, jakie szczegóły zmiany zobaczysz

.dyn od wersji 2.0 i .ghx

To pliki tekstowe. Git może wskazać zmienione fragmenty, ale sam zapis różnic nie zawsze jasno pokazuje, co zmieniło się w działaniu skryptu.

.gh

To plik binarny. Git zapisze jego kolejne stany, ale pokaże tylko, że cały plik się zmienił.

Jeżeli chcesz porównywać zmiany, wybierz .ghx jako plik źródłowy. Binarny .gh możesz nadal przygotowywać dla użytkowników, ale nie utrzymuj dwóch niezależnie edytowanych kopii. Zespół McNeel wskazuje porównywanie zmian jako jedno z zastosowań formatu .ghx.

Od wersji 2.0 Dynamo zapisuje pliki .dyn w formacie JSON. Autodesk opisuje zmianę formatu w Dynamo 2.0. Zmiana położenia wielu węzłów może jednak tworzyć duży, mało czytelny diff mimo niewielkiej zmiany logiki.

Numer major.minor.patch opisuje skutek zmiany

Numer w układzie nie zastępuje historii Gita, ale daje użytkownikowi krótką informację, czy zmienił się sposób pracy ze skryptem.

major · 2.0.0

Dotychczasowy sposób użycia przestaje działać, na przykład skrypt wymaga innych danych wejściowych albo zwraca wynik w innym formacie. Zespół musi zmienić sposób pracy.

minor · 1.7.0

Dochodzi nowa funkcja, ale dotychczasowy sposób użycia nadal działa.

patch · 1.6.3

Poprawka usuwa błąd bez zmiany obsługi i oczekiwanego wyniku.

Zasady numerowania opisuje polska wersja Semantic Versioning 2.0.0. Dla skryptu używanego w pracowni trzeba jeszcze zapisać, co użytkownik uznaje za zmianę zgodną z dotychczasowym sposobem pracy.

Tag łączy numer wersji z konkretnym stanem pliku

Po sprawdzeniu skryptu oznaczasz konkretny punkt historii , na przykład v1.6.2. Dzięki temu numer prowadzi do dokładnie tych plików, które przeszły test.

Do tagu możesz dołączyć stronę z opisem zmian i plikami do pobrania. GitHub nazywa ją Release. W małej bibliotece skryptów taki zestaw zwykle wystarcza do udostępniania sprawdzonych wersji.

W repozytorium GitHub możesz dodać workflow GitHub Actions, który po wprowadzeniu zmian do głównej gałęzi uruchamia semantic-release. Narzędzie odczytuje komunikaty commitów zapisane według ustalonej konwencji i na tej podstawie określa, czy zwiększyć numer major, minor czy patch, a następnie tworzy tag i GitHub Release. Dokumentacja semantic-release pokazuje gotową konfigurację dla GitHub Actions. Dzięki temu skrypty są wersjonowane automatycznie, ale poprawny numer nadal zależy od konsekwentnych komunikatów commitów.

Pakiety dla zespołu

Yak wersjonuje pakiet, nie historię definicji Grasshopper

Git zapisuje historię plików źródłowych. zawiera gotową wtyczkę, autorskie komponenty i plik manifest.yml z numerem wersji. Rhino Package Manager może później zainstalować ten pakiet na komputerze użytkownika.

McNeel pokazuje budowanie wersjonowanego pakietu dla wtyczki Grasshopper. To dobry sposób dystrybucji autorskich komponentów, ale nie zamiennik Gita dla kolejnych stanów pliku .gh lub .ghx. Dynamo Package Manager pełni podobną rolę dla pakietów Dynamo.

Jedna wersja wtyczki może mieć osobne pliki dla kilku środowisk uruchomieniowych

Wtyczka 1.6.2 może mieć osobny plik skompilowany dla każdego wspieranego środowiska uruchomieniowego. Taki plik to . Wszystkie buildy mogą należeć do jednej wersji funkcjonalnej, o ile realizują ten sam zakres. Nazwa gotowej paczki powinna wskazywać program, a tag w Git pozostaje wspólny.

NarzędziePlik dla użytkownikaWersja

Dodatek Revitnarzedzie-r24-1.6.2.zip1.6.2 · Revit 2024

Dodatek Revitnarzedzie-r25-1.6.2.zip1.6.2 · Revit 2025

Wtyczka Rhinogeometria-2.3.0-rh8-win.yak2.3.0 · Rhino 8

Praktyczny setup

Po teście zapisz numer wersji w Git i w plikach dla użytkowników

Chodzi o numer major.minor.patch, na przykład 1.6.2. Ten sam numer powinien wskazywać sprawdzony stan repozytorium oraz wszystkie pliki przygotowane z tego stanu dla użytkowników.

Pliki Dynamo i Grasshopper

Pliki trafiają do repozytorium. Po teście tworzysz tag i dołączasz sprawdzony plik do GitHub Release. Package Manager nie jest potrzebny, dopóki nie publikujesz osobnego pakietu z autorskimi węzłami lub komponentami.

Revit

Nice3point/RevitTemplates utrzymuje wiele konfiguracji Revita w jednym projekcie i automatyzuje wersjonowanie na podstawie historii Git. Jedna wersja produktu tworzy osobne buildy dla wskazanych wersji Revita.

Rhino

W folderze z gotową wtyczką .rhp lub .gha zapisujesz plik manifest.yml z nazwą i wersją pakietu:

name: narzedzie-biura
version: 1.6.2
authors:
  - Pracownia
description: Narzędzia do kontroli modelu

Polecenie yak build tworzy wersjonowany pakiet. Tag dystrybucji, na przykład rh8-win, wskazuje zgodną wersję Rhino i system. Jeden numer pakietu może mieć kilka wariantów dla różnych wersji Rhino.

Minimalny proces

Jedna sprawdzona wersja wskazuje jeden stan repozytorium

1. Zapisuj pliki skryptu i kod w jednym repozytorium Git.
2. Opisuj każdą zmianę krótko i konkretnie.
3. Po teście nadaj numer major.minor.patch i tag wskazujący sprawdzony stan.
4. Udostępnij zespołowi ten stan przez GitHub Release, folder sprawdzonych skryptów albo wersjonowany pakiet.

Większość tych czynności może wykonać agent AI pracujący w repozytorium, na przykład Codex albo Claude Code. Możesz też użyć aplikacji desktopowej, jeśli ma dostęp do plików projektu i Gita. Agent przygotuje opisy zmian, tag i paczkę, ale to autor narzędzia decyduje, który stan przeszedł test.

Numer wersji opisuje zmianę skryptu. Zgodność z konkretną wersją Revita lub Rhino wymaga osobnego zapisu i testu.