Repozytoria i systemy kontroli wersji

Panowanie nad danymi w projekcie w najlepszym możliwym wydaniu

Dziś o tym, o czym na pewno powinien wiedzieć każdy programista, ale wydaje mi się, że nie tylko tylko techniczni specjaliści mogą skorzystać z tego narzędzia.

Zobacz też: „zwinny projekt – zwinne życie”

Dzisiaj trochę dokładniej przybliżę pojęcie repozytoriów i systemu kontroli wersji, bo oba tematy są wręcz nierozłączne. Pisząc o projekcie mam na myśli nie tylko oprogramowanie, choć w tej dziedzinie najłatwiej myśleć o pojęciu repozytorium i o systemie kontroli wersji, ale też o wszelkiej dokumentacji jakiegoś urządzenia, jego schematach, czy też samych tekstach albo arkuszach kalkulacyjnych.

Potem jak tu się domyślić co gdzie jest /:

Zacznę od tego czym są systemy kontroli wersji. Jeśli prowadziliście jakiś projekt dobrze wiecie, że po wstępnym stworzeniu czegoś nastaje czas poprawek i zmian, które trwają do tak zwanej „śmierci projektu” – czasu, kiedy już nikt nie korzysta nawet z jego efektów. Podczas realizacji projektu co jakiś czas „wypychamy” jakieś efekty, czyli przesyłamy jakąś wersję tego, co robimy. Wersję, w której ciągle dokonujemy jeszcze zmian. Każda zmiana wiąże się z kolejnym przesłaniem wersji (jej podbijaniem). W rozbudowanych projektach z jednej pierwotnej wersji wyrasta kilka równolegle utrzymywanych wersji roboczych lub gotowych efektów. Tę swoistą „sieć” wersji nazywamy gałęziami (choć częściej spotykamy się z angielskim określeniem „branch”). Ważne, że drzewo, które – jak sobie wyobrażamy – powstaje z zależności między jedną wersją a drugą, jest pewną hybrydą. Poszczególne jego gałęzie potrafią się z powrotem łączyć – z angielskiego taka operacja nazywana jest „merge”. Szczególnym branchem w tym drzewie jest nasza główna, stabilna wersja zwana „trunk”.

Stosowane systemy kontroli wersji dają nam możliwość zapisania całego projektu w danej wersji, a jednocześnie pozwalają uniknąć utracenia poprzedniej wersji czy konieczności tworzenia osobno każdej następnej. Taki zapis nazywamy (z angielskiego) „commit”. Warto, aby taka zapisana wersja była dobrze opisana, aby czytelnym było, co zmieniło się w stosunku do poprzedniej wersji. W tak prowadzonym projekcie mamy możliwość powrotu do określonej wersji czy koncepcji, którą zmieniliśmy z jakiegoś powodu. Dodatkowo, mamy możliwość oznaczania tak zwanych „kamieni milowych” czy tagów, to znaczy bardzo charakterystycznych i istotnych zmian w naszym projekcie.

System kontroli wersji jest funkcjonalny jeśli pracujemy nad niedużym projektem, jeśli pracujemy sami na jednym stanowisku. Trzeba pamiętać o tym, że zmiany czy wersje danego projektu należy gdzieś przechować, zabezpieczeniem przed utratą danych jest z pewnością ich przechowywanie w kilku miejscach. Dobre przechowywanie danych umożliwia też ich szybkie przesyłanie, przeglądanie i pobieranie. Tutaj przyda się właśnie repozytorium, które jest czymś w rodzaju chmury, dysku sieciowego, ale ma pewne charakterystyczne cechy. Systemy kontroli wersji na szczęście świetnie się z tego typu miejscami łączą. Repozytoria są takim miejscami, w których przetrzymujemy nasz projekt, a także miejscami, w których odtwarzamy dokładnie ten przebieg wersji, jaki zaistniał lokalnie. Proces ten nazywamy synchronizacją wersji lokalnej i repozytorium. I tutaj ma zastosowanie terminologia zaczerpnięta z języka angielskiego – „push” czyli dodanie tego, co zrobiliśmy lokalnie do tego, co jest w repozytorium i „pull” czyli dołączenie tego, co jest w repozytorium do naszej lokalnej wersji. System kontroli wersji oraz repozytorium proponuje nam wiele udogodnień. Kiedy dodajemy coś lub pobieramy, dostajemy informację, które pliki się zmieniły, a nawet możemy dostać dokładną linię w tekście/kodzie, która się zmieniła.

Teraz warto przejść do podania konkretnych przykładów systemów oraz repozytoriów. Oczywiście jest ich więcej niż tutaj pokażę, ale te są najpopularniejsze.

Git

Chyba najbardziej popularny, często korzysta się z niego z poziomu wiersza poleceń, ale ma także wersję GUI (okienkową/graficzną). Jeśli ktoś jest programistą to często IDE (środowiska, w których tworzy się oprogramowanie) mają wbudowanego gita i można korzystać z jego funkcjonalności już na tym poziomie. Jeśli chcecie nauczyć się obsługi gita, szczególnie tego z poziomu konsoli, to tutaj znajdziecie fajny wstępny kurs.

GitHub

Już po nazwie można zgadnąć, że to narzędzie jest kompatybilne z Gitem. Repozytorium to jest znane chyba najbardziej fanom open source (czyli otwartych, darmowych źródeł). Na Githubie możemy założyć konto darmowo i od razu zacząć pracować z teamem nad projektem. Jeśli będziemy chcieli, aby nasze kody nie były ogólnie dostępne, wtedy będziemy musieli dopłacić. Tutaj mamy też możliwość ściągnięcia gotowego narzędzia GUI, w którym mamy i Gita, i od razu dostęp do naszych projektów na GitHubie.

SVN

Ten system kontroli wersji jest częściej używany w większych korporacjach z tym, że tam pliki często lądują na serwerze umieszczonym w firmie. Choć to tylko trend który zaobserwowałem a nie reguła. Do obsługi SVN możemy stosować wersję Tortoise stworzoną specjalnie pod ten system.

Mercurial

System kontroli wersji trochę mniej popularny niż Git, ale bardzo podobnie działający. Jest to kolejny system, z którego możemy korzystać dzięki Tortoisowi (ale w wersji hg).

BitBucket

Repozytorium od Atlassian czyli firmy zajmującej się Jirą. Możemy za darmo tworzyć projekty prywatne, dopłata jest wymagana dopiero przy zwiększeniu członków teamu (powyżej 5 osób), który będzie działał nad projektem. Dobrze łączy się z Gitem i Mercurialem. Daje też swoją aplikacje GUI: Source Tree, która pracuje nie tylko z repozytoriami BitBucketowymi

Można jeszcze wspomnieć o rosnących rozwiązaniach takich jak Visual Studio Team Foundation i Team Services, gdzie mamy zaszyte funkcjonalności Gita oraz skojarzenie projektu z repozytoriami. Tutaj można poczytać więcej.

Powyższe narzędzia opisuję tylko pokrótce, zdania co do nich są bardzo podzielone, które lepsze. Mimo to zachęcam do poznania nie tylko jednego i ogólnego zgłębienia tematu, bo wbrew pozorom to spory kawał wiedzy i możliwości. W życiu możliwe że spotkacie się z rozwiązaniami, gdzie repozytorium będzie lokalnie, tworzone na różne sposoby, może narzędzia takie jak git będą obudowane w dodatkowe wtyczki, ale najważniejsze żeby nabrać dobrych nawyków w korzystaniu (:

Mając wybrany zestaw narzędzi tworzymy dobrze opisane repozytorium, dzięki systemowi kontroli wersji kojarzymy je z folderem na naszym komputerze. Po każdej fali zmian dokonujemy „commita” (zapisu), a następnie „push”(dodanie wersji lokalnej do repozytorium) do „brancha” (gałęzi wersji), nad którym obecnie pracujemy i „merge” (połączenie) z „trunkiem” (ze stabilną wersją). Dzięki takim działaniom, możemy prowadzić projekt bezpiecznie (nie bojąc się zmian) i wygodnie – dzięki możliwości sprawnego poruszania się między wersjami.

Jeśli artykuł w jakiś sposób Tobie pomógł , możesz wpierać blog, aby nowych materiałów przybywało więcej. Zapraszam TUTAJ.