Kontrola wersji i wspólne pisanie Unreal 4.26.1

#1

Cześć wszystkim. Mam kilka pytań odnośnie kontroli wersji.

Po pierwsze czy dobrze rozumiem koncept. Oglądałem kilka poradników do GitHub, coś tam poczytałem o kontroli wersji. Działa to w ten sposób, że jeżeli ja wprowadzę jakąś zmianę w pliku i zrobi to też inna osoba to obie zmiany będą wprowadzone do kodu?

Co jeżeli wprowadzimy zmiany, w dokładnie tych samych linijkach (grafach w blueprintach)? Jest to w ogóle możliwe, czy akceptowana jest tylko jedna wersja pliku?

Czy do projektu na blueprintach nie są lepsze inne typy kontroli wersji niż repozytorium GIT? Coś tam próbowałem zrobić, ale nie wyszło mi połączenie mojego projektu z repozytorium.

Korzystał ktoś z kontroli wersji w projektach robionych na blueprintach i może pomóc zrobić takie repozytorium? Najlepiej przez discorda.

#2

Najlepiej ogarnąć Perforce. Kiedy jedna osoba zaklepie (checkout) sobie pliczek, to druga nie może go nadpisać na repo. Git jest rozproszonym systemem, i o zaklepywaniu plików nie ma mowy. Serwer perforce powinien oczywiście pracować na maszynie, która jest włączona 24h na dobę, żeby każdy dev miał dostęp do repo o każdej porze (najlepiej jakiś VPS). Chyba że robicie hobbystycznie, i zawsze w tych samych godzinach, wtedy postaw sobie serwer Perforce u siebie na kompie i najwyżej jak kolega będzie chciał coś wrzucić na repo w środku nocy, to wstaniesz i włączysz kompa :smiley:

PS. Perforce jest darmowy, do chyba 25 stanowisk

#3

Pracuję w zespole 5 osobowym i używam Gita od kiedy o nim usłyszałem, sporadycznie się zdarza że są konflikty, ale łatwo je rozwiązać.

Najważniejsze w pracy z Gitem:

  1. jedna osoba jest odpowiedzialna za nanoszenie zmian na master
  2. nie pracować na gałęzi master
  3. czyli każdy programista pracuje tylko na swojej gałęzi
  4. przed rozpoczęciem prac nad nową rzeczą zawsze zaciągamy zmiany z mastera
  5. nowe zadanie nowa gałąź

Jeśli zdarzy się że ktoś coś popsuje to mając Gita zawsze można to odzyskać i naprawić, bez gita przepada.

Jest jeszcze coś takiego jak Bitbucket, osobiście z tego korzystam od wielu lat.

#4

W kontekście UE4 lepszy jest Perforce z racji fajnych ficzerów w samym edytorze. Np. jak ktoś inny ma wycheckoutowany plik, to u Ciebie w edytorze pojawia się przy nim niebieski ptaszek, żebyś wiedział że jest zablokowany.

#5

Nigdy nie pracowałem na dużych plikach ale czytałem że wydajność spada wykładniczo w przypadku wykorzystywania GITa do dużych plików, dlatego NIGDY nie mam w repo plików binarnych tylko tekstowe, SVN nie ma tego problemu.

Jedyny problem jak widzę z SVN to że nie mogę pracować jak serwer jest wyłączony, muszę czekać jak ktoś włączy komputer(serwer) i wtedy reszta ekipy może zacząć pracę.

#6

No niestety największą bolączką scentralizowanych systemów jest dostępność serwera (no i bezpieczeństwo) :smiley:

#7

Całość stanu plików masz w jakiejś wersji na branchu.
Masz historię.
Masz loklany stan u różnych ludzi na dyskach i w lokalnych repo na poszczegółnych komputerach.
Masz jakieś źródło prawdy - 1 konkretny komputer na którym jest obowiazująca wersja.
Jeśli są wysłane 2 zmiany które da sie pogodzić - zmiany w innych pikach albo plik tekstowy i zmiany w innym miejscu piku to systemy starają sie zanieść te zmiany możliwie bezboleśnie.
Jeśli nie są w stanie wyślą ci info - jest konflikt - ręcznie określ jaki ma być skutek naniesienia obu zmian.

W przypadku plików binarnych praktycznie każda zmiana musi być fixowana ręcznie. Kiedyś blueprinty były binarne więc wszselkie niekompatybline zmiany oznaczały że ten kto niezdążył musiał pobrać nową wersję i przeklikać wszytko jeszcze raz. Może coś poprawili bo tekstowe bluepriny byłyby dużo lepsze, ale nie wiem czy to poszło w te stronę… chyba nie…

Generalnie do plików tekstowych Git >>>> cokolwiek.
Naprawdę do kodu to inna jakość życia.
Super tanie branche + dobrej jakości automatyczne merge, poezja.
Ale git nie jest prosty w użyciu, trzeba się poduczyć.
I przy plikach binarnych git nie specjalnie pomaga.
Nawet trochę sie nie nadaje i są rozszerzenia dla gita żeby działał wydajniej jak jest dużo plików binarnych.

Checkoutowanie w perforce (p4) że się ptaszek wyświetla.
To miłe i pomaga w synchronizacji,
ale tak naprawdę nic nie oznacza bo i tak można to wrzucić…
a tu ktoś zaptaszkuje ale jednak się rozmyślił i w sumie to ten ptaszek tylko myli
Itd itp
I jak 2 osoby siedzą na mapie to i tak będą miały konflikt.
Wsparcie edytora trochę pomaga unikać konfliktów
ale jest mnóstwo scenariuszy gdzie nie wystarczy.

(Btw nazewnictwo jest tragiczne, bo w gicie chekout oznacza pobranie brancha,
a w p4 zaklepanie sobie pliku
w ogóle podobne rzeczy mają inne nazwy
a czasem kompletnie różne rzeczy korzystają z tych samych w innych systemach)

I p4 kiedyś przynajmniej nie miał darmowej wersji,
co oznacza że dla małego projektu git albo SVN.
Programistom polecam gita, nawet jako lokalna pomoc jeśli główne repo jest na czymś innym.
Do binarek p4 albo SVN mogą ułatwić pracę i nie będzie trzeba uczyć nie programistów gita.

Przy każdym projekcie trzeba sie nauczyc pracować z kontrolą wersji

  • jakiś logiczny sposób zarządzania branchami
  • częsta synchronizacja z najnowszą wersją
  • struktura projektu tak żeby ograniczać sytuacje gdzie 2 osoby sobie na wzajem psują pracę