Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

System kontroli wersji. Podstawa dla sprawnego realizowania projektów.

Wstęp

Poniższy wpis, mam nadzieję, znajdzie zastosowanie dla każdego kto zdecyduje się kiedykolwiek napisać artykuł, sprawozdanie, wypracowanie, raport, kod etc.
Wszędzie tam gdzie nad projektem pracuje więcej niż jedna osoba zastosowanie znajduje System Kontroli Wersji (VCS). W pracy zespołowej VCS jest niemal koniecznością, przy pracach solo jest dobrą praktyką, która nie raz zaoszczędzi Wam, Drodzy Czytelnicy, godzin pracy i trochę nerwów.

Ale o co chodzi?

W telegraficznym skrócie. Każdy uczestnik pracy może w dowolnym czasie prześledzić historię zmian projektu, ew. przywrócić wcześniejsze jego wersje.

Jak to działa?

Najprostsze systemy systemy działają według nstępującego schematu. Na serwerze (w katalogu archiwum, w NAS, w jakiejkolwiek zdefiniowanej lokalizacji) przechowywane są kolejne pliki, z których każdy kolejny jest nowszą wersją. W celu edycji pobieramy najnowszy plik później odsyłamy go z powrotem, a narzędzie VCS automatycznie zapisuje go jako kolejną wersję. Taki system ma jedno główne ograniczenie. Nie jest możliwa symultaniczna praca na jednym pliku. Oczywiście w wielu sytuacjach nie jest to żadną przeszkodą, np. przy pracy nad projektem w autoCADzie.
VCS jest standardem we wszystkich edytorach dokumentów online (od Google Docs przez Evernote po Office365). Również pakiety MS Office od wersji 2007 mają wbudowany system VCS (do włączenia w ustawieniach). Istnieje też szeroki wachlarz programów do kontroli wersji. Jednym z ciekawszych rozwiązań dla Windows jest TortoiseSVN, który bazuje na Apache Subversion. Jego główną zaletami są darmowa licencja dla zastosowań komercyjnych, i prosta konfiguracja (zajmie max.6 minut).

Wszystko pięknie ale po co się tym zajmować?

Takie pytanie stawia sobie każdy kto zaczyna swoją przygodę z zarządzaniem projektem. Zwyczajnie wydaje się to dodatkową pracą, która do tego nie ma oczywistych zalet.

Powody dla których grupy projektowe nie wdrażają (względnie nie korzystają) z VCS

  • Trzeba włożyć wysiłek w know-how.
  • Z przyzwyczajenia. Przecież każdy w biurze wie co i kiedy robił, wystarczy spytać.
  • Zwyczajnie nigdy o VCS nie usłyszeli.

Zalety VCS

System kontroli wersji ma trzy główne zalety:
  1. Ułatwia zarządzanie projektem. Można sprawdzić kto, kiedy i dlaczego zmienił projekt.
  2. Zabezpiecza projekt. Archiwum służy jako kopia zapasowa.
  3. Archiwum zostaje bankiem pomysłów. Swobodnie można powracać do wcześniej porzuconych pomysłów/koncepcji.

Podsumowanie

VCS zabezpiecza i ułatwia pracę nad projektem. Daje wgląd w historię prac, możliwość powracania do wcześniejszych wersji. Niezależnie od wdrożonego systemu w naturalny sposób organizuje pracę grupy, ale także ją usprawnia i pozwala na luźniejszą organizację pracy. Członkowie zespołu nie są potrzebni by określać które wersje plików są finalne, rolę tę przejmuje VCS. Z łatwością przywrócimy wcześniejszą wersje projektu (tę opcje doceni, każdy kto będzie miał do czynienia z niezdecydowanym klientem ;)

PS.

Jest to mój pierwszy wpis tutaj. będę wdzięczny za każdą uwagę :)  

bezpieczeństwo porady inne

Komentarze

0 nowych
LordRuthwen   5 #1 09.06.2016 08:23

Git jest git i polecam każdemu pracującemu z plikami tekstowymi (źródła, konfiguracje czy cokolwiek innego), docenicie gdy będziecie szukać jakichś zmian :P

wojtekadams   18 #2 09.06.2016 10:04

@LordRuthwen: zgadzam się. Teraz już tylko Git + gerrit

Autor edytował komentarz w dniu: 09.06.2016 10:05
Frankfurterium   9 #3 09.06.2016 19:19

Git to najlepszy ale nie jedyny dobry wybór. Grunt żeby system działał w rozproszeniu. Przy prostszym flow i mniej wprawnych użytkownikach Mercurial sprawdzi się równie dobrze. Ale dzięki bardziej zaawansowanym ficzerom Gita (rebase, squash, ogólnie "zmienianiu historii") i kulturze użytkowania repozytorium wygląda składnie nawet przy sporej liczbie commitujących.

DjLeo MODERATOR BLOGA  17 #4 09.06.2016 19:38

Pierwszy wpis udany ;) Witaj w gronie blogerów ;)

kwpolska   5 #5 09.06.2016 21:19

Subversion dawno wymarł, dzisiaj się głównie Gita używa.

Vidivarius   13 #6 09.06.2016 23:12

@rzabro
Hej kolego. Wpis w sam raz pod moje zainteresowania :) Mam nadzieję, że pociągniesz to zagadnienie, włącznie z jakimiś łopatologicznymi przykładami. W szczególności zainteresowany jestem wersojonowaniem plików Ms Office.

Autor edytował komentarz w dniu: 10.06.2016 10:34
grapeli23   5 #7 10.06.2016 03:25

Mercurial to jedynie kopia gita. Są na tyle skrupulatni w powielaniu kodu, że przenoszą też i jego błędy. Choćby dość znaną podatność, występującą na systemach plików case-insensitive.

rzabro   2 #8 10.06.2016 13:52

@Vidivarius: temat cieszy się zainteresowaniem, w planie mam dwa kolejne wpisy. Jeden szczegółowo opisujący architektury CVCS, LVCS i DVCS. Następny będzie już konkretnym poradnikiem dla rozwiązania który będzie się cieszył największym zainteresowaniem. ;)

rzabro   2 #9 10.06.2016 13:57

@grapeli23: Tutaj nie chodzi tyle o kopię co o architekturę rozwiązania. Mianowicie Distributed Version Control System. Przedstawicielami tej rodziny systemów kontroli wersji są właśnie Git i Mercurial ale też Bazaar czy Darcs. Wydaje się że to właśnie stąd wynikają podobieństwa wszystkich tych rozwiązań (również błędów).

Autor edytował komentarz w dniu: 10.06.2016 13:58
Axles   16 #10 13.06.2016 12:07

LibreOffice sam w sobie też zawiera tego typu mechanizm do kontroli wersji, a raczej poczynionych zmian, choć nie każdy o tym wie i z tego korzysta, a warto.

  #11 14.06.2016 09:07

O cos ciekawego bedzie. Trzymam kciuki za kolejne wpisy :-)