Tworzenie gier to fajne zajęcie (taaa, jasne), ale nie wszystkie projekty tworzy się w pojedynkę. Jeśli jest jeden programista to tam "pół biedy", jeśli ich jest paru to muszą się jakoś zsynchronizować - i temu po części służy system kontroli wersji.
Programy (i gry) tworzy się w sposób "klockowy". Ogólnie zaczyna się od pustego programu, później dokłada powoli zmienne, funkcje - każdą taką operację można przyrównać do budowania zamku z klocków. Klocek po klocku aż powstanie gotowy projekt.
Git umożliwia analizowanie różnic między dwoma kawałkami kodu (lokalnie stworzonej na komputerze i globalnie zapisanej na serwerze) i wysłanie takich różnic na główny serwer (jako klocek). Potem inni użytkownicy mogą przeczytać co w danym commit (czyli klocku) się znajduje i zaadaptować do siebie. Jeśli tacy użytkownicy zrobią własny kod to mogą go wrzucić a my ostatecznie możemy go zaakceptować do swojego projektu.
To jakie opcje ma taki system?
Forkowanie
W projektach Open Source (głównie) się to stosuje. Jest to w zasadzie rozdzielenie się kodu (od pewnego momentu) na dwa niezależne. Powiedzmy, że nie podoba nam się wizja projektu tworzonego przez autora - możemy wziąć projekt i od pewnego momentu tworzyć go na własną rękę.
Przykładem niech będzie SteemNova i silnik 2Moons. SteemNova powstała by oczywiście zachęcić ludzi do wspólnych interakcji ze sobą, ale po części musiała mieć inne funkcje, których oryginalny silnik nie ma - np. autoryzacja SteemConnect. Dzięki SteemConnect człowiek może się zarejestrować (i logować) swoim kontem Steem co jest zbędne w oryginalnym silniku. I tak projekt rozdzielił się na dwie wersje. Oczywiście nowe projekty mogą współpracować ze sobą tak jak jest w SN i 2Moons.
"Cofanie się w czasie"
Aktualizujemy program i zauważamy błąd - o nie! Oczywiście możemy zgłosić to producentowi, ale wiedząc której wersji używaliśmy i która ma błąd możemy ograniczyć zasięg poszukiwań, gdyż wiadomo które linijki zostały dodane, usunięte lub zmienione. Puff, znaleźliśmy błąd.
"Własne forki"
Programy do kontroli wersji mogą tworzyć tzw. "Branches". Powiedzmy, że musimy coś zrobić na nowo - albo przepisać większość kodu, albo dodać funkcjonalność nową (dużą). Modyfikacja głównej linii nie zawsze ma sens. Wtedy można zostawić kod jak jest i zająć się specjalną odnogą programu, która jak będzie skończona - zostanie dodana do głównej funkcjonalności.
Kopia zapasowa
Kopię na serwerze można traktować jako kopię zapasową projektu. Przecież nie oszukujmy się - komputery się psują, a taka kopia zapasowa jest bardzo łatwa w stosowaniu, gdyż nie musimy się zastanawiać czy ta wersja na dysku jest aktualna bardzo czy nie. Możemy to sprawdzić po kolei.
Na zakończenie
Różnego rodzaju systemy kontroli wersji są bardzo ważnym i użytecznym oprogramowaniem - W przypadku amatorskiego tworzenia gier nie są może one niezbędne, ale raz wrzucony kod źródłowy może być np. dodany na Utopian.io i może zarobić troszkę pieniędzy (co prawda są z tym olbrzymie problemy, bo zamiast organizację wspierającą programistów idą w stronę urzędu z 12 prac Asteriksa, ale jednak).
Czyli rzecz być może warta zobaczenia ;)
W następnej części spróbujemy w sposób praktyczny pokazać podstawowe rzeczy związane z Git i Github (wymagany w Utopianie - interfejs i serwer dla projektów).