Skocz do zawartości

  • Zaloguj korzystając z Facebooka Zaloguj korzystając z Twittera Zaloguj przez Steam Zaloguj poprzez Google      Logowanie »   
  • Rejestracja

Witamy w Nieoficjalnym polskim support'cie AMX Mod X

Witamy w Nieoficjalnym polskim support'cie AMX Mod X, jak w większości społeczności internetowych musisz się zarejestrować aby móc odpowiadać lub zakładać nowe tematy, ale nie bój się to jest prosty proces w którym wymagamy minimalnych informacji.

  • Rozpoczynaj nowe tematy i odpowiedaj na inne
  • Zapisz się do tematów i for, aby otrzymywać automatyczne uaktualnienia
  • Dodawaj wydarzenia do kalendarza społecznościowego
  • Stwórz swój własny profil i zdobywaj nowych znajomych
  • Zdobywaj nowe doświadczenia

Dołączona grafika Dołączona grafika

Guest Message by DevFuse
 

Zdjęcie

Dlaczego warto korzystać z GITa?Czyli jak sobie nie utrudniać pracy.


  • Nie możesz napisać tematu
  • Zaloguj się, aby dodać odpowiedź
8 odpowiedzi w tym temacie

#1 GwynBleidD

    Godlike

  • Administrator

Reputacja: 1849
Godlike

  • Postów:3066
  • Steam:steam
  • Lokalizacja:Przemyśl
Offline

Napisano 27.06.2014 15:44

*
Popularny

Czym jest GIT?
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
I co najważniejsze, wszystkiego z tej listy można używać zamiennie. Nie jest nigdy tak, że jeśli używacie 1 rzeczy tu już innych się nie da, bo każda z aplikacji działa tak naprawdę poprzez komendy linii poleceń, więc są w 100% kompatybilne ze sobą.

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 :)
  • +
  • -
  • 12
NIE pomagam na PW. Nie trudź się, na zlecenia nie odpiszę... Od pomagania jest forum.
NIE zaglądam w tematy wysłane na PW. Jeśli są na forum to prędzej czy później je przeczytam. Jeśli mam co w nich odpisać, to odpiszę.
 
1988650.png?theme=dark

#2 sebul

    Godlike

  • Junior Admin

Reputacja: 2016
Godlike

  • Postów:5411
  • Steam:steam
  • Imię:Sebastian
  • Lokalizacja:Ostrołęka
Offline

Napisano 27.06.2014 20:08

Z 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.

No spoko, ale co to robi w dziale Scripting AMXX? biggrin.png sam GIT z amxx'em ma niewiele wspólnego.

Jakby nie patrzeć coś tam wspólnego ma.
  • +
  • -
  • 0
Posiadam TBM (inaczej PTB), które działa dużo lepiej niż zwykłe PTB, nawet na modach z lvlami. Zainteresowany? Proszę bardzo
Generator tabeli expa - aż do 103600 poziomu

#3 BlackPerfum

    Pseudo interakcja??

  • Power User

Reputacja: 453
Wszechobecny

  • Postów:575
  • Lokalizacja:...
Offline

Napisano 27.06.2014 20:18

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 xD
Widziałem to parę razy w akcji i jest całkiem spoko xD
  • +
  • -
  • 0
Chcesz napisać do mnie na PW to:
Spoiler

Mój tok myślenia jest błędny? Wskaż mi błąd zmienie to!

Aktualnie bije limit 32 graczy (łącze serwery) ale nadal są lagi przy zbyt dużym przesyłu informacji Dołączona grafika
Gra się płynnie do 40~50 graczy potem łącze pada i zamiast biegać ludzie się teleportują Dołączona grafika

#4 Puchate

    Wszechobecny

  • Użytkownik

Reputacja: 198
Profesjonalista

  • Postów:432
  • Lokalizacja:Polska
Offline

Napisano 28.06.2014 01:56

Sama nazwa mówi że jest GIT. ;)

 

Bez kontroli wersji łatwo jest pogubić starsze wersje i problem jest gdy projekt ma się rozgałęźniać :)


Użytkownik Puchate edytował ten post 28.06.2014 01:57

  • +
  • -
  • 0

#5 GwynBleidD

    Godlike

  • Autor tematu
  • Administrator

Reputacja: 1849
Godlike

  • Postów:3066
  • Steam:steam
  • Lokalizacja:Przemyśl
Offline

Napisano 28.06.2014 22:50

Z 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.

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ów :)

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.
 

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 haha.gif
Widziałem to parę razy w akcji i jest całkiem spoko haha.gif

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:

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? biggrin.png 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ć :)
sebul (29.06.2014 01:05):

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.

No akurat u nas było tak, że kolega zajmował się wyglądem (front), a ja działaniem (back).
GwynBleidD (29.06.2014 02:00):
To o jakich Ty problemach mówisz, skoro to są 2 oddzielne rzeczy? Tu nawet 1 pliku wspólnego nie powinniście mieć

  • +
  • -
  • 0
NIE pomagam na PW. Nie trudź się, na zlecenia nie odpiszę... Od pomagania jest forum.
NIE zaglądam w tematy wysłane na PW. Jeśli są na forum to prędzej czy później je przeczytam. Jeśli mam co w nich odpisać, to odpiszę.
 
1988650.png?theme=dark

#6 BlackPerfum

    Pseudo interakcja??

  • Power User

Reputacja: 453
Wszechobecny

  • Postów:575
  • Lokalizacja:...
Offline

Napisano 28.06.2014 23:49

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ść biggrin.png 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ę biggrin.png 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 sad.png (bynajmniej za mojego życia + nie uwierze dopóki nie zobacze)


GwynBleidD (29.06.2014 02:05):
Twój sposób akurat ma też wady. Nie mówię tutaj o rozdzielaniu na pliki, bo to jest jak najbardziej OK, no chyba że przesadzisz dość konkretnie z tym.

Mówię tu o wykomentowaniu tego i tamtego. Skoro zachowujesz każdą wersję kodu w komentarzach to musi być tego cholernie dużo w Twoim kodzie, co też niezbyt fajnie się czyta. Poza tym nie ochroni Cię to przed sytuacją, gdy przypadkiem sobie coś usuniesz z kodu, co czasem pewnie i Tobie się przytrafiło. Spróbuj przynajmniej jak się używa GITa gdy pracujesz sam przy projekcie.

Co do ostatniego, dużo by już dało gdyby choć te największe projekty były na GITcie przechowywane, jak Cod mod, zombie, AMX Bans... I tych czasów może doczekasz :)

  • +
  • -
  • 0
Chcesz napisać do mnie na PW to:
Spoiler

Mój tok myślenia jest błędny? Wskaż mi błąd zmienie to!

Aktualnie bije limit 32 graczy (łącze serwery) ale nadal są lagi przy zbyt dużym przesyłu informacji Dołączona grafika
Gra się płynnie do 40~50 graczy potem łącze pada i zamiast biegać ludzie się teleportują Dołączona grafika

#7 BlackPerfum

    Pseudo interakcja??

  • Power User

Reputacja: 453
Wszechobecny

  • Postów:575
  • Lokalizacja:...
Offline

Napisano 29.06.2014 12:52

no chyba że przesadzisz dość konkretnie z tym.

Nie przesadzajmy haha.gif
 

Skoro zachowujesz każdą wersję kodu w komentarzach to musi być tego cholernie dużo w Twoim kodzie, co też niezbyt fajnie się czyta.

To zależy np. jeśli to funkcja główna to nie komentuje a odłączam biblioteke i robie nowy plik haha.gif 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ęść kwasny.gif 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 biggrin.png Trochę roboty ale mi tak jest naprawdę wygodnie + widze swoje stare błędy i o nich nie zapominam
 

Poza tym nie ochroni Cię to przed sytuacją, gdy przypadkiem sobie coś usuniesz z kodu, co czasem pewnie i Tobie się przytrafiło

Zaskoczę cię mam nawyk do nieusuwania biggrin.png

 

I tych czasów może doczekasz smile.png

MOŻE

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)
GwynBleidD (29.06.2014 15:15):
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.

Efekt: 10 minut nie Twoje na samo przygotowanie się do poprawienia błędu. Używając GITa:
git commit # dla zapisania bieżących zmian, ewentualnie git stash jeśli nie chcesz ich commitować, ale też nie chcesz tracić
git checkout master # na gałąź główną
git checkout -b bugs/ence-pence # tworzenie nowej gałęzi na której poprawimy błąd (nazwa ofc gałęzi dowolna, ale polecam dzielić na foldery, w tym przypadku folder bugs)

i jesteśmy gotowi do poprawienia błędu :) Po poprawieniu
git checkout master # wracamy na gałąź główną
git merge bugs/ence-pence # łączymy gałąź fixa błędu z gałęzią główną
git checkout new-thing # wracamy do pracy nad nową rzeczą
git stash pop # ewentualnie pobieramy kod ze stosu (tak, to dosłownie jest stos) jeśli go nie commitowaliśmy

Oczywiście brakuje tutaj commitowania poprawy błędu, a to dlatego, że commitów może być kilka, więc to wedle uznania.

Łącznie czas na przełączenie się na gałąź naprawy błędu i wrócenie spowrotem po jego naprawieniu to jakaś minuta.

  • +
  • -
  • 0
Chcesz napisać do mnie na PW to:
Spoiler

Mój tok myślenia jest błędny? Wskaż mi błąd zmienie to!

Aktualnie bije limit 32 graczy (łącze serwery) ale nadal są lagi przy zbyt dużym przesyłu informacji Dołączona grafika
Gra się płynnie do 40~50 graczy potem łącze pada i zamiast biegać ludzie się teleportują Dołączona grafika

#8 BlackPerfum

    Pseudo interakcja??

  • Power User

Reputacja: 453
Wszechobecny

  • Postów:575
  • Lokalizacja:...
Offline

Napisano 29.06.2014 15:31

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.

W takim przypadku zakomentowuje w jednym pliku a w reszcie jedynie zmieniam/usuwam dołączoną bibliotekę haha.gif
Nigdy mi się taki pesysmistyczny przypadek nie trafił sad.png 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ąćhaha.gif

A poza tym jak coś umieszczam do głównego kodu to zawsze gdzieś w osobnym sprawdzam czy to działa biggrin.png

Użytkownik BlackPerfum edytował ten post 29.06.2014 15:34

  • +
  • -
  • 1
Chcesz napisać do mnie na PW to:
Spoiler

Mój tok myślenia jest błędny? Wskaż mi błąd zmienie to!

Aktualnie bije limit 32 graczy (łącze serwery) ale nadal są lagi przy zbyt dużym przesyłu informacji Dołączona grafika
Gra się płynnie do 40~50 graczy potem łącze pada i zamiast biegać ludzie się teleportują Dołączona grafika

#9 DarkGL

    Nie oddam ciasteczka !

  • Administrator

Reputacja: 6033
Godlike

  • Postów:10825
  • GG:
  • Steam:steam
  • Imię:Rafał
  • Lokalizacja:Warszawa
Offline

Napisano 29.06.2014 19:17

sam GIT z amxx'em ma niewiele wspólnego.

 

Świetne narzędzie do zarządzania projektami pluginów / modów ;)


  • +
  • -
  • 0




Użytkownicy przeglądający ten temat: 0

0 użytkowników, 0 gości, 0 anonimowych