Kursy • Poradniki • Inspirujące DIY • Forum
Pracowałeś nad większym projektem i bałeś się przystępować do większych zmian w kodzie?
Zaśmiecałeś dysk folderami typu projekt1, projekt2. Wykomentowywałeś duże bloki kodu, żeby dało się je szybko przywrócić jeśli coś przestanie działać? Czas na wprowadzenie systemu kontroli wersji Mercurial!
Dzięki doświadczeniu, uwadze i pomysłowości znajdowałeś sposoby na przezwyciężenie tego typu problemów.
Jednak rozwiązania prowizoryczne wiązały się z dodatkową stratą czasu i nigdy nie było pewności, że o czymś nie zapomnisz i nie stracisz swojej pracy.
Okazuje się, że jest proste rozwiązanie tego typu problemów - systemy kontroli wersji (angielskie nazwy - Version Control, Revision Control, Source Control).
Kontrola wersji polega na zapisywaniu historii zmian jakie zaszły w poszczególnych plikach projektu. Dzięki temu dostajemy możliwość cofania zmian jeśli okazały się błędne. Jeżeli skasujemy jakieś pliki albo uszkodzimy projekt, możliwe jest jego odtworzenie.
Zmiany są zapisywane w blokach, dzięki czemu np. zmiana nazwy funkcji w pliku c i odpowiadającym mu pliku .h może być logicznie traktowana jako jedna zmiana.
Pakiety zmian są archiwizowane i przechowywane na serwerze (może być to także serwer lokalny), dlatego zmian może dokonywać kilka osób na raz. Możliwe jest również dzielenie projektu na gałęzie skupiające się na dodaniu konkretnych funkcjonalności czy usunięcie błędów. Następnie mogą być one dołączone z powrotem do gałęzi głównej tak, aby wynikowy kod zawierał funkcjonalności dodane w każdej z tych gałęzi.
Rozwiązanie nie jest nowe. Pierwsze tego typu systemy powstawały już w latach siedemdziesiątych. Od tego czasu zdążyły się znacząco rozwinąć i są podstawowym narzędziem na wyposażeniu każdej firmy zajmującej się programowaniem.
Co więcej nawet najlepsze systemy tego typu są całkowicie darmowe. Ale sytuacja np. na uczelniach jest bardzo podobna jak w przypadku innych dobrych praktyk programistycznych. Po co o tym wspominać, niech się sami męczą, niech wyrabiają sobie złe nawyki i niech się potem dziwią, że w rzeczywistości podchodzi się do problemu zupełnie inaczej.
Istnieją dwa typy systemów kontroli wersji. W systemie scentralizowanym (CVCS - Centralized Version Control System) programista ma na dysku aktualną wersję projektu, a cała historia przechowywana jest na centralnym serwerze. Pakiety zmian dodajemy bezpośrednio do centralnego repozytorium. Jeżeli chcemy pracować na innej wersji programu, odpowiednie pliki są ściągane z serwera i podmieniane.
Możemy również porównać aktualną wersję z którąś z poprzednich. Najważniejszymi przedstawicielami tego modelu kontroli wersji są CVS i Subversion (SVN). Jest on chętnie wykorzystywany przez duże korporacje prowadzące projekty przez wiele lat. Aby spełnić ich potrzeby tworzone są również płatne systemy takie jak IBM Rational ClearCase.
Alternatywą są systemy rozproszone (DVCS - Distributed Version Control System). Zostały one stworzone głównie z myślą o projektach open source.
System tego typu został po raz pierwszy wykorzystany w pracach nad jądrem Linuxa. Od tego czasu DVCS zdobywają coraz większą popularność i powoli zastępują systemy scentralizowane.
W DVCS użytkownik trzyma na dysku dokładną kopię repozytorium z centralnego serwera zawierającą nie tylko aktualną wersję, ale również całą historię. Takie podejście może wydawać się nieefektywne, ale system nie archiwizuje całych plików. Zamiast tego zapisuje same różnice pomiędzy poszczególnymi wersjami i na tej podstawie jest w stanie odtworzyć zawartość pliku. Dzięki takiemu podejściu użytkownik może dokonać wielu zmian na swoim lokalnym repozytorium i uploadować je na serwer centralny dopiero kiedy uzna to za stosowne. Najpopularniejsi przedstawiciele tej kategorii to Git i Mercurial (hg).
Główną zaletą DVCS jest fakt, że umożliwia całkowicie lokalną pracę bez żadnego serwera.
Operacje na lokalnie zapisanej historii wykonują się dużo szybciej. Poza tym jeśli utracimy połączenie z serwerem, możemy dalej pracować. Dodatkowo każdy klon repozytorium jest jednocześnie pełnym backupem. Z kolei systemy scentralizowane lepiej nadają się do pracy z dużymi plikami binarnymi, w których nawet mała zmiana logicznej zawartości może całkowicie zmieniać zawartość binarną.
W dalszej części artykułu będę się posługiwał Mercurialem, nakładką graficzną TortoiseHg i serwisem hostingowym Bitbucket. Dlaczego tak? Moim zdaniem do zastosowań indywidualnych systemy rozproszone są dużo lepsze.
Mercurial mimo, że mniej popularny od Gita, jest uznawany za prostszy do opanowania. Poza tym Git nie jest tak dobrze przystosowany do pracy pod Windowsem. Tortoise to oprogramowanie zapewniające nakładki graficzne na popularne systemy kontroli wersji w zależności od wybranego systemu, możemy użyć: TortoiseHg, TortoiseGit, TortoiseSvn.
Bitbucket to serwis, na którym można umieszczać własne projekty. W odróżnieniu od innych podobnych projektów (np. GitHub) umożliwia tworzenie niepublicznych projektów przy użyciu darmowego konta.
Nie będę tutaj opisywać instalacji TortoiseHg i zakładania konta na Bitbucket. Myślę, że każdy powinien z tym sobie bez problemu poradzić. W razie czego można skorzystać z tutoriali Bitbucketa. Jest tam również opis wstępnej konfiguracji TortoiseHg.
Aby utworzyć nowe repozytorium wybieramy odpowiednią lokalizację, a następnie w explorerze klikamy prawy przycisk w docelowym folderze i wybieramy opcję:
TortoiseHg->Create Repository Here.
Tworzenie repozytorium.
Docelowy folder może być pusty. Wtedy robimy repozytorium od zera i musimy w nim utworzyć odpowiednie pliki lub skopiować je z innego miejsca. Możliwe jest też tworzenie repozytorium w folderze zawierającym już istniejący projekt. Właśnie taka sytuacja została tutaj przedstawiona.
Następnym krokiem jest dodanie plików do repozytorium. Możemy to zrobić klikając:
TortoiseHg->Add i wybierając odpowiednie pliki.
Dodawanie plików do repozytorium
Możemy również wybrać opcję TortoiseHg->Commit i otworzy nam się nowe okno. Po lewej stronie będziemy mieli listę plików repozytorium i ich status. Należy tam zaznaczyć interesujące nas pliki i wybrać dla nich opcję Add.
Warto również dodać pliki wynikowe kompilacji i ustawienia projektu do listy ignorowanych.
W tym celu należy kliknąć prawym przyciskiem na plik i wybrać opcję ignore. Otworzy się wtedy dodatkowe okno, w którym dodajemy pliki do listy ignorowanych. Jeżeli klikniemy prawym na jeden z plików na liście w nowym oknie, będziemy mogli dodać do ignorowanych wszystkie pliki z danego folderu albo o konkretnym rozszerzeniu. Lista ignorowanych plików przechowywana jest w pliku .hgignore, który również warto dodać do śledzonych plików.
.hgignore
Teraz możemy napisać wiadomość i dokonać commita. W ten sposób zmiany zostaną zapisane w repozytorium lokalnym.
Następnie dodałem 4 następne commity. Utworzyłem w nich nowy plik time.c i dodałem do niego trochę kodu. Aby teraz cofnąć się do poprzedniej wersji należy w folderze projektu kliknąć prawy przycisk i wybrać HgWorkbench. Repozytorium otworzy się teraz w TortoiseHg. Wybieramy rewizję, do której chcemy się cofnąć, klikamy prawy przycisk myszy. Wybieramy opcję Update. Po wykonaniu tej operacji wszystkie późniejsze zmiany zostały cofnięte.
Przywracanie wybranej wersji.
Następnie dodałem kilka kolejnych commitów ze zmianami w pliku time.c tworząc w ten sposób dwie gałęzie (branche).
Miejscem rozwidlenia jest rewizja do której wcześniej się cofnąłem. Dzięki temu zabiegowi mogę w każdym branchu niezależnie rozwijać inną funkcjonalność.
Aby dokonać ponownego scalenia jedną gałąź mam zaznaczoną jako aktualną, a drugą klikam prawym przyciskiem i wybieram opcję merge with local W kolejnym oknie należy potwierdzić merge. Jeżeli zmiany były dokonywane w innych miejscach, merge wykona się automatycznie.
Scalanie wersji.
Czasem jednak ma miejsce konflikt. Należy wtedy wybrać opcję resolve i w kolejnym oknie dokonać merge za pomocą dodatkowego programu. Zaznaczony na rysunku program zewnętrzny kdiff3 jest instalowany razem z Tortoise. Po jego wybraniu i naciśnięciu przycisku Tool Resolve często wykona się automatyczny merge. Czasem jednak niezbędne będzie ręczne dokonanie zmian.
Program kdiff3.
Po zakończeniu merge należy się upewnić, że projekt działa tak jak powinien i można dokonać commita. Jak widać na branche zostały z powrotem połączone.
Gałęzie po połączeniu.
System kontroli wersji umożliwia również zmienianie nazw plików oraz ich usuwanie.
Ważne jest jednak, aby zmiany wykonywać za pomocą TortoiseHg, zamiast robić to bezpośrednio w Windowsie lub w IDE.
Aby zmienić nazwę pliku klikamy go prawym przyciskiem i wybieramy:
TortoiseHg->Rename File.
Zmiana nazwy pliku
Jeżeli chcemy usunąć plik, wybieramy TortoiseHg->Remove Files. Jeżeli usunęliśmy plik w niepoprawny sposób, przy następnym commicie po lewej stronie nazwa skasowanego pliku wyświetli się z wykrzyknikiem obok.
Niepoprawne usunięcie pliku.
Oznacza to, że pliku nie można znaleźć, ale nie zostanie on uznany za usunięty. Dlatego jeśli później wrócimy do tej rewizji, plik może pojawić się z powrotem. Poprawne usunięcie pliku jest sygnalizowane symbolem R obok nazwy pliku.
Poprawne usunięcie pliku.
Operacja zmiany nazwy składa się z usunięcia starego pliku i dodania nowego. Dodatkowo zapisywana jest informacja o zmianie nazwy, dzięki czemu można w późniejszym czasie śledzić zmiany w pliku z czasu kiedy miał starą nazwę.
Aby połączyć lokalne repozytorium z bitbucketem, należy założyć nowe repozytorium przez stronę. Następnie repozytorium lokalnemu trzeba przypisać ścieżkę serwera, do którego ma wysyłać zmiany. W tym celu wchodzimy do HgWorkbench z otwartym repozytorium. Wybieramy tam File->Settings. Otworzą nam się opcje w dwóch zakładkach. Jedna zawiera ustawienia globalne, a druga lokalne dla aktualnego projektu. Wybieramy drugą zakładkę i tam klikamy przycisk Edit File. Wewnątrz pliku dopisujemy:
|
1 2 |
[paths] default = url |
Gdzie url to adres do projektu bitbucket. Możemy go odczytać ze strony projektu po prawej stronie (zaczyna się od https i naszej nazwy użytkownika). Zapisujemy zmiany w opcjach HgWorkbench i wykonujemy operację "Push outgoing changes to selected URL". W ten sposób zmiany zostaną wysłane na serwer. Poniżej podgląd commitów w bitbuckecie.
Repozytorium w BitBucket.
Dla lepszego zapoznania się z możliwościami TortoiseHg polecam przestudiowanie manuala.
Serwisy takie jak Bitbucket oferują również kilka dodatkowych funkcjonalności, które można zintegrować z systemem kontroli wersji. Najważniejszą z nich jest issue tracker. Pozwala on na:
Obsługa trackera jest bardzo prosta - otwieramy odpowiednią zakładkę na stronie projektu i wyświetla nam się lista. Na rysunku tracker dla projektu tortoisehg . Jeżeli wybierzemy któryś wpis, otwiera się widok szczegółowy. Możemy również dodawać nowe wpisy. Poza dodaniem tekstu i załączników można im nadawać także typ (np. bug, feature) czy priorytet.
W artykule postarałem się przybliżyć podstawowe informacje i wykorzystanie przyjaznych w użyciu narzędzi umożliwiających łatwe dodanie kontroli wersji do domowych projektów.
Temat kontroli wersji jest bardzo rozbudowany. Zachęcam do głębszego zapoznania się z nim, aby wypracować konfigurację optymalną dla siebie. W internecie łatwo znaleźć przydatne artykuły, tutoriale, blogi i inne pomocne materiały na ten temat.
Przeczytaj powiązane artykuły oraz aktualnie popularne wpisy lub losuj inny artykuł »
Mercurial, programowanie, projekt, SVN, system kontroli wersji
Dołącz do 20 tysięcy osób, które otrzymują powiadomienia o nowych artykułach! Zapisz się, a otrzymasz PDF-y ze ściągami (m.in. na temat mocy, tranzystorów, diod i schematów) oraz listę inspirujących DIY z Arduino i RPi.
Trwa ładowanie komentarzy...