Forum
Użytkownicy
Kalendarz
Dodatki SourceMod
Git to system kontroli wersji.
Czym jest system kontroli wersji
System kontroli wersji śledzi zmiany w naszych plikach. Oznacza to, że dzięki takiemu systemowi możemy się w każdej chwili cofnąć do dowolnej zapisanej wersji naszego pliku. Weźmy przykład, tworzymy bardzo rozbudowany plugin i w pewnym momencie widzimy, że w kodzie brakuje czegoś, co już napisaliśmy... Gdzieś zniknęło, wyparowało, ktoś to usunął, może my sami przez przypadek? Nie ważne, brakuje i to jest jedyny ważny fakt... W takiej sytuacji osoba nie używająca systemu kontroli wersji pisze ten kod od nowa. Osoba która korzysta z systemu kontroli wersji szuka ostatniej zapisanej wersji kodu, gdzie ten fragment jeszcze istnieje i po prostu przywraca ten fragment.
Ale czy to oznacza, że system kontroli wersji przydaje się przy dużych projektach?
Przy dużych, przy małych, przy każdych
Nawet malutki plugin, który ustala tylko interp może być zarządzany w systemie kontroli wersji. Bo przecież sposób ustawiania interpu może się zmieniać i w pewnym momencie dojdziemy do wniosku, że poprzedni sposób był lepszy. I możemy spokojnie do niego wrócić Czyli w systemie kontroli wersji możemy trzymać kod?
Tak, ale nie tylko kod. Możemy trzymać tam dowolne pliki, które się zmieniają. Na przykład referat do szkoły, pracę magisterską, pliki dźwiękowe nad którymi pracujemy, praktycznie wszystko.
Ma to jednak ograniczenie: systemy kontroli wersji najlepiej radzą sobie z plikami tekstowymi (czystym tekstem, tj plikiem z kodem źródłowym, plikiem HTML, plikiem TXT), z plikami binarnymi (którymi są na przykład pliki doc, docx, obrazki, dźwięki) już gorzej. Ale nie jest powiedziane, że całkowicie sobie nie radzą! Radzą, ale mamy mniej funkcji, dla przykładu brak możliwości porównania 2ch wersji plików lub automatycznego połączenia zmian z 2ch wersji. Musimy to wtedy zrobić ręcznie. Ale są odpowiednie wtyczki, które to ułatwiają, dla przykładu wtyczka do porównywania obrazków, która po prostu nam zaznacza kolorem na obrazie wszystkie zmiany.
A czy coś jeszcze potrafią te systemy kontroli wersji?
Ojj dużo więcej, niż tu opisałem
Oczywiście zależy od samego narzędzia, którego używamy. Ale większość z nich potrafi oznaczać konkretne wersje plików własnymi tagami (dzięki temu szybko możemy znaleźć np wersję 1.4 naszego pluginu), możliwość tworzenia gałęzi, porównywania plików, automatycznego łączenia różnych wersji plików, wysyłania plików na serwer... Jest tego mnóstwo.Gałęzi?
Tak
Gałęzie. Prawie jak te na drzewie. Podam prosty przykład.Tworzymy nową super fajną rzecz w naszym pluginie, ale zajmie to nam z 3 dni zanim będzie ona do użytku. W pewnym momencie, tak w połowie tworzenia, dociera do nas informacja, że w dotychczasowej wersji jest bardzo poważny błąd i trzeba go szybko naprawić. Jest to dużo ważniejsze od tej nowej rzeczy którą właśnie piszemy. No i co teraz? mamy kod rozgrzebany na 4 strony świata i albo musimy chwilowo wyrzucić wszystko co pozmienialiśmy, albo skończyć to, co tworzymy teraz...
I tu nas ratują gałęzie. Każde repozytorium posiada tzw gałąź główną, którą nazwiemy teraz masterem. I wystarczy, że przed zaczęciem pracy nad nową rzeczą utworzymy nową gałąź i na niej tą rzecz będziemy robić. Wybucha alarm, trzeba naprawić błąd, przechodzimy więc grzecznie na gałąź główną i tworzymy z niej następną gałąź, na której naprawimy ten błąd. Przez to, że jesteśmy teraz na gałęzi głównej, cała nasza robota bezpiecznie sobie czeka na osobnej gałęzi. A my po naprawieniu błędu i opublikowaniu wersji bez błędu wracamy do roboty nad naszą super mega hiper rzeczą.
Dla wzrokowców:
--•--•--•-- | Fix błędu
/ \
--•--•--•--•--•--•--•--+-------------+-- | Gałąź główna
\
--•--•--•--•--•--•--•--•--• | Nowa super hiper rzecz
Kropki to po prostu różne zapisane wersje kodu. + to rozdzielenie czyli w tym miejscu tworzymy nową gałąź i jak widać gałąź z Fixem błędu łączymy do głównej, to samo zrobimy oczywiście później z naszą nową funkcjonalnością.W niektórych systemach kontroli wersji, m.in w GITcie będzie to wyglądać tak:
--•--•--•--•--•--•--•--+--•--•--•-- | Gałąź główna | Fix błędu
\
--•--•--•--•--•--•--•--•--• | Nowa super hiper rzecz
Dlaczego? Ano dlatego, że na głównej gałęzi nie nastąpiły żadne zmiany (brak jak widać kropek), więc została ona po prostu całkowicie połączona z fixem błędu i tworzą one teraz jedną całość, a nie jakieś takie dziwne rozgałęzienia i łączenia jak wyżej. Oczywiście jeśli choć jedna zmiana byłaby obecna na gałęzi głównej to wyglądałoby to tak, jak "rysunek" poprzedni Ale czym jest repozytorium?
Tak, wcześniej użyłem tego słowa. Repozytorium jest po prostu zbiorem plików, często jest to po prostu folder na dysku. Ten zbiór jest zarządzany jako całość, czyli tworzymy w nim gałęzie, zapisujemy wersję wszystkich plików itp. Najwygodniej dla każdego projektu (czyli pluginu osobnego albo zbioru pluginów działających razem) utworzyć osobne repozytorium. Dzięki temu zarządzamy jednym projektem niezależnie od innych. Głupotą jet wrzucanie plików z jednego projektu do osobnych repozytoriów, bo później się okaże, że wersja ta z tego repozytorium nie jest kompatybilna z tamtą z tamtego. Więc pamiętajmy - 1 projekt = 1 repozytorium.
No dobrze, ale co z tym GITem?
Opisałem ogólnie czym są systemy kontroli wersji. GIT jest jednym z nich. Jednym z lepszych, a moim zdaniem najlepszym
Słyszeliście może o innych: Bazaar, SVN, Mercurial...
Tak, są inne i też są ciekawe. Osobiście jednak używam GITa bo jest najwygodniejszy i chyba potrafi najwięcej. SVNa od razu odradzam. Z tego korzystają wielkie korporacje założone w zeszłym tysiącleciu, bo wtedy był tylko SVN dostępny. Jest stary, obolały, nie rozwijany od długiego czasu i co najgorsze, scentralizowany. Bazaar i Mercurial są też ciekawe, ale jakoś nigdy mnie nie przekonały tak, jak GIT.
Co to znaczy, że SVN jest scentralizowany?
To oznacza, że wszystko jest trzymane na serwerze. Jeśli chcemy pobrać inną wersję pliku, łączymy się z serwerem i on nam ją podaje. Oczywiście wersja na której aktualnie pracujemy jest skopiowana na nasz dysk, ale tylko jedną wersję na raz mamy. Co jest wadą, bo nie mając dostępu do serwera nie możemy w pełni pracować nad projektem. Poza tym potrzebujemy takiego serwera, możemy go uruchomić na własnym komputerze, ale to jest niewygodne i bardzo źle się tak pracuje. A teraz pracujmy na innym komputerze, bo np siostra nam zabrała laptopa i musimy na stacjonarnym kompie siedzieć. I zonk, oba komputery muszą być włączone i muszą mieć połączenie ze sobą, żebyśmy mogli pracować, bo inaczej serwera nie ma. Same kłopoty...
Czy to oznacza, że inne systemy kontroli wersji nie mogą się łączyć z serwerem?
To, że nie muszą nie oznacza, że nie mogą
Git jest zdecentralizowany, ale nadal posiada architekturę umożliwiającą połączenie się z innymi. Jednak nie jesteśmy w stanie tutaj wyróżnić klienta i serwera, przynajmniej nie na stałe. Oznacza to, że możemy się połączyć z każdym komputerem, który posiada to repozytorium i je pobrać albo coś do tego komputera wysłać. Oczywiście wygodnie jest sobie wyznaczyć który z nich będzie serwerem, ale konieczne to nie jest. No i zawsze posiadamy pełną kopię całego repozytorium u siebie na dysku. Oczywiście jeśli chcemy, bo nie zawsze potrzebujemy pobrać wszystkie gałęzie, możemy pobrać to, co nas interesuje i korzystać z tego nawet bez połączenia.Są też już gotowe, darmowe serwery, a właściwie serwisy oferujące repozytoria na swoich serwerach. Na przykład GitHub. Kosztem jednak jest to, że takie repozytorium jest publiczne, tj każdy może sobie je pobrać i przeglądać kod. Istnieje jeszcze Bitbucket w którym możemy za darmo tworzyć prywatne repozytoria, jednak z limitem do 5 osób na repozytorium. Oczywiście oba serwisy posiadają oferty płatne, gdzie nie mamy żadnych limitów na repozytoria prywatne.
Osobiście polecam wszelkie publiczne projekty trzymać na GitHubie, jest najbardziej popularny i jeśli ktoś będzie szukał naszego projektu, tam właśnie zacznie
No to super, więc jak korzystać z GITa?
Nie jest to takie trudne. Właściwie można wytypować 3 drogi:
- Wykonywać odpowiednie polecenia w konsoli
Tak, wiem że to nie jest rozwiązanie, które spodoba się wszystkim, ale naprawdę używanie konsoli do tego typu zadań jest bardzo przyjemne i do tego ona właśnie została stworzona. Dla nieprzekonanych o tym osób są następne 2 sposoby, więc się nie martwcie. Jednak należy uważać, bo poniższe 2 mogą posiadać ograniczenia (w zależności od użytych narzędzi oczywiście), a konsola takich mieć nie będzie
Bardzo dobry e-book odnośnie nauki GITa znajdziecie tu, nie dość że po polsku to naprawdę świetnie napisany - Użyć edytora z wbudowaną obsługą GITa
To rozwiązanie dla wielu osób będzie z pewnością najwygodniejsze. Możemy zarządzać dzięki niemu repozytoriami bez opuszczania edytora. Istnieją odpowiednie dodatki dla prawie każdego dobrego edytora. Nie znalazłem jednak takiego jak na razie dla AMXX Studio, ale nawet dużo nie szukałem, bo go nie używam, więc może istnieje.
Przykładowe edytory z wbudowaną obsługą GITa:
Atom Jak na razie do pobrania tylko pod Mac OS, ale można go skompilować dla innych systemów. Wydany przez speców od GitHuba, więc z nim się integruje najlepiej
Qt Creator jest właściwie stworzony do tworzenia w C++ z użyciem bibliotek Qt, ale bardzo fajnie się w nim też pisze w PAWNie jeśli doinstalujemy podświetlanie składni
Plugin do Notepad++ - Użyć zewnętrznego narzędzia okienkowego
Czyli tzw nakładki Jest ich trochę, a 2 popularne i bardzo fajne to TortoiseGIT (narzędzie dostępne w specjalnym menu w prawokliku na plikach i folderach, więc nie uruchamiamy osobnego programu, bo się ładnie integruje z eksploratorem windows) oraz specjalny program od GitHuba. Służy on praktycznie w całości do integracji z GitHubem, ale spokojnie można go używać do repozytoriów trzymanych tylko lokalnie albo nawet na innych serwerach. Istnieje również aplikacja wydana przez twórców bitbucket o nazwie SourceTree, obsługuje ona też Mercuriala i jest bardzo rozbudowana. Zrobimy z niej praktycznie wszystko, więc linia komend nie jest potrzebna.
Apka GitHuba pod windowsa, Mac OS, a nawet pod Androida
Tutaj macie SourceTree
No i oczywiście TortoiseGIT
Super, a czy będzie jakiś tutorial o obsłudze GITa?
Takowego nie przewiduję, tutoriali na internetach do GITa od groma, wyżej podlinkowałem najlepszy wg mnie e-book, który jest dostępny w bardzo wielu językach w tym w Polskim. Aplikacje są bardzo intuicyjne i każdy się ich nauczy, no może oprócz SourceTree, który jest mocno rozbudowany, ale żeby jego w całości ogarnąć to trzeba być naprawdę wyjadaczem
