W jaki sposób zespoły zapobiegają nadpisywaniu plików źródłowych? [Zamknięte]

26

Przyszło mi do głowy, że podczas gdy, na przykład, silnik gry, pracuje jednocześnie przez wiele osób, jak można uniknąć nadpisywania?

Powiedzmy, że programista nad którym pracuje, Audio.cppa programista nad drugim również Audio.cpp, w jaki sposób jest to ogólnie zarządzane w dużych zespołach w celu zwalczania nadpisywania? (Innymi słowy, aby zatrzymać programistę dwa przed otwarciem pliku, dopóki programista jeden nie zakończy pracy)

Ethan Webster
źródło
84
Jeden z wybranych tagów jest już odpowiedzią.
Philipp
18
W rzeczywistości, 3 z 4 znaczniki są odpowiedzi, ale jedno jest odpowiedź.
MSalters
1
Powiązane: gamedev.stackexchange.com/q/480
moooeeeep

Odpowiedzi:

69

Większość zespołów tworzących oprogramowanie (nie tylko podczas tworzenia gier) rozwiązuje ten problem za pomocą oprogramowania do kontroli wersji . Przykładami są

Wszystkie te narzędzia mają pewne różnice, ale podstawowy przepływ pracy jest zwykle taki: Istnieje jedno centralne repozytorium dla projektu z pełną bazą kodu. Gdy programista chce dołączyć do projektu, wykonuje „kasę”. Oprogramowanie do kontroli wersji kopiuje bazę kodów na komputer lokalny. Oprogramowanie zapamiętuje bieżącą wersję („wersję”) bazy kodu. Gdy programista dokonał zmian i chce je umieścić w głównym repozytorium, wykonuje „zatwierdzenie”. Ich zmiany są przesyłane do centralnego repozytorium i tworzony jest nowy numer wersji.

Gdy inny programista chce teraz zatwierdzić swoje zmiany, ale wersja, którą raz wypisali, nie jest już najnowsza, system kontroli wersji im na to nie pozwala. Deweloper musi najpierw „wyciągnąć” poprawki, które wydarzyły się w międzyczasie. To aktualizuje ich lokalną kopię do najnowszej wersji w centralnym repozytorium. Kiedy występują konflikty (w przejściowych wersjach wprowadzono zmiany do pliku, który również zmienili), oprogramowanie może poprosić ich o rozwiązanie konfliktu poprzez ręczną edycję konfliktowych plików („scalanie”), na wypadek, gdyby nie udało się tego automatycznie zrobić. Po wykonaniu tej czynności mogą zatwierdzić zmiany jako nową wersję.

Philipp
źródło
18
Zauważ, że Git i Mercurial to rozproszone systemy kontroli wersji, które działają nieco inaczej: nie wymagają jednego centralnego repozytorium, ale teoretycznie pozwalają każdemu deweloperowi na pobieranie aktualizacji bezpośrednio od kogokolwiek innego. Oczywiście w praktyce wciąż zdarza się, że jedno repozytorium (często zlokalizowane na hoście publicznym, takim jak GitHub) deklaruje, że jest „oficjalne” i używane mniej więcej tak, jak centralne repozytorium w niepodzielnym systemie kontroli wersji.
Ilmari Karonen,
18
Ta odpowiedź oznacza również, że scalanie odbywa się zawsze ręcznie. Przez większość czasu jednak oprogramowanie do kontroli wersji może automatycznie łączyć różnice i wymaga tylko pracy ręcznej w przypadku naprawdę drażliwych zmian.
jhocking
Unikajcie długiej dyskusji w komentarzach, ludzie. To nie jest forum dyskusyjne. Jeśli chcesz to zrobić, skorzystaj z czatu poświęconego rozwojowi gry . Wyczyściłem kilka stycznych wątków komentarzy.
Josh
Ponadto idealnie, gdyby każdy członek zespołu był odpowiedzialny za określone moduły prawie wyłącznie i tylko w rzadkich przypadkach więcej niż jedna osoba zmodyfikowałaby ten sam plik źródłowy w krótkim czasie, ponieważ ten przepływ pracy minimalizuje potrzebę scalania sprzecznych zmian. Ale nie zawsze tak jest.
Nicolas Miari
13

Programiści nie używają tego samego pliku.

Każdy programista ma własną wersję pliku i do zarządzania swoją pracą korzysta ze specjalnego rodzaju oprogramowania. Jeśli obaj dokonają w nim zmian, ten, który próbuje zastąpić zmiany dokonane przez innego programistę, napotka konflikt, który należy rozwiązać, w przeciwnym razie oprogramowanie, o którym mówiłem, zaczyna narzekać. Innymi słowy, programista, który powoduje konflikt, musi połączyć swoją pracę z pracą innego programisty i dopiero wtedy plik można „zapisać”.

To proste wyjaśnienie części niezbyt prostej koncepcji kontroli wersji .


źródło
6
Robią też tę nowatorską rzecz zwaną komunikacją, a oprogramowanie nie jest pisane w próżni. Więc jeśli nie rozumieją konfliktu, najpierw rozmawiają z drugą osobą lub koordynują.
Brian
9

Oprócz kwestii poruszonych w innych odpowiedziach dotyczących kontroli wersji i rozwiązywania konfliktów przy scalaniu, istnieją co najmniej dwa inne sposoby, w których członkowie zespołu mogą uniknąć wzajemnego nadpisywania swojej pracy:

  • Niektóre systemy kontroli wersji (np. SVN) umożliwiają blokowanie plików. Oznacza to, że jeden członek zespołu może przejąć wyłączną własność pliku przez pewien czas, uniemożliwiając innym członkom zespołu dokonywanie sprzecznych edycji (lub, w rzeczywistości, jakichkolwiek zmian), dopóki plik nie zostanie odblokowany.

    Jest to jednak powszechnie stosowane rzadko, ponieważ może powodować szereg problemów. Może zmniejszyć produktywność (ograniczając, kto może pracować na plikach w danym momencie) i może powodować problemy, jeśli ktoś zapomni odblokować plik. Ponadto, przynajmniej w przypadku SVN (nie jestem pewien co do innych VCS), zablokowanie pliku nie zapobiega wprowadzeniu zmian w kopii roboczej przez kogoś innego, tylko zapobiega ich zatwierdzeniu - może to prowadzić do zmarnowanego wysiłku, jeśli programista modyfikuje plik tylko w celu wykrycia, że ​​nie może zatwierdzić swoich zmian, ponieważ jest on zablokowany.

  • Zespoły mogą próbować przypisywać zadania programistom w taki sposób, aby nie mieli więcej niż jednej osoby pracującej nad danym plikiem w danym momencie. Na przykład, programiści mogą być odpowiedzialni za określoną część projektu (np. Renderowanie 3D, sieć, audio itp.) - jeśli podstawa kodu jest dobrze zmodularyzowana, to programista przypisany do kodu sieci nie powinien dotykać plików radzenie sobie z dźwiękiem.

    Oczywiście zawsze zachodzi pewne nakładanie się, którym należy zarządzać w inny sposób.

Prochowiec
źródło
2
Plusem jest to, że blokowanie jest jedynym sposobem edycji pliku .JPEG lub innego pliku innego niż zwykły tekst. To nie jest teoretyczne ograniczenie, po prostu narzędzia do scalania zwykle są do kitu.
MSalters
2
@MSalters To nie jest tak, że narzędzia są do bani, po prostu większość narzędzi do scalania jest tworzona dla tekstu, a nie dla danych binarnych. Jak rozwiązałbyś konflikt, gdyby dwie zmiany zmodyfikowały ten sam piksel w pliku? A co gorsza, jak uwzględniłbyś zmiany spowodowane kompresją JPEG? Jest to bardzo złożony problem, który może nie mieć nawet jednego dobrego rozwiązania, dlatego większość narzędzi do scalania nie obsługuje, ponieważ potrzeba jest bardzo rzadka, a funkcjonalność trudna do wdrożenia.
Maurycy
3
@MaurycyZarzycki: Zmiana tej samej litery jest podobna do zmiany tego samego piksela: wymaga ręcznego rozwiązania. Rozumiem, że .JPEG był prawdopodobnie złym przykładem, ponieważ artyści nie pracują nad stratnymi formatami. Ale problem z scalaniem istnieje również w .PNG. Przynajmniej byłbyś wdzięczny, gdyby narzędzia do scalania byłyby w stanie scalić XML bez jego łamania.
MSalters
@MSalters Jasne, dzięki czemu mogę zgodzić się znacznie więcej.
Maurycy
1
@xorsyst: Wypróbuj w ten sposób: sprawdź z SVN w dwóch lokalizacjach. Następnie zablokuj plik z lokalizacji 1. Lokalizacja 2 nie będzie wiedziała, że ​​jest zablokowana do czasu zatwierdzenia lub aktualizacji.
Zan Lynx,