Dlaczego warto korzystać z GITa?
GwynBleidD
27.06.2014
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 rzeczKropki 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 rzeczDlaczego? 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
sebul
27.06.2014
Jakby nie patrzeć coś tam wspólnego ma.No spoko, ale co to robi w dziale Scripting AMXX? sam GIT z amxx'em ma niewiele wspólnego.
BlackPerfum
27.06.2014
Osobista opinia na temat git'u: Dzięi nie skorzystam bo wszystko piszę na jednym kompie (zawsze). A nie mam z kim pisac bym miał to mu przesyłac po każdej zmianie. Nie potrzebne mi sa te gałęzie bo mam na takie przypadki sposoby, także nie widzę sensu korzystania z powracania do dawnego kodu (bynajmniej w moim przypadku). Nie raz pisałem spore projekty i zawsze radziłem sobie na własne sposoby ;D
Ale jak najbardziej polecam bo moja indywidualna opinnia nie ma tu nic do gadania
Widziałem to parę razy w akcji i jest całkiem spoko
Puchate
28.06.2014
Sama nazwa mówi że jest GIT.
Bez kontroli wersji łatwo jest pogubić starsze wersje i problem jest gdy projekt ma się rozgałęźniać
Edited by Puchate, 28.06.2014 01:57.
GwynBleidD
28.06.2014
Chodzi Ci o konflikty? Jeśli 2 osoby edytują ten sam fragment pliku albo dodadzą coś mniej więcej w podobnym miejscu to są one praktycznie nieuniknione. No sorry, ale GIT nie przewidzi co autorzy mieli na myśli i jak wygenerować działający kod. Jakby potrafił to już by była krótka droga do samopiszących się programówZ gita coś tam ostatnio korzystałem (musiałem), ale jednak nie do końca kumam jak poprawnie łączyć branche (gałęzie) tak, żeby niczego nie spierniczyć, a nawet kumpel praktycznie zawsze jak tylko łączył swój branch z moim to coś tam mu się psuło. Jakbyś tak był w stanie podać bardzo praktycznie i minimum jak wykonywać tę czynność to było by git, bo jak czytałem chociażby ten e-book, który podałeś, to tam jest tyle tego, że po prostu nie ogarniam. No chyba że nie ma czegoś takiego jak "praktycznie i minimum", to jednak sobie odpuszczę, przyjdzie pora na to.
Ujmując to prościej: konfliktyy trzeba rozwiązywać, a nie im zapobiegać I nie są niczym strasznym, widzisz konflikt to otwierasz plik, szukasz miejsc gdzie wystąpił i patrzysz jak te 2 kawałki kodu należy połączyć. Czy z systemem kontroli wersji, czy bez, ktoś ten kod ze sobą połączyć musi, ale z GITem na pewno jest to dużo łatwiejsze. Tym bardziej, że i tak w bardzo wielu sytuacjach sobie radzi sam.
Jak sprawić, by było to łatwiejsze?
po 1. więcej commitów (dla nieobeznanych częściej zapisujemy w repozytorium zmiany, tak w uproszczeniu). Nie robimy wieeeelgachnych commitów uwzględniających wszystko co robiliśmy w danym dniu, ale staramy się każdą zmianę w miarę sprawnie w commit wrzucić i ładnie ofc ten commit opisać.
po 2. warto podzielić projekt na kilka plików, oczywiście według funkcjonalności, a nie według osób należących do projektu, bo to głupota...
po 3. częściej pobieramy kod od kolegi i łączymy ze swoim, a co za tym idzie w parze: staramy się, aby każdy commit nie psuł nic, czyli żeby dało się po każdym uruchomić apkę i przetestować wszystko, co już jest do testowania, ewentualnie ta rzecz której dotyczy może jeszcze nie działać, ale nie powinno to wpłynąć na działanie lub niedziałanie reszty.
I wtedy rozwiązywanie commitów jest dużo łatwiejsze
A do łączenia gałęzi oczywiście służy merge. No i nie musicie pracować na osobnych gałęziach, tu też nie dzielimy na jacka i staszka, ale według jakichśtam zbiorów funkcji i funkcjonalności projektu. Nie trzeba bać się pracy na jednej gałęzi, pull ładnie łączy zmiany.
Git jest właśnie po to, aby nie wymyślać koła na nowo. A mogę jeszcze podać następny worek korzyści. Znając życie tworzysz sobie foldery z "wersjami" kodu, co jest takim jakby zalążkiem kontroli wersji, ale dość marnym. Nigdy się w tym nie zgubiłeś? No więc garść korzyści:Ma nawet wiele. Może nie nawiązuje do kodu który piszemy ale nawiązuje do środowiska w jakim piszemy/możemy pisać dlatego ten temat jest jak najbardziej na miejscu.
Osobista opinia na temat git'u: Dzięi nie skorzystam bo wszystko piszę na jednym kompie (zawsze). A nie mam z kim pisac bym miał to mu przesyłac po każdej zmianie. Nie potrzebne mi sa te gałęzie bo mam na takie przypadki sposoby, także nie widzę sensu korzystania z powracania do dawnego kodu (bynajmniej w moim przypadku). Nie raz pisałem spore projekty i zawsze radziłem sobie na własne sposoby ;D
Ale jak najbardziej polecam bo moja indywidualna opinnia nie ma tu nic do gadania
Widziałem to parę razy w akcji i jest całkiem spoko
1. Jak napisałem 1 poście, mamy wygodę powrócenia do wcześniejszej wersji kodu, gdy tworzymy coś nowego, co jeszcze nie może ujrzeć światła dziennego, ale w starszej wersji kodu trzeba jak najszybciej coś naprawić. Nie dość że to jest prostsze, to jeszcze po stworzeniu tej nowej rzeczy można naprawdę szybko połączyć gałęzie nowej rzeczy i poprawy błędu, co i tak będziesz musiał zrobić. W GITcie zrobi się to praktycznie samo. Także możesz jeszcze w trakcie pracy nad nowym cosiem "przesunąć" sobie gałąź w miejsce w którym poprawiłeś błąd, dzięki czemu fix będziesz już miał rozwiązany w trakcie dopieszczania nowości, bo może mieć on na tą nowość istotny wpływ.
2. Łatwo można się podzielić gotowym kodem z ludźmi i przyjmować od nich nie tylko zgłoszenia błędu, ale także same poprawki. GitHub i Bitbucket to nie tylko serwer na Twój kod, ale też społeczność. Każdy może skopiować Twoje repozytorium (o ile ma do niego dostęp), nanieść jakieś poprawki i później poprzez Pull request (to moim zdaniem powinno być szerzej rozbudowane jako merge request, ale mniejsza z tym) powiedzieć Ci "hej, naprawiłem dość ważny błąd, możesz pobrać tą poprawkę z mojej kopii repozytorium i umieścić w swoim". Gdyby GIT był wśród piszących pluginy pod AMXX popularny, wiele pluginów byłoby dużo lepiej dopracowanych dzięki właśnie takiej łatwości poprawienia czyjegoś kodu
3. Możesz mieć dużo więcej zapisanych wersji kodu. Jak już pisałem, pewnie tworzysz po prostu kopie na dysku co jakiś czas i oznaczasz te kopie wersją, np 1.3, 1.4, 1.5... I ile tych kopii masz? 10? 20? 50? 100? Czy potrafisz ogarnąć takich 100 wersji i znaleźć tą właściwą w której zmieniłeś to i tamto? W GITcie nie ma z tym problemów. Właściwie nie obchodzi Cię ile tych zapisanych wersji (commitów) już masz, ile ich ogólnie utworzyłeś, najlepiej commitować jak najczęściej. Konkretne wersje aplikacji (1.7, 1.8) możesz oznaczyć tagiem przy odpowiednim commicie albo utworzyć dla nich osobną gałąź, to już zależy od Twojej polityki. Jest to przede wszystkim bardzo proste do ogarnięcia.
Jeśli nie korzystasz z GITa, bo go jeszcze tak dobrze nie znasz, czas poznać. Jeśli Ci się po prostu nie spodobał, Twój wybór. Są inne systemy kontroli wersji, może któryś Ci lepiej podpasuje.
No spoko, ale co to robi w dziale Scripting AMXX? sam GIT z amxx'em ma niewiele wspólnego.
A to, że w społeczności tworzącej pluginy AMXX jest bardzo mało rozpowszechnione używanie systemów kontroli wersji. Dlatego właśnie napisałem to tu, a nie w dziale ogólnym o programowaniu czy o PHP nawet. Pisałem ten temat, aby zachęcić osoby tworzące pluginy AMXX do poznania GITa i korzystania z niego. Bo naprawdę szkoda się męczyć
BlackPerfum
28.06.2014
Git jest właśnie po to, aby nie wymyślać koła na nowo. A mogę jeszcze podać następny worek korzyści. Znając życie tworzysz sobie foldery z "wersjami" kodu, co jest takim jakby zalążkiem kontroli wersji, ale dość marnym. Nigdy się w tym nie zgubiłeś? No więc garść korzyści:
Robienie kopii starszych wersji danego kodu to u mnie sporadyczna czynność Zazwyczaj kod jednego projektu rozdrabniam na wiele plików które odpowiadają za dane części całego projektu tzn. bardzo kod rozkładam na pliki (zazwyczaj leci jedna funkcja główna na plik + 0~x (no nie przesadziłem może 0 nigdy nie było) funkcji pobocznych (z których kożystam tylko w tym pliku)), błędy zakomentowuje nie usuwam (oczywiście daje sobie opis dlaczego to jest zakomentowane). Dla mnie takie pisanie jest jak najbardziej przyjemne. Nigdy nie miałem takim sposobem problemów w ogarnianiu a także nigdy się nie pogubiłem nawet po dłuższym czasie braku ingerencji w kodzie. W dodatku często jeden plik z jednego projektu używam do kolejnych 20 innych projektów bez najmniejszego wysiłku bo co to jest plik skopiować i dołączyć bibliotekę Może dam ci mały przykład bo łatwo mnie źle zrozumieć. Użyje twojego przykładu aby pokazać ci jak ja to bym obszedł:
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...
Moje wyjście z sytuacji. Mozliwe są dwa warianty:
A) Błąd znajduje się w tym samym pliku co super fajna rzecz. Sposób postępowania w tym przypadku:
1. Zakomentowuje super fajna rzecz
2. Odkomentowuje starą funkcję
3. Usuwam z niej błąd
B) Błąd znajduje się w innym pliku niż super fajna rzecz. Sposób postępowania w tym przypadku:
1. Zakomentowuje super fajna rzecz
2. Usuwam błąd
Następnie opublikowuje kod bez krytycznego błędu i odkomentowuje super fajna rzecz by skończyć ją pisać
Dlatego argumenty nr. 1 i 3 mnie nie przekonują ale nr. 2 jak najbardziej. Podoba mi się pomysł:
Gdyby GIT był wśród piszących pluginy pod AMXX popularny, wiele pluginów byłoby dużo lepiej dopracowanych dzięki właśnie takiej łatwości poprawienia czyjegoś kodu
który niestety nigdy w życie nie wejdzie (bynajmniej za mojego życia + nie uwierze dopóki nie zobacze)
BlackPerfum
29.06.2014
Nie przesadzajmyno chyba że przesadzisz dość konkretnie z tym.
To zależy np. jeśli to funkcja główna to nie komentuje a odłączam biblioteke i robie nowy plik A jeśli to funkcja poboczna to po zakomentowaniu leci na sam dół pliku i nie sprawia problemu z czytaniem. Problemy mogły by być gdybym nie mógł zakomentowac całej funkcji pobocznej a jej część Wtedy albo kod zakomentowany mocno uszczuplam by nie zajmował dużo linijek albo robie nową funkcję poboczną i wklejam do niej zakomentowany kod (poczym go odkomentowuje + leci na sam dół pliku ale przed kodem zakomentowanym) następnie do funkcji pobocznej (tej z której kod wyciąłem) dołączam w odpowiednim miejscu funkcję (ta którą przed chwilą stworzyłem) którą komentuje Trochę roboty ale mi tak jest naprawdę wygodnie + widze swoje stare błędy i o nich nie zapominamSkoro zachowujesz każdą wersję kodu w komentarzach to musi być tego cholernie dużo w Twoim kodzie, co też niezbyt fajnie się czyta.
Zaskoczę cię mam nawyk do nieusuwaniaPoza tym nie ochroni Cię to przed sytuacją, gdy przypadkiem sobie coś usuniesz z kodu, co czasem pewnie i Tobie się przytrafiło
MOŻEI tych czasów może doczekasz
Ależ oczywiście że spróbuje to znaczy już od dawan mam pare plików na GitHub'ie ale jakoś wielce z niego nie kożystam jedynie do udostępniania (zazwyczaj sobie)
BlackPerfum
29.06.2014
W takim przypadku zakomentowuje w jednym pliku a w reszcie jedynie zmieniam/usuwam dołączoną bibliotekęNo to załóżmy pesymistyczny przypadek:
1. w wielu miejscach już "podłączyłeś" nową rzecz i jest więc w kilku plikach kilka rzeczy do zakomentowania. Żebyś się nie czepiał, że gotowe tylko podłączasz, myślałeś że już gotowe, ale testy wykazały, że jeszcze trzeba cośtam ponaprawiać.
2. Błąd też dość duży i wymaga w kilku miejscach zakomentowania i odkomentowania
3. Dodatkowo jeszcze przerabiamy większość zakomentowanego kodu, aby nie zajmował zbyt dużo linii.
Nigdy mi się taki pesysmistyczny przypadek nie trafił Niestety wielką wadą mojego sposobu jest to iż trzeba parę godzin spędzić nad połapaniem się co gdzie podłączyć i co gdzie umieścić (dla osób nieobeznanych z moim stylem pisania bo mi to jakichś problemów nie robi). Znajomi mi mówią że mój sposób pisania jest irracjonalny ale ja jakoś tego nie łapię.Łączny czas na zmiane we wszystkich plikach dołączonej biblioteki to hmm 30-60 sek w notepad++ opcja podmien we wszystkich plikach (zawsze tak robie) + komentowanie i odkomentowanie bo co to dać w pawnie */ i /* lub to usunąć
A poza tym jak coś umieszczam do głównego kodu to zawsze gdzieś w osobnym sprawdzam czy to działa
Edited by BlackPerfum, 29.06.2014 15:34.
DarkGL
29.06.2014
sam GIT z amxx'em ma niewiele wspólnego.
Świetne narzędzie do zarządzania projektami pluginów / modów