Na forum 4programmers.net korzystamy z plików cookies. Część z nich jest niezbędna do funkcjonowania
naszego forum, natomiast wykorzystanie pozostałych zależy od Twojej dobrowolnej zgody, którą możesz
wyrazić poniżej. Klikając „Zaakceptuj Wszystkie” zgadzasz się na wykorzystywanie przez nas plików cookies
analitycznych oraz reklamowych, jeżeli nie chcesz udzielić nam swojej zgody kliknij „Tylko niezbędne”.
Możesz także wyrazić swoją zgodę odrębnie dla plików cookies analitycznych lub reklamowych. W tym celu
ustaw odpowiednio pola wyboru i kliknij „Zaakceptuj Zaznaczone”. Więcej informacji o technologii cookie
znajduje się w naszej polityce prywatności.
Pracuje na codzień z kodem repozytoriach git. Ostatnio bawię się trochę grafiką. Szukam informacji jak się sprawuje git do wersjonowania projektów graficznych. Macie jakieś doświadczenie z tym?
Zastanawiam się jak będzie z rozmiarem repozytorium i szybkością działania repozytorium lokalnego, czy są jakieś triki, żeby czyścić stare commity?
Szukam informacji jak się sprawuje git do wersjonowania projektów graficznych.
Zwróć uwagę nie na to jakiego typu pliki chcesz wrzucić do repozytorium, a na to, jakie korzyści będziesz z tego mieć. A korzyści są bardzo przyjemne i dokładnie takie same jak w przypadku plików z kodem źródłowym. Masz doświadczenie w tym temacie, więc sam doskonale wiesz co można zrobić w systemie wersjonowania.
Porzykład z powietrza — masz w grze kupę ilonek np. do menusów, które chcesz wymienić na nowy zestaw. Robisz nowy branch, eksperymentujesz, szukasz najlepszego zestawu i konfiguracji, nie ruszając głównej gałęzi. Jesteś zadowolony z osiągniętych efektów to merge'ujesz gałęzie, a jeśli nie, to ubijasz gałąź i wracasz do tego co miałeś.
Jeśli dwaj graficy pracują jednocześnie nad jednym plikiem na dwóch branchach, to problem nie leży w Gicie, a w zarządzaniu. Bo dokładnie to samo mogę powiedzieć o modyfikowaniu jednego modułu z kodem źródłowym, gdzie jeden deweloper modyfikuje górę pliku, a drugi dół. Tak więc argument z czapy.
akurat to że dwóch developerów modyfikuje różne części tego samego pliku źródłowego i trzeba to mergować zdarza się przy niemal każdym releasie, ciężko żeby każdy miał przydzielony swój moduł skoro cały team zajmuje się jednym modułem. Twierdzisz że nigdy nie miałeś merge conflictów a jeśli są to oznacza błąd w zarządzaniu?
Dokładnie to samo mogę powiedzieć o wieloosobowej pracy nad zasobami graficznymi — tyle że w przypadku grafik żadnych konfliktów nie będzie, bo to nie kod źródłowy. Widzisz problem tam gdzie go nie ma, chyba tylko po, aby się dla zasady przyczepić.
hę? powiedziałem że mergowanie plików graficznych nie ma sensu i że się to nigdy nie zdarza. Ty się przyczepiłeś twierdząc że to samo można powiedzieć o plikach źródłowych. Nie zgadzam się - mergowanie plików źródłowych jest normalną praktyką
ja włączyłem do unity na githubie i sobie chwalę - repo przyspieszyło wielokrotnie i nie zaużyłem minusów, 10MB to już jest duży plik, zresztą limit to 50MB
@Spine: Jeżeli to jest ten sam perforce, z którym miałem do czynienia lata temu, to najgorszemu wrogowi nie życzę... Ale faktycznie miał niezłą funkcję, która może się dobrze sprawdzić w przypadku plików binarnych, czy ogólnie takich, gdzie merge jest niemożliwy czyli "blokowanie".
Jeżeli pracujesz sam nad tymi grafikami, to może wystarczy włączenie historii plików w Windows?
Żeby trochę rozjaśnić to chodzi mi głównie o modele w blenderze (~5k tris), tekstury quixel mixer (1024x1024), GIMP, pliki .png .obj .dds. Do projektów w unity może kiedyś wrócę, ale nie w najbliższym czasie. Nie zamierzam walczyć z konfliktami, raczej nie będę tych plików z nikim dzielić.
Ostatni projekt nad którym siedziałem cały zajął 30MB z kopiami _1, _2, _gotowe ;)