kontrola wersji

kontrola

W dzisiejszym artykule postanowiłem przyjrzeć się tematowi, który często pomijany jest przez kandydatów na programistów. Zrozumienie jego podstaw zajmuje zaledwie kilka wieczorów, a ich wykorzystanie pozwala uniknąć wielu problemów. Z czasem staje się też elementem niezbędnym podczas procesu wytwarzania oprogramowania. Tym razem wypowiem się na temat kontroli wersji.

kontrola wersji

źródło: github

Trudne początki

początek

Jak wspomniałem wyżej, wielu adeptów sztuki programowania początkowo pomija temat kontroli wersji. Powodów może być wiele:

– wolą skupić się na nauce języka lub frameworka;

– uważają, że nie jest to tak istotny obszar wiedzy;

– wydaje się to pogmatwane i trudne.

Nie jestem tu po to, żeby oceniać słuszność takich przekonań. Jednak rezultatem takich wyborów zwykle jest trzymanie kodu na dysku i traktowanie go jak wszystkie inne pliki. Niezależnie od tego, czy tak robisz czy nie możesz natrafić na jeden z tych problemów:

  • Uszkodzenie komputera/dysku i utrata danych

Wbrew pozorom nie trzeba do tego wiele. Dyski mają swoją żywotność i nigdy nie wiesz ile zostało im jeszcze czasu. Mogą też przydarzyć się sytuacje, które same przyspieszą ich koniec. Przykładem może być uderzenie pioruna, czy zwykłe zwarcie lub zalanie. W takim przypadku tracimy nasze dane bezpowrotnie. Oczywiście nie jest to jedyny scenariusz. Bardziej przezorni tworzą backupy
i przechowują je na innych urządzeniach lub chmurze. Nie jest to więc problem nie do rozwiązania bez kontroli wersji, niemniej jednak warto tutaj o nim wspomnieć.

  • Usunięcie ważnej części kodu

Do tej sytuacji może dość na kilka sposobów. W ferworze pracy możesz przypadkowo wcisnąć delete tam gdzie nie trzeba. W wyniku tego usunięte mogą być linie, a nawet pliki. To samo może zrobić Twoje dziecko lub kot. Niezależnie od winowajcy skutki mogą być opłakane. Problem częściowo załatwiają backupy. Jednak te robione ręcznie, wykonywane są rzadziej i nawet najnowszy może być przestarzały. Automatyczne natomiast aktualizują się same, istnieje więc duże ryzyko, że informacja o usunięciu też zostanie zapisana. Problem wymaga więc bardziej zaawansowanego rozwiązania.

  • Poprawienie działającej wersji kodu na błędną

To też zdarzyło się pewnie nie jednemu. Powrót do poprzedniego stanu kodu może być problematyczny lub czasochłonny. Szczególnie gdy zmian jest dużo lub nie pamięta się poprzedniej implementacji.

  • Praca nad jednym projektem na kilku urządzeniach

Może Ci się zdarzyć, że nad kodem będziesz pracował na kilku urządzeniach, np.: na laptopie na uczelni i na komputerze stacjonarnym w domu. Niektóre firmy pozwalają rozwijać własne projekty w czasie, gdy oczekujesz na projekt – to już trzeci komp. Prywatne komputery możesz dowolnie wykorzystywać i przenosić swoje dane za pomocą pen drive, dysku, czy chmury. Komputer firmowy nie jest jednak dobrym miejscem do synchronizacji prywatnych plików z OneDrive czy GoogleDrive. Co więcej firmy często zabezpieczają się przed potencjalną infekcją i blokują możliwość korzystania z zewnętrznych nośników danych.

  • Współpraca z innymi programistami rozwijającymi jednocześnie tą samą aplikację

Ostatni problem jest rozwinięciem poprzedniego z dodatkowym utrudnieniem. We wcześniejszym przykładzie omawiałem przypadek, w którym nad kodem pracuje jedna osoba. Łatwo więc kontrolować wprowadzane zmiany. Co jednak w sytuacji, gdy w takim samym czasie program rozwija 2 lub więcej osób? Jak połączyć wszystkie wersje oprogramowania, z których każda jest poprawna? Pomijając rozwiązanie jakie mam zamiar Ci zaproponować, nie znam żadnego innego, które by temu podołało.

Przestraszony? Przyznam, że moim celem było zobrazowanie Ci ryzyka, jakie podejmują osoby nie korzystające z kontroli wersji. Jeśli będąc ich świadomym nie jesteś zainteresowany kontrolą wersji – szanuję to 🙂 Możesz jednak zamknąć kartę w przeglądarce z tym artykułem, bo raczej nie znajdziesz tutaj niczego dla siebie.

Sposób działania kontroli wersji

pomysł

Jeśli zostałeś, zastanówmy się jak działa mechanizm kontroli wersji. Zacznę jednak od małego disclaimera. Istnieje wiele różnych systemów kontroli wersji. W tym wpisie będę skupiał się głównie na jednym o nazwie Git. Mogę więc zamiennie używać tych terminów. Miej to proszę na uwadze. Na Gita zdecydowałem się ponieważ w pracy z nim mam największe doświadczenia, a dodatkowo jest on obecnie najpopularniejszy. Istnieje więc spora szansa, że to właśnie z nim przyjdzie Ci pracować. Pamiętaj jednak o tym, że istnieją też inne systemy kontroli wersji takie jak: SVN, Mercurial, CVS. Przejdźmy teraz do konkretów. System kontroli wersji wprowadza kilka pojęć, które wypada zrozumieć, są to:

  • Origin  źródło kodu. Zwykle znajduje się na serwerze, skąd mogą go pobrać wszyscy uprawnieni użytkownicy.
  • Branch – służy do rozdzielenia oprogramowania – kod na branchu można modyfikować niezależnie od źródłowego brancha, z którego został stworzony. Najważniejszym branchem jest tzw. master, zawierający poprawną wersję aplikacji. Co mam przez to na myśli? A to, że master powinien zawierać jedynie dokończony, przetestowany i pokryty testami jednostkowymi kod, który ma najmniejszą szansę na to, że jest w nim błąd. Warto wspomnieć o tym, że wyróżnia się branche znajdujące się na serwerze (origin) oraz utworzone z nich lokalne (na dysku komputera). Zwykle śledzą swoje zmiany nawzajem.
  • Commit– jeśli będąc na lokalnym branchu modyfikujesz kod, to nie jest on widoczny
    w systemie kontroli wersji. W celu wprowadzenia tych zmian musisz wykonać commit. Jest to wiadomość zawierająca zmiany wprowadzone od ostatniego commita, a więc nowe
    i usunięte pliki, czy modyfikacje istniejących. Dodatkowo każdy commit ma metadane: datę, id, autora, treść (ang. commit message), opisującą zmiany w nim wprowadzone.
  • Pull – operacja niezbędna do synchronizacji Z brancha origin DO lokalnego. Pobiera wszystkie zmiany wprowadzone przez osoby, które równolegle z nami pracują nad kodem, na tym samym branchu.
  • Push – przeciwieństwo operacji pull. Synchronizuje wersję lokalną do zmian przechowywanych na serwerze. Przed wykonaniem pusha, kod w lokalnej wersji musi posiadać wszystkie modyfikacje wprowadzone przez innych na serwer (musisz wykonać pull).
  • Conflict – sytuacja, kiedy linia kodu na originie różni się od lokalnej, a system sam nie jest
    w stanie zdecydować, która wersja jest poprawna. Konflikt rozwiązuje się za pomocą dodatkowego oprogramowania- przeczytasz o nim niżej.
  • Merge – ta operacja ma za zadanie scalić kod z dwóch, niezwiązanych ze sobą branchy. Zawsze wykonuje się ją na branch, na którym aktualnie się znajdujesz.

Przykład

Powyżej omówiliśmy podstawowe definicje elementów i operacji używanych przez Gita. Domyślam się, że jeśli dopiero zaczynasz może być to dla Ciebie niejasne. Omówimy to na przykładzie:

Pracujesz w projekcie, który rozwija oprogramowanie dla kin (opisywałem je w tym poście). Twoim zadaniem jest stworzenie funkcjonalności do rezerwacji miejsc. Patrząc z perspektywy kontroli wersji, przedstawię Ci kroki, które powinieneś wykonać, żeby wykorzystać jej potencjał. Na mastrze znajduje się wersja oprogramowania, której nie ruszasz. Wszystkie zmiany (przed dodaniem do mastera) wrzucane są ostatecznie na branch dla programistów, zwykle nazywany develop – ten musisz mieć w lokalnej wersji – zrobić checkout. Do wprowadzenia swoich zmian tworzysz nowy branch z developa. W początkowym stanie są one sobie równe. Będąc na nowym branchu wprowadzasz wszystkie zmiany związane ze swoim zadaniem. Jeśli równocześnie z Tobą, na tym branchu pracują inni – okazjonalnie wykonuj pull. Po zakończeniu implementacji wykonaj commit, możesz też commitować zmiany partiami. Aby wrzucić dane na origin wykonaj push. Kod ostatecznie musi trafić na developa, w tym celu musisz wykonać merge, jeśli to potrzebne rozwiąż konflikty. Gotowe.

Jak widzisz korzystanie z systemu kontroli wersji wymaga postępowania według pewnego algorytmu. Oczywiście ten, który Ci tutaj przedstawiłem jest jedynie przykładowy. Istnieją już gotowe rozwiązania, a w rzeczywistości każdy zespół wypracowuje swoje własne zasady. Zdarza się też, że sposób korzystania narzucony jest przez klienta.

Korzyści z używania kontroli wersji

Jeśli popatrzymy na problemy, które omawiałem na początku artykułu – wyraźnie widać, że kontrola wersji może je wyeliminować:

Utrata danych – w przypadku używania gita i jemu podobnych, jedyne co możemy stracić to lokalną kopię danych. Całość przetrzymywana jest na serwerze, który z pewnością wdrożył więcej standardów zabezpieczających przed utratą danych, jak np.: regularne backupy, replikacja danych, itp.

Usunięcie kodu/poprawienie na błędną wersję – powrót do właściwej implementacji trwa kilka sekund. Dzięki funkcjonalności commitów, możemy przywrócić kod do dowolnego
z nich, stosując odpowiednie polecenia systemu kontroli wersji

Łączenie plików niezależnie rozwijanych przez różnych programistów i/lub na różnych urządzeniach też załatwione jest w prosty sposób. Zależnie od scenariusza wystarczy użyć pull lub merge. Oczywiście jak pisałem wcześniej mogą pojawić się konflikty – jednak git radzi sobie z nimi całkiem nieźle, samodzielnie rozwiązując wiele z nich.

Podsumowanie

Dzisiejszy wpis miał na celu zapoznanie z tematyką świata kontroli wersji. Mam nadzieję, że bardziej zachęciłem niż zniechęciłem 🙂 Daj znać w komentarzu, czy i z jakim systemem wersji miałeś okazję pracować. Jakie są Twoje wrażenia? Jeśli temat Cię zainteresował to od razu dam znać, że kolejny artykuł będzie kontynuacją tego. Skupię się w nim na bardziej technicznym aspekcie kontroli wersji, więc myślę, że warto zaczekać tydzień. Jeśli artykuł był dla Ciebie wartościowy, to śmiało puść go
w świat dalej, przyciski jak zwykle poniżej, z góry dziękuję 🙂

Please follow and like us:

Dodaj komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.