Kontrola wersji z tworzeniem gier - kiedy należy rozgałęzić?

Niedawno zacząłem używać Kontroli wersji w swoich projektach (chociaż pracuję nad nimi sam). Uważam, że daje to dobry sposób na przechowywanie historii całego procesu programowania (ze śledzeniem problemów) i pozwala mi przechowywać kopie zapasowe dla moich projektów po drodze.

Kiedy powoli odkrywam funkcje i zalety korzystania z kontroli wersji, utknąłem wokół idei rozgałęziania. Kiedy powinienem to zrobić?

Czy powinno to być za każdym razem, gdy idę i rozwijam nową funkcję, czy tylko raz na jakiś czas, kiedy osiągam pewien kamień milowy?

Oczywiście rozgałęzianie jest dość bezużyteczne, gdy pracuję sam, ale wolałbym teraz nabrać dobrych nawyków i przyzwyczaić się.

Kiedy czytałem książkę Game Coding Complete autorstwa Mike'a McShaffry'ego (która jest świetną książką), całkowicie się zgubiłem, gdy autor zalecił trzymanie trzech gałęzi, coś w stylu:

• Główny : Główny dział rozwoju, w którym dokonywane są regularne zmiany.
• Złoto : złota gałąź, w której przechowywany jest ostatni kamień milowy.
• Badania : Oddział do testowania rzeczy, które mogłyby źle wpłynąć na Oddział główny (modyfikowanie ważnych elementów silnika gry itp.).

Czy tak ma być? Jak to naprawdę działa w świecie tworzenia gier z dużymi zespołami programistów?

Zasadniczo: Kiedy zwykle rozwija się (i łączy) rozwój gier?

Rozgałęzienie zależy trochę od obsługi funkcji przez VCS (tj. Od tego, czy VCS czyni to łatwym, czy trudnym).

Ale przynajmniej potrzebujesz gałęzi dla każdej niezależnie obsługiwanej wersji twojego projektu. Oznacza to, że jeśli masz „Game 2” i „Game 2 + Expansion”, które są oddzielnymi produktami zbudowanymi z tej samej bazy kodów i do których musisz mieć możliwość łatania i wydawania aktualizacji, to chcesz mieć każdy z nich istnieją we własnej gałęzi poza główną bazą kodu, dzięki czemu poprawki do podstawowej bazy kodu można połączyć niezależnie z każdym z tych produktów. (Zazwyczaj te gałęzie są tworzone po wydaniu każdego produktu, a może kilka dni / tygodni wcześniej, jeśli w bazie kodu pracują ludzie, których nie chcesz wychodzić z pierwszą wersją)

Podczas pracy z VCS, który sprawia, że ​​korzystanie z gałęzi jest trudne lub bolesne (SourceSafe, svn itp.), Prawdopodobnie będziesz najszczęśliwszy, utrzymując gałąź „release” dla każdego wydanego produktu i robiąc główny rozwój w „trunk”, łączenie zmian z „trunk” do gałęzi „release”, jeśli i kiedy trzeba wydać poprawki dla tych wydań.

Jeśli natomiast pracujesz z jednym z nowszych systemów VCS zbudowanych wokół rozgałęziania i łączenia (git, Bazaar, Mercurial itp.), Prawdopodobnie będziesz najszczęśliwszy, robiąc swój rozwój w bardzo krótkim czasie - żywe gałęzie „funkcji”. Na przykład, jeśli pracujesz nad wyszukiwaniem ścieżek AI, możesz utworzyć gałąź „wyszukiwanie ścieżek” i zaimplementować tam kod. Po zakończeniu scalasz tę gałąź z powrotem do głównej gałęzi rozwoju i (opcjonalnie) usuwasz gałąź, w której pracujesz. Zaletą tego podejścia jest to, że pozwala ci pracować nad wieloma zadaniami jednocześnie, zamiast konieczności wykonania jednego. zadanie przed rozpoczęciem następnego.

W moim bieżącym projekcie domowym (używając git) mam teraz pięć różnych gałęzi funkcji, pracujących nad różnymi różnymi funkcjami. Dwa z nich to alternatywne podejścia do robienia tego samego (do profilowania), dwa to eksperymentalne pomysły na mechanikę gry, a jeden jest dużym refaktorem moich systemów AI i jest faktycznie uszkodzony w taki sposób, że kod nie kompiluje się poprawnie teraz. Ale jest zaangażowany w gałęzi funkcji w celach informacyjnych i tworzenia kopii zapasowych, a jego uszkodzenie nie powstrzymuje mnie przed pracą nad innymi funkcjami; Te inne gałęzie funkcji (a także główny pień programistyczny) nadal się kompilują i działają poprawnie.

Z mojego doświadczenia w profesjonalnym tworzeniu gier przez duży zespół, nadal tkwimy głównie w starszych (i wspieranych komercyjnie) systemach kontroli wersji. Prawdopodobnie najczęściej stosuje się Perforce, a następnie Subversion. Wszędzie, gdzie pracowałem, mieliśmy gałąź „trunk”, a następnie oddzielną gałąź „release” dla każdego produktu (kamień milowy / demo / release / itp.). Czasami ktoś zrobi osobistą gałąź dla jakiejś ogromnej zmiany, którą wprowadza lub testuje, ale jest to niezwykle rzadkie i zwykle dotyczy rzeczy takich jak „konwersja gry do działania z tą inną biblioteką fizyki”, która może nie przejść do wydany produkt.

Już powyższa doskonała odpowiedź, ale jedną rzeczą, na którą należy zwrócić uwagę, jest to, kiedy chcesz rozgałęzić się i kiedy chcesz oznaczyć.

Większość vcs pozwala na tagowanie (czasem nazywają to etykietowaniem). Powinieneś stosować znacznik za każdym razem, gdy wykonujesz poważną kompilację (albo do testu playtowego, albo do beta testów, albo do funkcji, która się pojawi). Jeśli używasz pewnego rodzaju ciągłej integracji (i powinieneś), system CI powinien oznaczyć udane kompilacje. Zasadniczo za każdym razem, gdy robisz coś, do czego możesz wrócić (aby utworzyć gałąź lub sprawdzić, jak zrobiłeś coś w tej wersji), stwórz tag / etykietę. Są zwykle tanie i łatwe do dodania.

Inną rzeczą, którą zdecydowanie zalecałbym, jest utrzymanie zasobów i kodu w tym samym systemie kontroli wersji. Posiadanie gałęzi (lub tagu) kodu jest całkowicie bezużyteczne, jeśli nie można dopasować (a następnie rozgałęzić) zasobów. Jest to jeden z głównych powodów, dla których firmy gier uwielbiają Perforce - równie chętnie przechowuje binarne pliki sztuki, jak i kod, i (w przeciwieństwie do git) jest zrozumiały dla nietechnicznych typów!

Aha i za każdym razem, gdy masz ochotę sprawdzić skompilowane pliki w swoim VCS, zatrzymaj się i zastanów się, jak możesz tego uniknąć. Z mojego doświadczenia wynika, że ​​prawie zawsze prowadzi to do niedopasowania danych, braku źródła (gdzie na przykład zapisywana jest skompresowana tekstura DDS, ale nie źródło png) i chaos w dół. Jeśli masz potok zasobów, który jest lepiej obsługiwany przez gdzieś buforowane pliki eksportowane (więc nie wszyscy ponownie generują ten sam zestaw plików), na wszelki sposób możesz zbudować zasoby źródłowe w VCS i umieścić wyeksportowane pliki w pamięć podręczna (lub dysk współdzielony, a nawet osobny VCS). Ale nie sprawdzaj ręcznie tych wyeksportowanych plików - to cię ugryzie (szczególnie jeśli pracujesz w zespole).

Kochałem tę książkę i polecam ją wszystkim zainteresowanym. W przypadku niezależnych projektów jednoosobowych nie ma potrzeby tworzenia rozgałęzień, chyba że potrzebujesz lub chcesz utworzyć osobne wersje; jak jeden na Androida i jeden na PC lub coś podobnego.

Jak powiedziałeś, jeśli chcesz nabrać dobrych nawyków, wybrałbym podejście Mike'a. Ma to sens i takie podejście wykorzystuję w moich niezależnych projektach dla dwóch osób.

Wszystko, czego potrzebujesz, aby móc wrócić i wykonać więcej pracy, powinno być możliwe do rozgałęzienia (ale niekoniecznie rozgałęzione ... jeszcze).

Powód tego jest prosty. Musisz mieć możliwość wydania stałej wersji tego kodu, a nie żadnego innego kodu, więc w tym czasie musisz pracować nad oddziałem.

VCS są różne. Niektóre - jak git - są bardzo łatwe do rozgałęzienia z dowolnego zatwierdzenia w późniejszym czasie, inne - jak CVS - są bardzo kłopotliwe przy późniejszej pracy.

Być może chcesz otworzyć pytanie dotyczące przepływu stosu, pytając, jak najlepiej pracować z wybranym systemem kontroli wersji? Jeśli tak naprawdę jeszcze nie zacząłeś z dużą historią, możesz otworzyć pytanie opisujące sposób pracy i poprosić o rekomendację najlepszego systemu kontroli wersji dla Ciebie?