Wyślij swoją dobrą pracę do bazy wiedzy jest prosta. Skorzystaj z poniższego formularza

Studenci, doktoranci, młodzi naukowcy, którzy wykorzystują bazę wiedzy w swoich studiach i pracy, będą Państwu bardzo wdzięczni.

Wysłany dnia http://www.allbest.ru/

Ministerstwo Edukacji i Nauki Federacji Rosyjskiej

Oświatowy budżet państwa federalnego

Instytucja wyższego wykształcenia zawodowego

„Uniwersytet Państwowy w TOMSKU

SYSTEMY STEROWANIA I ELEKTRONIKA RADIOWA” (TUSUR)

Dział systemy radiowe(RTS)

Praca na kursie

na kursie „Technologie informacyjne”

SYSTEMY KONTROLI WERSJI

Uczniowie grupy 121-3 Korolev D.O.,

Kuleshov M.V., Sadov D.A., Taimasov S.S.

Szef Nozdrevatykh B.F.

Praca kursowa 46 s., 31 rycin, 2 tabele, źródła.

SYSTEM KONTROLI WERSJI, GIT, SVN, MERCURIAL.

W ramach tego kursu omawiane są najpopularniejsze systemy kontroli wersji.

Celem pracy jest zapoznanie się z systemami kontroli wersji, zrozumienie ich działania, instalacji i konfiguracji.

W trakcie prac zainstalowano, skonfigurowano i przetestowano trzy rodzaje systemów kontroli wersji.

W efekcie opracowano trzy w pełni gotowe systemy kontroli wersji, opracowano tabele porównujące funkcje tych systemów oraz udostępniono słownik terminów używanych podczas pracy z programami.

Prace kursowe są uzupełniane w formie tekstowej Redaktor Microsoftu Word 2010 i jest dostępny w formacie drukowanym i elektronicznym.

interfejs systemu wersji sterującej

Wstęp

3.1 Rozpoczęcie pracy nad projektem

3.2 Dzienny cykl pracy

3.3 Oddziały

3.4 Łączenie wersji

3.5 Konflikty i ich rozwiązywanie

3.6 Zamki

3.7 Wersje projektu, tagi

4.1 Lokalne systemy kontroli wersji

4.2 Model scentralizowany

5.1.1 Wymagania systemowe

5.1.2 Koncepcja

5.1.3 Pierwsze kroki

5.2.1 Wymagania systemowe

5.2.2 Instalacja

5.2.3 Podstawowa koncepcja

5.2.4 Tworzenie repozytorium

5.2.5 Import projektu

5.2.7 Dokonywanie zmian

5.2.8 Dodawanie nowych plików

5.2.9 Anuluj zmiany

5.3.1 Wymagania systemowe

5.3.2 Koncepcja

5.3.3 Pierwsze kroki

Wniosek

załącznik A

Załącznik B

Załącznik B

Wstęp

Dziś w świecie, w którym istnieje wielka ilość złożone systemy, istnieje potrzeba modyfikacji dokumenty elektroniczne na różnych etapach ich rozwoju. W trakcie swojego istnienia dokument elektroniczny może podlegać dużej liczbie zmian. Często jednak zdarza się, że dla dalsza praca Potrzebna jest nie tylko najnowsza wersja dokumentu, ale także różne poprzednie wersje.

Oczywiście możesz przechowywać kilka różne opcje wymagany dokument, ale ta metoda jest nieskuteczna. Musimy poświęcić dużo czasu i wysiłku, wymagana jest szczególna uwaga i istnieje duże prawdopodobieństwo błędu. Ponadto musimy przechowywać ogromną liczbę niemal identycznych dokumentów.

W rezultacie opracowano narzędzia programowe, które upraszczają ten mechanizm. Narzędzia te nazywane są systemami kontroli wersji. Istnieje kilka tego rodzaju systemów, z których każdy jest istotny w określonych warunkach ich stosowania.

Główną ideą systemów kontroli wersji jest zapamiętywanie wszystkich wprowadzonych zmian, a także komentarzy użytkowników, którzy je dokonali. Potem staje się jasne, kto, kiedy i co się zmieniło, dlaczego i dlaczego. I co ważne, wszystkie te zmiany można następnie w dowolnym momencie cofnąć.

Zgodnie z celem należy rozwiązać następujące zadania:

Zdefiniować koncepcję systemu kontroli wersji;

Zrozum, jak działają takie systemy;

Przejrzyj zasady instalacji i uruchamiania;

Analizować istniejące systemy kontroli wersji;

Rozważ główne typy tego typu systemów.

Cele pracy przesądziły o jej strukturze. Praca kursu składa się z pięciu rozdziałów, wstępu, zakończenia, bibliografii i dodatku.

1. Koncepcja systemu kontroli wersji

System kontroli wersji (VCS) to oprogramowanie ułatwiające pracę ze zmieniającymi się informacjami. System kontroli wersji umożliwia przechowywanie wielu wersji tego samego dokumentu, w razie potrzeby powrót do wcześniejszych wersji oraz określenie, kto i kiedy dokonał konkretnej zmiany.

2. Korzystanie z systemu kontroli wersji

Tego typu systemy są najczęściej wykorzystywane w programowaniu oprogramowanie, dzięki czemu można przechowywać kody źródłowe rozwijanych programów. VCS umożliwia programistom przechowywanie poprzednich wersji plików z okresu programowania i pobieranie ich stamtąd. Przechowuje informacje o wersji każdego pliku (i całej strukturze projektu) w kolekcji zwanej zwykle repozytorium. Niemniej jednak systemy te można wykorzystać w innych obszarach wiedzy, które obejmują ogromną liczbę często zmieniających się dokumentów elektronicznych. Na przykład są coraz częściej stosowane w CAD, zwykle jako część systemów zarządzania danymi produktu (PDM). Wersjonowanie jest używane w narzędziach do zarządzania konfiguracją.

Korzystanie z VCS jest z pewnością obowiązkowe dla programisty, jeśli projekt obejmuje więcej niż kilkaset linii lub jeśli nad projektem pracuje kilku programistów.

Systemy kontroli wersji rozwiązują następujące problemy:

Przechowywanie wersji plików;

Możliwość uzyskania dowolnych poprzednich wersji przechowywanych plików;

Wyświetl zmiany wprowadzone pomiędzy wersjami określonymi w żądaniu;

3. Typowa procedura pracy z systemem

Każdy VCS ma swoje specyficzne cechy w zestawie poleceń, sposobie pracy użytkowników i administracji. Jednak ogólna procedura operacyjna większości systemów VCS jest całkowicie stereotypowa. Tutaj zakłada się, że projekt jakikolwiek by nie był, już istnieje, a jego repozytorium znajduje się na serwerze, do którego dostęp uzyskuje deweloper.

3.1 Rozpoczęcie pracy nad projektem

Pierwszym krokiem, jaki musi podjąć programista, jest pobranie roboczej kopii projektu lub jego części, nad którą będzie pracował. Ta akcja jest wykonywana za pomocą standardowej wersji polecenia checkout (checkout lub klon) lub specjalnego polecenia, które faktycznie wykonuje tę samą akcję. Programista określa wersję, którą należy skopiować, domyślnie kopiowana jest zazwyczaj wersja najnowsza (lub ta wybrana przez administratora jako główna).

Polecenie wyodrębnienia nawiązuje połączenie z serwerem, a projekt w postaci drzewa katalogów i plików jest kopiowany na komputer programisty. Powszechną praktyką jest duplikowanie kopii roboczej: oprócz głównego katalogu, w którym znajduje się projekt dysk lokalny Ponadto rejestrowana jest kolejna jego kopia. Podczas pracy nad projektem programista zmienia tylko pliki w głównej kopii roboczej. Druga kopia lokalna jest przechowywana jako odniesienie, co pozwala w dowolnym momencie, bez konieczności kontaktowania się z serwerem, określić, jakie zmiany zostały wprowadzone w pliku konkretny plik lub projekt jako całość i z jakiej wersji została wykonana kopia robocza; z reguły każda próba ręczna zmiana kopia ta powoduje błędy w działaniu oprogramowania VCS.

3.2 Dzienny cykl pracy

Z pewnymi odchyleniami wynikającymi z cech systemu i szczegółów przyjętego procesu biznesowego, typowy cykl pracy programisty w ciągu dnia roboczego wygląda następująco:

1) Aktualizacja kopii roboczej. W miarę wprowadzania zmian w głównej wersji projektu kopia robocza na komputerze programisty staje się stara: zwiększa się jej rozbieżność z główną wersją projektu. Zwiększa to ryzyko sprzecznych zmian. Dlatego wygodnie jest wspierać egzemplarz roboczy w stanie jak najbardziej zbliżonym do aktualnej wersji głównej, dla której programista możliwie najczęściej przeprowadza operację aktualizacji na kopii roboczej.

2) Modyfikacja projektu. Deweloper modyfikuje projekt, zmieniając pliki zawarte w kopii roboczej zgodnie ze specyfikacją projektu. Praca ta wykonywana jest lokalnie i nie wymaga wywołań do serwera VCS.

3) Naprawianie zmian. Po zakończeniu kolejnego etapu pracy nad zadaniem programista zatwierdza swoje zmiany, przesyłając je na serwer, albo do gałęzi głównej, jeśli praca nad zadaniem została całkowicie zakończona, albo do osobnej gałęzi rozwojowej dla tego zadania. VCS może wymagać od programisty aktualizacji kopii roboczej przed zatwierdzeniem. Jeśli system obsługuje zmiany półek, zmiany można przesłać na serwer bez ich zatwierdzania. Jeżeli pozwala na to zatwierdzona polityka pracy w systemie twardej waluty, wówczas zmiany można rejestrować nie codziennie, ale dopiero po zakończeniu pracy nad zadaniem; w tym przypadku wszystkie zmiany związane z zadaniem są zapisywane wyłącznie w lokalnej kopii roboczej programisty do momentu zakończenia zadania.

3.3 Oddziały

Możesz dokonać drobnych poprawek w projekcie bezpośrednio edytując kopię roboczą, a następnie zatwierdzając zmiany bezpośrednio do głównej gałęzi (trunk) na serwerze. Jednak przy wykonywaniu większej ilości pracy taka kolejność staje się niewygodna: brak zapisu zmian pośrednich na serwerze nie pozwala na pracę nad czymkolwiek w trybie grupowym, ponadto zwiększa się ryzyko utraty zmian podczas wypadków lokalnych i możliwość analizy i powrotu do poprzednich wariantów kodu została utracona w ramach tej pracy. Dlatego przy takich zmianach zwyczajową praktyką jest tworzenie oddziałów, tworzenie wersji nowej wersji projektu lub jego części, której rozwój odbywa się równolegle ze zmianami w wersji głównej. Po zakończeniu pracy, dla której utworzono gałąź, gałąź zostaje ponownie zintegrowana z gałęzią główną. Można to zrobić za pomocą polecenia merge lub tworząc łatkę zawierającą zmiany wprowadzone w trakcie rozwoju gałęzi i stosując tę ​​łatkę do bieżącej głównej wersji projektu.

3.4 Łączenie wersji

Trzy rodzaje operacji wykonywanych w kontroli wersji mogą skutkować koniecznością scalania zmian:

Aktualizacja kopii roboczej;

Rejestrowanie zmian;

Łączenie oddziałów.

Każdy system posiada mechanizm automatycznego scalania, który działa w oparciu o następujące zasady:

Zmiany mogą polegać na modyfikacji zawartości pliku, utworzeniu nowego pliku lub katalogu, usunięciu lub zmianie nazwy już istniejącego pliku lub katalogu w projekcie;

Jeśli dwie zmiany odnoszą się do różnych i niepowiązanych plików i/lub katalogów, zawsze można je połączyć automatycznie. Ich połączenie polega na tym, że zmiany dokonane w każdej wersji projektu są kopiowane do wersji scalonej;

Tworzenie, usuwanie i zmiana nazw plików w katalogach projektu mogą być łączone automatycznie, o ile nie kolidują ze sobą. W takim przypadku zmiany dokonane w każdej wersji projektu zostaną skopiowane do wersji scalonej.

Konfliktowe to zazwyczaj:

Usuwanie i zmiana tego samego pliku lub katalogu;

Usuwanie i zmiana nazwy tego samego pliku lub katalogu;

Stworzenie w różne wersje plik o tej samej nazwie i innej zawartości;

Zmiany w jednym plik tekstowy wykonane w różnych wersjach, można je łączyć, jeśli są różne miejsca tego pliku i nie przecinają się. W takim przypadku wszystkie wprowadzone zmiany zostaną uwzględnione w wersji scalonej;

Zmiany w tym samym pliku, chyba że jest to plik tekstowy, zawsze powodują konflikt i nie można ich automatycznie scalić.

We wszystkich przypadkach łączoną wersją podstawową jest wersja, w której podzielono scalone wersje. Jeśli jest to operacja zatwierdzenia, to wersją podstawową będzie wersja ostatniej aktualizacji przed zatwierdzeniem; w przypadku aktualizacji, to wersja poprzedniej aktualizacji; w przypadku łączenia gałęzi, to wersja, w której utworzono odpowiednią gałąź. W związku z tym porównywane zestawy zmian będą zbiorami zmian wprowadzonych od poziomu podstawowego do obecna wersja we wszystkich łączonych wariantach.

Absolutna większość nowoczesne systemy Kontrola wersji ma na celu przede wszystkim projekty tworzenia oprogramowania, w których głównym rodzajem zawartości plików jest tekst. W związku z tym mechanizmy automatycznego łączenia zmian skupiają się na przetwarzaniu plików tekstowych.

Przy określaniu dopuszczalności łączenia zmian w obrębie tego samego pliku tekstowego działa standardowy mechanizm porównywania tekstu linia po linii (przykładem jego wdrożenia jest narzędzie systemowe GNU diff), który porównuje scalone wersje z wersją bazową i buduje lista zmian, czyli dodanych, usuniętych i zastąpionych zestawów linii. Znalezione zestawy zmodyfikowanych ciągów, które się nie przecinają, są uznawane za zgodne, a ich łączenie odbywa się automatycznie. Jeśli scalone pliki zawierają zmiany wpływające na tę samą linię pliku, prowadzi to do konfliktu. Takie pliki można łączyć tylko ręcznie. Wszelkie pliki inne niż pliki tekstowe są binarne z punktu widzenia VCS i nie pozwalają na automatyczne łączenie.

3.5 Konflikty i ich rozwiązywanie

Sytuację, w której podczas łączenia kilku wersji dokonane w nich zmiany nakładają się na siebie, nazywa się konfliktem. Jeśli występuje konflikt zmian, system kontroli wersji nie może automatycznie utworzyć scalonego projektu i jest zmuszony skontaktować się z programistą. Jak wspomniano powyżej, konflikty mogą pojawić się na etapach wprowadzania zmian, aktualizacji lub łączenia oddziałów. We wszystkich przypadkach wykrycia konfliktu odpowiednia operacja zostaje zatrzymana do czasu rozwiązania.

Aby rozwiązać konflikt, system ogólnie oferuje programiście trzy opcje dotyczące sprzecznych plików: podstawowy, lokalny i serwerowy. Sprzeczne zmiany są albo pokazywane programiście w specjalnym module oprogramowania do łączenia zmian, albo po prostu oznaczane specjalnymi znacznikami bezpośrednio w tekście scalonego pliku.

Konflikty w systemie plików są rozwiązywane łatwiej: tylko usunięcie pliku może powodować konflikt z jedną z pozostałych operacji, a kolejność plików w katalogu nie ma znaczenia, więc programista może jedynie wybrać, która operacja ma zostać zapisana w katalogu wersja połączona.

3.6 Zamki

Mechanizm blokujący pozwala na zabranie tylko jednego z programistów użytek własny plik lub grupa plików, w których chcesz wprowadzić zmiany. Gdy plik jest zablokowany, pozostaje on tylko do odczytu dla wszystkich innych programistów, a każda próba wprowadzenia w nim zmian jest odrzucana przez serwer. Technicznie rzecz biorąc, blokowanie można zorganizować na różne sposoby. Typowy dla nowoczesnych systemów jest następujący mechanizm:

Pliki wymagające blokowania są oznaczone specjalną flagą „zablokowane”;

Jeśli plik jest oznaczony jako zablokowany, to po pobraniu kopii roboczej z serwera otrzymuje on w lokalnym systemie plików atrybut tylko do odczytu, co zapobiega przypadkowej edycji;

Programista, który chce zmienić zablokowany plik, dzwoni specjalny zespół lock (lock) wskazujący nazwę tego pliku. Wynik tego polecenia jest następujący:

1. serwer sprawdza, czy plik nie jest już zablokowany przez innego programistę; jeśli tak, polecenie blokowania nie powiedzie się.

2. plik na serwerze zostaje oznaczony jako „zablokowany” z podaniem identyfikatora dewelopera, który go zablokował oraz zapisanego czasu blokady;

3. Jeżeli blokada na serwerze się powiedzie, atrybut „tylko do odczytu” zostanie usunięty z pliku kopii roboczej w lokalnym systemie plików, co umożliwi rozpoczęcie jego edycji.

Jeśli podczas operacji okaże się, że plik nie wymaga zmiany, może wywołać polecenie odblokowania , zwolnić blokadę). Wszystkie zmiany w pliku zostaną cofnięte, plik lokalny powróci do stanu tylko do odczytu, atrybut „locked” zostanie usunięty z pliku na serwerze, a inni programiści będą mogli zmieniać ten plik;

Po zakończeniu pracy z zablokowanym plikiem programista zatwierdza zmiany. Zwykle blokada jest usuwana automatycznie.

3.7 Wersje projektu, tagi

System kontroli wersji zapewnia przechowywanie wszystkich istniejących wersji plików, a co za tym idzie, wszystkich wersji projektu jako całości, które pojawiły się od początku jego rozwoju. Ale samo pojęcie „wersji” w różne systemy można interpretować na dwa różne sposoby.

Niektóre systemy obsługują wersjonowanie plików. Oznacza to, że otrzymuje każdy plik występujący w projekcie własny numer wersje. Za każdym razem, gdy programista zatwierdza zmiany w pliku, odpowiednia część zatwierdzonych zmian jest stosowana do pliku, a plik otrzymuje nowy, zwykle kolejny numer wersji.

W przypadku innych systemów pojęcie „wersji” nie odnosi się do pojedynczego pliku, ale do całego repozytorium. Nowo utworzone puste repozytorium ma wersję 1 lub 0, wszelkie zmiany zatwierdzeń prowadzą do zwiększenia tej liczby. Właściwie nie ma tutaj numeru wersji pojedynczego pliku.

Obie opcje nie są jednak zbyt wygodne. Aby wygodniej oznaczać wersje projektu, systemy kontroli wersji obsługują koncepcję tagów.

Znacznik to symboliczna etykieta, którą można powiązać z konkretną wersją pliku i/lub katalogu w repozytorium. Za pomocą odpowiedniego polecenia można nadać daną etykietę całości lub części plików projektu spełniających określone warunki. W ten sposób można zidentyfikować wersję projektu, ustalając jego stan w żądanym momencie. Z reguły system tagowania jest dość elastyczny i pozwala na tagowanie wielu wersji plików i katalogów jednym tagiem. Pozwala to na zbudowanie „wersji projektu” w dowolny, dowolny sposób.

4.1 Lokalne systemy kontroli wersji

Najbardziej preferowanym VCS do monitorowania zabudowy mieszkaniowej będzie typ lokalny. Aby rozwiązać ten problem, opracowano specjalne systemy VCS z prostą bazą danych, w której przechowywane są wszystkie lokalne pliki.

Rysunek 4.1 Schemat lokalnego SCR

Jednym z najpopularniejszych VCS-ów tego typu jest RCS, który do dziś jest instalowany na wielu komputerach.

4.2 Model scentralizowany

Tradycyjne systemy kontroli wersji wykorzystują model scentralizowany, w którym zarządzane jest jedno repozytorium dokumentów specjalny serwer, który wykonuje większość funkcji kontroli wersji. Użytkownik pracujący z dokumentami musi najpierw uzyskać z repozytorium potrzebną mu wersję dokumentu; Zwykle tworzona jest lokalna kopia dokumentu, tzw. „kopia robocza”. Można uzyskać wersję najnowszą lub dowolną z poprzednich, którą można wybrać według numeru wersji lub daty utworzenia, czasem według innych kryteriów. Po dokonaniu niezbędnych zmian w dokumencie nowa wersja zostaje umieszczona w repozytorium. W odróżnieniu od zwykłego zapisywania pliku, poprzednia wersja nie jest usuwana, ale również pozostaje w pamięci i można ją z niej w każdej chwili odzyskać.

Takie systemy, jak CVS, Subversion i Perforce, posiadają centralny serwer, który przechowuje wszystkie pliki pod kontrolą wersji, oraz pewną liczbę klientów, którzy otrzymują od niego kopie plików. Od wielu lat jest to standard w systemach kontroli wersji.

Rysunek 4.2 Scentralizowany schemat kontroli wersji

To podejście ma wiele zalet, szczególnie w porównaniu z lokalnym SLE. Na przykład każdy wie, kto co robi w projekcie. Administratorzy mają jasną kontrolę nad tym, kto może co robić, a CSKB jest oczywiście znacznie łatwiejsze w administrowaniu niż lokalne bazy danych na każdym kliencie.

Jednakże podejście to ma kilka poważnych wad. Najbardziej oczywiste jest to, że scentralizowany serwer jest słabym punktem całego systemu. Jeśli serwer przestanie działać na godzinę, programiści nie będą mogli przez godzinę wchodzić w interakcje i nikt nie będzie mógł zapisać nowej wersji swojej pracy. Jeżeli dysk z centralną bazą danych ulegnie uszkodzeniu i nie będzie kopii zapasowej, tracisz absolutnie wszystko – całą historię projektu, z wyjątkiem kilku działających wersji zapisanych na komputerach roboczych użytkowników. Lokalne VCS mają ten sam problem: jeśli cała historia projektu jest przechowywana w jednym miejscu, ryzykujesz utratę wszystkiego.

4.3 Rozproszone systemy kontroli wersji

Takie systemy wykorzystują model rozproszony zamiast tradycyjnego modelu klient-serwer. Generalnie nie potrzebują centralnego przechowywania: cała historia zmian dokumentów przechowywana jest na każdym komputerze, w lokalnej pamięci, a w razie potrzeby poszczególne fragmenty historii lokalnego przechowywania są synchronizowane z podobnym magazynem na innym komputerze. Dlatego w przypadku, gdy serwer, przez który szła praca, ulegnie awarii, dowolne repozytorium klienta można skopiować z powrotem na serwer w celu przywrócenia bazy danych. W niektórych z tych systemów pamięć lokalna jest zlokalizowana bezpośrednio w katalogach kopii roboczej.

Rysunek 4.3 Rozproszony model VCS

Kiedy użytkownik takiego systemu wykonuje normalne czynności, takie jak pobranie określonej wersji dokumentu, utworzenie nowej wersji itp., pracuje ze swoją lokalną kopią repozytorium. W miarę wprowadzania zmian repozytoria należące do różnych deweloperów zaczynają się od siebie różnić i zachodzi potrzeba ich synchronizacji. Taką synchronizację można osiągnąć poprzez wymianę poprawek lub tzw. zestawów pomiędzy użytkownikami.

Opisany model jest logicznie bliski stworzeniu osobnej gałęzi dla każdego programisty w klasycznym systemie kontroli wersji. Różnica polega na tym, że do czasu synchronizacji inni programiści nie widzą tej gałęzi. Dopóki programista modyfikuje tylko swoją gałąź, jego praca nie wpływa na innych członków projektu i odwrotnie. Po zakończeniu oddzielnej części pracy zmiany wprowadzone w gałęziach są łączone z gałęzią główną (wspólną). Zarówno podczas łączenia oddziałów, jak i synchronizacji różnych repozytoriów możliwe są konflikty wersji. W takim przypadku wszystkie systemy zapewniają określone metody wykrywania i rozwiązywania konfliktów scalania.

Z punktu widzenia użytkownika system rozproszony wyróżnia się koniecznością utworzenia lokalnego repozytorium oraz obecnością język poleceń dwa dodatkowe polecenia: polecenie pobrania repozytorium z komputera zdalnego i przeniesienia repozytorium na komputer zdalny. Pierwsze polecenie łączy zmiany z repozytorium zdalnego i lokalnego i umieszcza wynik w repozytorium lokalnym; drugi natomiast łączy zmiany z dwóch repozytoriów i umieszcza wynik w zdalnym repozytorium. Zazwyczaj polecenia scalania w systemach rozproszonych umożliwiają wybranie, które zestawy zmian zostaną wypchnięte do innego repozytorium lub ściągnięte z innego repozytorium, skorygowanie konfliktów scalania bezpośrednio podczas operacji lub po jej niepowodzeniu oraz ponowienie lub wznowienie niedokończonego scalania. Zazwyczaj przeniesienie zmian do repozytorium innej osoby kończy się sukcesem tylko wtedy, gdy nie ma konfliktów. Jeśli pojawią się konflikty, użytkownik musi najpierw scalić wersje w swoim repozytorium, a dopiero potem przenieść je do innych.

Zwykle zaleca się taką organizację pracy z systemem, aby użytkownicy zawsze lub w przeważającej mierze dokonywali fuzji w swoich repozytoriach. Oznacza to, że w przeciwieństwie do systemów scentralizowanych, w których użytkownicy przesyłają swoje zmiany na serwer centralny, kiedy uznają to za stosowne, w systemach rozproszonych bardziej naturalne jest, że łączenie wersji jest inicjowane przez osobę, która potrzebuje otrzymać wynik (na przykład programistę zarządzającego serwer kompilacji).

Głównymi zaletami systemów rozproszonych jest ich elastyczność i znacznie większa (w porównaniu do systemów scentralizowanych) autonomia pojedynczego stanowiska pracy. Komputer każdego programisty jest tak naprawdę niezależnym i w pełni funkcjonalnym serwerem, z takich komputerów można zbudować system o dowolnej strukturze i stopniu złożoności, ustawiając żądaną kolejność synchronizacji.

Wady systemów rozproszonych obejmują wzrost wymaganej objętości pamięć dyskowa: każdy komputer musi przechowywać pełną historię wersji, podczas gdy w systemie scentralizowanym na komputerze programisty zwykle przechowywana jest tylko kopia robocza, czyli wycinek repozytorium w pewnym momencie i wprowadzone zmiany. Mniej oczywistą, ale nieprzyjemną wadą jest to, że prawie niemożliwe jest wdrożenie niektórych funkcjonalności zapewnianych przez systemy scentralizowane w systemie rozproszonym. Ten:

- Blokowanie pliku lub grupy plików (do przechowywania atrybutu blokowania wymagany jest centralny serwer, który jest publicznie dostępny i stale online). Wymusza to podjęcie specjalnych środków administracyjnych, jeśli trzeba pracować z plikami binarnymi, które nie nadają się do automatycznego łączenia;

- Monitorowanie określonego pliku lub grupy plików;

- Pojedyncza ciągła numeracja wersji systemu i/lub plików, w której numer wersji rośnie monotonicznie. W systemach rozproszonych należy poprzestać na lokalnych oznaczeniach wersji i używać tagów, których przeznaczenie jest określone umową pomiędzy programistami lub standardami korporacyjnymi firmy;

- Lokalny użytkownik pracuje z oddzielną próbką o małej objętości z magazynu o znacznych rozmiarach i wewnętrznej złożoności na zdalnym serwerze.

Można wyróżnić następujące typowe sytuacje, w których zastosowanie systemu rozproszonego zapewnia zauważalne korzyści:

- Okresowa synchronizacja kilku komputerów pod kontrolą jednego programisty. Korzystanie z systemu rozproszonego eliminuje potrzebę przydzielania jednego z komputerów jako serwera;

- Wspólna praca nad projektem przez małą, rozproszoną geograficznie grupę programistów bez alokacji wspólnych zasobów. Podobnie jak w poprzednim przypadku, schemat pracy realizowany jest bez głównego serwera, a aktualność repozytoriów utrzymywana jest poprzez okresowe synchronizacje według schematu „każdy z każdym”;

Duży rozproszony projekt, którego uczestnicy mogą pracować na swoim stanowisku przez długi czas, ale nie mają stałego połączenia z siecią. W takim projekcie można zastosować scentralizowany serwer, z którym synchronizowane są kopie wszystkich jego uczestników. Można pracować bez serwerów „grupowych”, wówczas programiści jednej grupy synchronizują między sobą zmiany, po czym każdy z nich przesyła zmiany na serwer centralny.

5. Przykłady systemów kontroli wersji

5.1 GIT

5.1.1 Wymagania systemowe

Git Działa pod następującymi systemami operacyjnymi: Windows, Linux i Mac OS.

Aby zainstalować Git na Windows wystarczy pobrać plik exe instalatora ze strony projektu na GitHubie i uruchomić go.Po instalacji będziesz mieć zarówno wersję konsolową (zawierającą klienta SSH) jak i standardową wersję graficzną.

5.1.2 Koncepcja

Git to rozproszony system kontroli wersji. W nim pliki mogą znajdować się w jednym z trzech stanów: zatwierdzony, zmodyfikowany i przygotowany. „Zatwierdzony” oznacza, że ​​plik jest już zapisany w lokalnej bazie danych. Zmienione pliki obejmują pliki, które uległy zmianie, ale nie zostały jeszcze zatwierdzone. Pliki etapowe to zmodyfikowane pliki, które są zaznaczane do włączenia przy następnym zatwierdzeniu.

Zatem projekty korzystające z Gita składają się z trzech części: katalogu Git, katalogu roboczego i obszaru testowego.

Katalog Git to miejsce, w którym Git przechowuje metadane projektu i bazę danych obiektów.Jest to najważniejsza część Gita i jest kopiowana podczas klonowania repozytorium z innego komputera.

Katalog roboczy jest kopią określonej wersji projektu wyodrębnionej z bazy danych. Pliki te są pobierane ze skompresowanej bazy danych w katalogu Git i umieszczane na dysku, abyś mógł je przeglądać i edytować.

Staging area to zwykły plik, zwykle przechowywany w katalogu Git, który zawiera informacje o tym, co powinno znaleźć się w następnym zatwierdzeniu. Czasami nazywany jest indeksem, ale ostatnio standardem stało się nazywanie go obszarem testowym (staging area). .

Standardowy przepływ pracy przy użyciu Gita wygląda mniej więcej tak:

1. Dokonujesz zmian w plikach w swoim katalogu roboczym.

2. Przygotuj pliki dodając ich migawki do obszaru przygotowanych plików.

3. Wykonaj commit, który pobierze przygotowane pliki z indeksu i umieści je w katalogu Git w celu trwałego przechowywania.

Jeżeli działająca wersja pliku jest zgodna z wersją w katalogu Git, plik uznaje się za zatwierdzony. Jeżeli plik został zmieniony, ale dodany do przygotowanego obszaru danych, to jest przygotowany. Jeżeli plik zmienił się po wyładowaniu z bazy, ale nie został sporządzony, wówczas uważa się go za zmieniony.

5.1.3 Pierwsze kroki

Wszyscy pracują Git odbywa się w repozytorium zawierającym wszystkie pliki dzieła. Repozytorium możesz utworzyć na różne sposoby.

1. Za pomocą menu kontekstowego. Aby to zrobić, wystarczy kliknąć prawym przyciskiem myszy żądany katalog i wybrać Git Init Here.

Rysunek 5.1.1 Tworzenie repozytorium za pomocą menu kontekstowego

2. Korzystanie z wiersza poleceń. Aby to zrobić analogicznie w wymaganym katalogu wybierz z menu kontekstowego Git Bash. Otworzy się linia poleceń, w której tworzymy repozytorium za pomocą polecenia Git Init.

Rysunek 5.1.2 Tworzenie repozytorium przy użyciu wiersza poleceń

Jeśli nigdy wcześniej nie korzystałeś z gita, musisz najpierw wpisać swoje imię i nazwisko oraz adres e-mail, używając odpowiednio następujących poleceń:

git config --global nazwa_użytkownika „Twoje imię”

git config --global użytkownik.email [e-mail chroniony]

Utworzone repozytorium będzie zawierać katalog .git. Aby dodać plik do repozytorium wystarczy skopiować go do swojego katalogu roboczego. Dodajmy plik ex.txt do repozytorium. Za pomocą polecenia git status upewnimy się, że Git widział plik.

Rysunek 5.1.3 Dodawanie i sprawdzanie pliku w repozytorium

Następnie, aby dodać plik pod kontrolą wersji, należy zaindeksować te pliki i wykonać pierwsze zatwierdzenie zmian. Można to zrobić za pomocą kilku poleceń git add określających pliki do indeksowania, a następnie git commit.

Rysunek 5.1.4 Dodawanie pliku pod kontrolą wersji

Polecenie git status jest głównym narzędziem używanym do określania, w jakim stanie są pliki.

Aby rozpocząć śledzenie (dodawanie pod kontrolą wersji) nowego pliku, użyj polecenia git add „nazwa pliku”. Polecenie to przyjmuje jako parametr ścieżkę do pliku lub katalogu, jeśli jest to katalog, polecenie rekurencyjnie dodaje (indeksuje) wszystkie pliki w podanym katalogu.

Git commit -m „comment” to polecenie służące do utworzenia zatwierdzenia, naprawienia zmiany.

Korzystając z interfejsu graficznego Git Gui, powtórzymy poprzednią operację. Aby to zrobić, wybierz opcję Git Gui z menu kontekstowego.

Rysunek 5.1.5

W oknie, które zostanie otwarte, wybierz „Utwórz nowe repozytorium”. Następnie wskazujemy katalog, w którym chcemy umieścić repozytorium.

Rysunek 5.1.6 Tworzenie repozytorium w Git Gui

Dodaj plik Ex.txt do katalogu. Następnie kliknij przycisk „Przeczytaj ponownie”. Aby dodać plik do kontroli wersji należy kliknąć przycisk „Przygotuj wszystko”. Plik Ex.txt powinien zostać przeniesiony z okna „Zmieniono” do okna „Przygotowany”. Aby naprawić zmianę, użyj przycisku „Zapisz”.

5.1.5 Tworzenie kopii repozytorium

Obecnie masz do wyboru ogromną liczbę opcji hostingu, a każda z nich ma własną zalety i wady.

W tej sekcji omówimy proces tworzenia konta i nowego projektu na GitHubie, co da ci pojęcie o tym, co się z tym wiąże.

GitHub to obecnie największa witryna hostingowa Git dla projektów open source i jedna z niewielu oferujących hosting zarówno publiczny, jak i prywatny.

Pierwszą rzeczą, którą musisz zrobić, to założyć konto i utworzyć repozytorium na http://github.com/plans.

Następnie w wierszu poleceń Git wpisujemy znane nam już polecenia:

Git dodaj ex.txt

Git commit -m „komentarz”

Git zdalnie dodaj pochodzenie https://github.com/Arbuz-z-z/MyHomework.git

Git push -u mistrz pochodzenia

Polecenie git Remote Add służy do dodawania zdalnych repozytoriów, a polecenie git Push służy do wypychania lokalnych zmian na zdalny serwer.

Rysunek 5.1.7

Wpisz nazwę użytkownika i hasło podane podczas rejestracji:

Rysunek 5.1.8

Teraz nasz projekt jest zamieszczony na GitHubie, w repozytorium - MyHomework z plikiem Tusur.txt i możemy udostępnić link do niego każdemu, komu chcemy udostępnić projekt.

Rysunek 5.1.9 Repozytorium na GitHubie

5.2 TortoiseSVN

5.2.1 Wymagania systemowe

TortoiseSVN działa na Windows XP (z Service Pack 3) lub nowszym i jest dostępny zarówno w wersji 32-bitowej, jak i 64-bitowej. Instalator dla 64-bitowego systemu Windows zawiera również część 32-bitową.

5.2.2 Instalacja

TortoiseSVN jest dostarczany jako łatwy w użyciu plik instalacyjny.

5.2.3 Podstawowa koncepcja

Składowanie. Subversion korzysta z centralnej bazy danych, która zawiera wszystkie wersjonowane pliki wraz z ich pełna historia. Ta baza danych nazywa się repozytorium. Magazyn zazwyczaj znajduje się pod adresem serwer plików, na którym zainstalowano Subversion, dostarczając dane klientom Subversion (na przykład TortoiseSVN) na żądanie. Jeśli zrobisz kopia zapasowa, a następnie skopiuj swoją pamięć, ponieważ jest to oryginał wszystkich Twoich danych.

Kopia robocza. To jest dokładnie miejsce, w którym pracujesz. Każdy programista ma własną kopię roboczą, czasami nazywaną piaskownicą, na swoim komputerze lokalnym. Można go pobrać z repozytorium Ostatnia wersja plików, pracuj nad nimi lokalnie, bez interakcji z nikim innym, a gdy będziesz mieć pewność co do zmian, możesz przesłać te pliki z powrotem do repozytorium. Kopia robocza nie zawiera historii projektu, lecz zawiera kopię wszystkich plików, które znajdowały się w repozytorium przed rozpoczęciem wprowadzania zmian.

TortoiseSVN jest rozszerzeniem Eksploratora Windows, więc najpierw musisz uruchomić Eksploratora.

Rysunek 5.2.1 Widok w Eksploratorze

5.2.4 Tworzenie repozytorium

Do tego projektu będziemy potrzebować repozytorium utworzonego w bezpiecznej lokalizacji i serwera Subversion do zarządzania nim. Będziemy używać funkcji magazynu lokalnego Subversion, która umożliwia bezpośredni dostęp do magazynu utworzonego na Twoim dysku twardym i nie wymaga serwera.

Najpierw utwórzmy nowy pusty katalog na komputerze. Może znajdować się gdziekolwiek, ale w tym samouczku nazwiemy go s:\svn_repos. Teraz kliknij prawym przyciskiem myszy nowy folder i wybierz TortoiseSVN z menu kontekstowego > Utwórz tutaj repozytorium... Repozytorium utworzone w folderze jest gotowe do użycia. Stworzymy także wewnętrzną strukturę folderów, klikając przycisk „Utwórz strukturę katalogów”.

Rysunek 5.2.2 Tworzenie repozytorium

Rysunek 5.2.3 Przeglądaj repozytorium

5.2.5 Import projektu

Aktualnie posiadamy magazyn, ale w tej chwili jest on całkowicie pusty. Załóżmy, że mamy zestaw plików w E:\\TortoiseSVN, który chcielibyśmy dodać. Przejdźmy do folderu TortoiseSVN w Eksploratorze i kliknij go prawym przyciskiem myszy. Teraz wybierz TortoiseSVN > Importuj..., co wyświetli okno dialogowe.

Rysunek 5.2.4 Okno Importu

Dostęp do repozytorium Subversion uzyskuje się poprzez adres URL, który pozwala nam wskazać repozytorium w dowolnym miejscu w Internecie. W w tym przypadku musimy wskazać nasze lokalne repozytorium, które ma adres URL file:///s:/svn_repos i do którego dołączamy nazwę naszego projektu TortoiseSVN.

Kolejną ważną funkcją tego okna dialogowego jest okno Importuj wiadomość, w którym możemy dodać wiadomość o tym, co robimy. Kiedy będziemy musieli przejrzeć historię projektu, wiadomości te będą cenną pomocą w zobaczeniu, jakie zmiany zostały wprowadzone i kiedy.

5.2.6 Sprawdzanie kopii roboczej

Teraz mamy projekt w naszym repozytorium i musimy stworzyć kopię roboczą do codziennej pracy. Warto zauważyć, że zaimportowanie folderu nie powoduje automatycznego przekształcenia go w kopię roboczą. Aby utworzyć nową kopię roboczą, Subversion używa terminu „Wyewidencjonuj”. Wypakujemy folder TortoiseSVN z naszego repozytorium do folderu programistycznego o nazwie e:\\TortoiseSVN\svn_repos. Utwórzmy ten folder, następnie kliknij go prawym przyciskiem myszy i wybierz TortoiseSVN > Wyodrębnij... Wprowadź adres URL do wyodrębnienia, w tym przypadku file:///s:/svn_repos/TortoiseSVN i kliknij OK. Nasz folder deweloperski zostanie wypełniony plikami z repozytorium.

Wygląd tego folderu różni się od zwykłego folderu. Każdy plik ma teraz zieloną flagę w lewym rogu. Są to ikony stanu TortoiseSVN, które są obecne tylko w kopii roboczej. Status zielony oznacza, że ​​plik nie różni się od wersji pliku w repozytorium.

5.2.7 Dokonywanie zmian

Możesz zacząć pracować. W folderze TortoiseSVN zaczynamy zmieniać pliki - powiedzmy, że wprowadzamy zmiany w plikach TortoiseSVN.docx. Zwróć uwagę, że ikony na tych plikach są teraz czerwone i wskazują, że zmiany zostały wprowadzone lokalnie.

Kliknij prawym przyciskiem myszy jeden ze zmodyfikowanych plików i wybierz TortoiseSVN > Różnice. Uruchomi się narzędzie do porównywania plików TortoiseSVN i pokaże dokładnie, które linie w plikach zostały zmienione.

Rysunek 5.2.5 Porównanie plików

Teraz zaktualizujmy pamięć. Ta akcja nazywa się „Zatwierdź zmiany”. Kliknijmy kliknij prawym przyciskiem myszy w folderze TortoiseSVN i wybierz polecenie TortoiseSVN > Zatwierdź. Pojawi się okno dialogowe zatwierdzenia z listą zmienionych plików, a obok każdego z nich pojawi się znacznik wyboru. Możemy wybrać tylko kilka plików z listy do zatwierdzenia.

Rysunek 5.2.6 Zatwierdzanie plików

5.2.8 Dodawanie nowych plików

Podczas pracy nad projektem będziemy potrzebować dodaj nowe pliki, załóżmy, że dodaliśmy nowe funkcje w pliku i dodaliśmy pomoc w istniejącym pliku. Kliknij folder prawym przyciskiem myszy i wybierz TortoiseSVN > Dodaj. Okno dodawania pokazuje wszystkie pliki bez wersji i możemy wybrać pliki, które chcemy dodać. Innym sposobem dodawania plików jest kliknięcie prawym przyciskiem myszy samego pliku i wybranie TortoiseSVN > Dodaj.

Teraz, jeśli otworzymy folder zatwierdzeń, nowy plik zostanie wyświetlony jako „Dodano”, a istniejący plik jako „Zmieniony”.

5.2.9 Anuluj zmiany

Jedną wspólną cechą wszystkich systemów zarządzania wersjami jest funkcja, która pozwala nam cofnąć zmiany, które wcześniej dokonaliśmy.

Jeśli chcemy pozbyć się zmian, których nie udało nam się jeszcze zarejestrować i przywrócić wymagany plik w formie, w jakiej był przed rozpoczęciem zmian, następnie wybierz polecenie TortoiseSVN > Usuń zmiany. Ta akcja cofnie nasze zmiany i zwróci poprawioną wersję pliku, od którego zaczęliśmy. Jeśli chcemy usunąć tylko niektóre zmiany, możemy użyć narzędzia TortoiseMerge, aby wyświetlić zmiany i selektywne usuwanie zmienione linie.

Jeśli chcemy cofnąć konkretną wersję, zaczniemy od okna dziennika i znajdziemy problematyczną wersję. Wybierz polecenie Menu kontekstowe > Odrzuć zmiany z tej wersji, a zmiany te zostaną odrzucone.

5.2.10 Funkcje TortoiseSVN. Integracja powłoki

TortoiseSVN integruje się bezpośrednio z powłoką Windows (tj. Eksploratorem). Oznacza to, że możesz pracować z narzędziami, które już znasz i nie musisz przełączać się na inną aplikację za każdym razem, gdy potrzebujesz funkcji kontroli wersji!

I nie musisz nawet używać Eksploratora. Menu kontekstowe TortoiseSVN działają w wielu innych menedżerach plików oraz w oknach dialogowych otwierania plików używanych w większości standardowych aplikacji Windows. Jednakże powinieneś mieć świadomość, że TortoiseSVN został pierwotnie zaprojektowany jako rozszerzenie Eksploratora Windows i inne aplikacje mogą nie mieć pełnej integracji, na przykład nakładki ikon mogą się nie pojawiać.

Status każdego pliku i folderu z wersją jest wskazywany przez mały znak na górze głównej ikony. W ten sposób możesz szybko sprawdzić status swojej kopii roboczej.

5.2.11 Graficzny interfejs użytkownika

Przeglądając listę zmian w pliku lub folderze, możesz kliknąć wersję, aby zobaczyć komentarze dotyczące tego zatwierdzenia. Dostępna jest również lista zmienionych plików – wystarczy dwukrotnie kliknąć plik, aby zobaczyć, jakie konkretnie zmiany zostały wprowadzone.

Okno dialogowe zatwierdzenia to lista zawierająca wszystkie pliki i foldery, które zostaną uwzględnione w zatwierdzeniu. Każdy element listy ma pole wyboru, dzięki czemu możesz dokładnie wybrać, co chcesz uwzględnić w zatwierdzeniu. Na tej liście mogą znajdować się również pliki bez wersji, więc nie zapomnij dodać nowego pliku lub folderu do zatwierdzenia.

Wszystkie polecenia Subversion są dostępne z menu kontekstowego Eksploratora. TortoiseSVN dodaje tam swoje własne podmenu.

5.3 Rtęciowy

5.3.1 Wymagania systemowe

P Pakiety Mercurial dostępne są na każdy popularny system operacyjny: Windows, Mac OS, Linux (Ubuntu, Debian, Fedora, OpenSUSE, Gentoo), Solaris.

Najlepszą wersją Mercurial dla Windows jest TortoiseHg, którą można znaleźć pod adresem http://tortoisehg.org. Ten pakiet umożliwia korzystanie z wiersza poleceń i graficznego interfejsu użytkownika.

5.3.2 Koncepcja

Mercurial to rozproszony (zdecentralizowany) system kontroli wersji. Oznacza to, że przepływ pracy zazwyczaj wygląda następująco:

1. Włączone komputer osobisty tworzone jest nowe repozytorium (poprzez klonowanie istniejącego repozytorium, tworzenie nowego itp.);

2. Dokonuje się zmiany/dodania/usunięcia plików w katalogu roboczym tego repozytorium;

3. Zmiany zapisywane są w tym repozytorium (czyli w repozytorium lokalnym na komputerze osobistym);

4. Kroki 2 i 3 powtarza się tyle razy, ile to konieczne;

5. Jeśli to konieczne, zmiany są synchronizowane z innymi repozytoriami: zestawy zmian innych osób są pobierane i/lub wypychane są ich własne.

Oznacza to, że cała codzienna praca odbywa się w lokalnym repozytorium, a gdy zajdzie taka potrzeba, wyniki ich pracy przesyłane są do jednego lub większej liczby innych repozytoriów. Liczbę kroków podczas pracy ze zdalnymi repozytoriami można zmniejszyć, ustawiając Mercurial na automatyczne wysyłanie zmiany w innych repozytoriach podczas zatwierdzania.

5.3.3 Pierwsze kroki

Możesz pracować w Mercurial poprzez menu kontekstowe Eksploratora, okno obszaru roboczego TortoiseHg Workbench (program tworzy odpowiedni skrót podczas instalacji) lub z wiersza poleceń za pomocą polecenia hg.

5.3.4 Tworzenie repozytorium i praca z plikami

W Mercurial wszystko dzieje się wewnątrz repozytorium. Repozytorium projektu zawiera wszystkie pliki „związane” z projektem, a także historię modyfikacji tych plików. Istnieją trzy różne sposoby tworzenia repozytorium.

Aby utworzyć repozytorium za pomocą menu kontekstowego Eksploratora, wystarczy kliknąć prawym przyciskiem myszy żądany folder i wybrać odpowiedni element.

Rysunek 5.3.1 Tworzenie repozytorium

W wyświetlonym oknie możesz potwierdzić lokalizację folderu repozytorium i otworzyć utworzone repozytorium w środowisku produkcyjnym.

Rysunek 5.3.2 Lokalizacja folderu repozytorium

Repozytorium tworzone jest w podobny sposób bezpośrednio w oknie TortoiseHg Workbench: sekwencja Plik\Nowe repozytorium wywołuje powyższe okno o tej samej nazwie. W wierszu poleceń użyj polecenia hg init, aby utworzyć repozytorium w bieżącym katalogu<имя хранилища>. Utworzone repozytorium będzie zawierać katalog .hg.

Rysunek 5.3.3 Tworzenie folderu repozytorium za pomocą wiersza poleceń

Jeśli chcemy dodać istniejące pliki do repozytorium, kopiujemy je do katalogu roboczego i używamy polecenia hg add, aby poinformować Mercurial, aby zaczął je monitorować. Dodajmy plik do repozytorium i utwórzmy nową wersję.

Rysunek 5.3.4 Dodanie pliku do repozytorium i utworzenie nowej wersji

Upewnijmy się, że Mercurial widzi zapisany plik. Polecenie status wyświetla status kopii roboczej w porównaniu ze statusem lokalnego repozytorium. Mercurial pokazuje, że widzi plik example.txt, ale plik ten nie jest jeszcze objęty kontrolą wersji (znak „?” po lewej stronie nazwy pliku). Aby poinformować Mercurial, że wymaga wersji, uruchomimy hg add. Po lewej stronie nazwy pliku pojawia się symbol „A”, co oznacza, że ​​plik readme.txt zostanie dodany do systemu kontroli wersji podczas kolejnego zatwierdzenia (podczas tworzenia nowej wersji), które jest wykonywane komendą hg commit .

Polecenie hg commit może zakończyć się niepowodzeniem za pierwszym razem. Mercurial rejestruje Twoje imię i nazwisko oraz adres przy każdej zmianie, dzięki czemu Ty lub inni użytkownicy możecie skontaktować się z autorem każdej zmiany. Aby ustawić nazwę użytkownika, należy dokonać zmian w pliku hgrc znajdującym się w katalogu .hg wewnątrz katalogu roboczego. Początkowa zawartość tego pliku powinna wyglądać mniej więcej tak:

# To jest plik konfiguracyjny Mercurial.

nazwa użytkownika = imię i nazwisko [e-mail chroniony]

Linia „” deklaruje sekcję pliku konfiguracyjnego. Możesz przeczytać „nazwa użytkownika =…” jako „ustaw wartość zmiennej nazwy użytkownika w sekcji interfejsu użytkownika”. Sekcje są kontynuowane aż do rozpoczęcia nowych sekcji. Puste linie a linie zaczynające się od „#” są ignorowane. Możesz użyć dowolnego tekstu jako wartości nazwy użytkownika, ponieważ informacje te są przeznaczone do wykorzystania przez inne osoby, a nie do interpretacji przez firmę Mercurial.W powyższym przykładzie wykorzystano powszechną konwencję: kombinację imienia i nazwiska oraz adresu e-mail.

Kiedy zatwierdzamy zmiany, Mercurial przenosi nas do edytora tekstu, aby wprowadzić komentarz opisujący modyfikacje, które wprowadziliśmy w tym zestawie zmian. Taki opis nazywany jest komunikatem zmiany (opis zmian, opis rewizji). Będzie to zapis dla czytelników tego, co zrobiliśmy i dlaczego, i zostanie wyświetlony, gdy uruchomimy hg log po zakończeniu publikowania wersji.

Edytor otwierający się po uruchomieniu hg commit będzie zawierał pustą linię i kilka linii zaczynających się od „HG:”.

HG: Wprowadź wiadomość zatwierdzenia. Linie zaczynające się od „HG:” są usuwane.

HG: Pozostaw wiadomość pustą, aby przerwać zatwierdzenie.

HG: --

HG: użytkownik: użytkownik

HG: gałąź „domyślna”

HG: zmieniono przykład.txt

Mercurial ignoruje linie zaczynające się od „HG:”. Używa ich tylko do poinformowania nas, w których plikach zapisze zmiany. Edytowanie lub usuwanie tych linii nie będzie miało na nic wpływu. Jeśli podczas edytowania komentarza zmienisz zdanie na temat publikowania zmian, po prostu wyjdź z edytora bez zapisywania modyfikowany plik. Nie spowoduje to zmian ani w repozytorium, ani w katalogu roboczym.

Polecenie hg log domyślnie wyświetla tylko pierwszą linię opisu zmiany. Dlatego lepiej napisać komentarz tak, aby pierwsza linia była oddzielona. Pozostała część opisu wersji nie ma sztywnych reguł. Sam Mercurial nie przetwarza ani nie przejmuje się treścią komunikatów o zmianach, chociaż Twój projekt może mieć zasady narzucające określone formatowanie.

Powtórzmy te operacje używając GUI TortoiseHg Workbench. Przed dodaniem pliku do katalogu roboczego okno wygląda następująco.

Rysunek 5.3.5 Dodawanie pliku do katalogu roboczego

Przenieśmy plik do repozytorium i odświeżmy okno klikając na przycisk po lewej stronie na pasku narzędzi. Dodajmy plik do systemu kontroli wersji za pomocą odpowiedniej komendy z menu kontekstowego (podobnie jak hg add).

Rysunek 5.3.6 Polecenie menu kontekstowego

Rysunek 5.3.7 Dodawanie pliku

Po dodaniu pliku w prawym górnym oknie zapisywany jest opis rewizji, a po kliknięciu przycisku „Zatwierdź” tworzona jest nowa rewizja. W prawym dolnym oknie pojawi się zapis dokonanych zmian. Zauważysz, że zmiany są przedstawione w formie wykresów.

Rysunek 5.3.8 Zmień wykresy

Zmiany można także zatwierdzić komendą Hg Commit w menu kontekstowym pliku umieszczonego w repozytorium, bez konieczności uruchamiania Workbencha.

Rysunek 5.3.9 Zatwierdzanie zmian

Polecenie hg log lub hg diff odpowiada tutaj „Porównaj wersje plików” (kliknij prawym przyciskiem myszy nazwę pliku).

Rysunek 5.3.10 Porównanie wersji plików

W tym samym oknie możesz powrócić do jednej z poprzednich wersji za pomocą polecenia „Wróć do wersji…” lub „Cofnij zmiany…” w oknie głównym. Zademonstrujmy to na przykładzie, rejestrując najpierw więcej zmian w pliku przykład.txt. Linia podświetlona na czerwono oznacza zmiany odwrócone.

Rysunek 5.3.11 Anuluj zmiany

5.3.5 Tworzenie kopii repozytorium

Chociaż repozytorium można skopiować jak zwykły katalog, lepiej jest użyć wbudowanego polecenia Mercurial. Nazywa się to hg clone, ponieważ tworzy identyczną kopię istniejącego repozytorium. Jedną z zalet używania hg clone jest to, że umożliwia klonowanie repozytoriów przez sieć. Innym jest to, że pamięta, skąd go sklonowaliśmy.

Każde repozytorium Mercurial jest kompletne, samodzielne i niezależne. Zawiera własną kopię plików projektu i ich historię. Sklonowane repozytorium pamięta, skąd zostało sklonowane, ale nie komunikuje się z tym repozytorium ani żadnym innym, dopóki mu tego nie powiesz. Dlatego możesz swobodnie eksperymentować ze swoim repozytorium. Jest to bezpieczne, ponieważ Twoje repozytorium jest „zamkniętą piaskownicą”, w której zmiany nie będą miały wpływu na nic poza nim samym.

Stwórzmy zdalną kopię naszego magazynu (wykorzystamy folder Dysk Google, który sam w sobie jest usługą w chmurze), dla której wykonamy sekwencję poleceń File\Clone Storage w TortoiseHg Workbench. Wynik pokazano na poniższym rysunku.

Rysunek 5.3.12 Tworzenie zdalnej kopii magazynu

Mercurial pozwala nam wypchnąć zmiany do innego repozytorium z repozytorium, w którym się znajdujemy ten moment jesteśmy. Dodajmy nową wersję (pod komentarzem zmiany lokalnej) do repozytorium źródłowego i wykonajmy polecenie Storage\Synchronizacja\Push. Interfejs środowisko pracy pozwala wybrać tylko te wersje, które należy wypchnąć. Należy pamiętać, że dla otrzymanej wersji utworzono nową gałąź w repozytorium zdalnego skarbca.

...

Podobne dokumenty

Możliwości systemu kontroli wersji - programu przeznaczonego do pracy ze zmieniającymi się dokumentami. Jego właściwości i praktyki stosowania. Struktura wewnętrzna magazynu. Kopia robocza wersjonowanych dokumentów. Scentralizowany i rozproszony system VCS.

prezentacja, dodano 01.05.2014


Analiza metod i środków kontroli dostępu do plików. Problemy bezpieczeństwa podczas pracy z plikami, narzędzia kontroli dostępu. Ideologia budowy interfejsów, wymagania architektury. Działanie klas systemowych. Szacowanie kosztu produktu programowego.

teza, dodano 21.12.2012


Analiza architektury systemu operacyjnego Windows 8. Porównanie z poprzednimi wersjami (nowoczesny interfejs UI, praca z kontami, model bezpieczeństwa, menedżer zadań, historia plików, odzyskiwanie systemu, miejsca na dysku). Funkcje różnych wersji systemu Windows 8.

praca na kursie, dodano 25.01.2016


Etapy rozwoju zautomatyzowany system przyjmowanie i rezerwacja zamówień stolików w lokalach. Analiza środowiska programistycznego Android Development Tools. ogólna charakterystyka schematy komponentów aplikacje na iOS. Rozważenie systemu kontroli wersji serwera.

praca na kursie, dodano 14.05.2014


Interfejsy graficzne i rozszerzenia dla DOS-u. Historia rozwoju systemu operacyjnego Microsoft Windows. Innowacje współczesnych wersji: interfejs użytkownika, integracja językowa, systemy bezpieczeństwa. Chronologia rozwoju i architektura systemu GNU/Linux.

streszczenie, dodano 25.10.2010


Zestaw deweloperski DirectX dla systemu Microsoft Windows, charakterystyka zestawów obiektów zgodnych z COM wchodzących w jego skład. Najważniejsze cechy wersji, języki shaderów. Opis głównych używanych funkcji. Kod źródłowy programu, przykłady jego działania.

praca na kursie, dodano 16.02.2015


Windows jako pośrednik pomiędzy użytkownikiem a systemem operacyjnym, ułatwiający proces komunikacji pomiędzy nimi, historię powstawania i rozwój jego pierwszych wersji. Funkcje funkcjonalne I Różnice w Windowsie 95/98/ME i Windows NT/2000/XP/Vista/7, ich rozwiązania architektoniczne.

prezentacja, dodano 23.10.2013


Obniżenie kosztów napraw mających na celu usunięcie usterek, osiągnięte poprzez zastosowanie systemu informatycznego do ich kontroli. Analiza Tematyka i oprogramowanie. Obliczanie oszczędności dzięki zwiększonej produktywności użytkowników.

praca magisterska, dodana 19.01.2017


Pojęcie, istota, struktura i rodzaje systemów operacyjnych. Charakterystyka sali operacyjnej Systemy Windows XP, wymagania dotyczące jego instalacji, analiza porównawcza wersji, funkcje konfiguracyjne, aktualizacje wersji, instalacja sterowników urządzeń i dodawanie nowych.

streszczenie, dodano 20.10.2009


Pojawienie się pierwszych wersji systemu Windows interfejsy graficzne i rozszerzenia dla DOS-u. Rodziny Windows 3.x i Windows 9.x, ich cechy i główne funkcje. Ewolucja technologii Plug and Play. Najbardziej znaczące ulepszenia w nowoczesne wersje Okna.

Dziwię się, jak wielu inżynierów elektroników nie wykorzystuje w swoich projektach systemów kontroli wersji. Sama taka byłam, dopóki nie spróbowałam. Teraz każdy projekt zaczynam od stworzenia repozytorium.

Co to jest?

Tak więc systemy kontroli wersji (VCS) to program, który pozwala zapisać całą historię rozwoju projektu.

Dlaczego jest to konieczne?

To bardzo, naprawdę mega-wygodne narzędzie programistyczne. Zdarza się, że pisałeś i pisałeś program i w końcu coś zepsułeś. Jeżeli w programie była kontrola wersji to można łatwo wrócić do poprzedniej wersji projektu i zobaczyć co się zmieniło, wielokrotnie mnie to uratowało.

Na przykład niedawno zacząłem doświadczać ograniczeń prędkości w projekcie FPGA. W dosłownie 5 minut znalazłem wersję w której jeszcze się nie zawiesiły i znalazłem przyczynę

Jeśli nad projektem pracuje kilka osób, praca bez systemu sterowania jest prawie niemożliwa – zaczyna się chaos, każdy robi coś innego i nie jest jasne, kto co zrobił. Dzięki SUV-owi możesz wygodnie zobaczyć, kto co zrobił, zmiany dokonane przez innych stają się znacznie mniej nieoczekiwane.

Ponadto istnieją bardziej egzotyczne zastosowania. Na przykład przesyłam zmiany w tej witrynie na serwer za pomocą systemu kontroli wersji.

Który wybrać?

Istnieje ogromna różnorodność systemów kontroli wersji. Osobiście wybrałem dla siebie Mercurial. Świetny system, który polecam każdemu - szybki, wieloplatformowy, z doskonałym klientem graficznym. Istnienie serwisu okazało się bardzo mocnym argumentem na jego korzyść. Nigdy nie żałowałem swojego wyboru.

Oprócz Mercuriala, git i svn są teraz dość powszechne. Git jest bardziej powszechny w środowisku Linuksa, svn jest bardziej powszechny w środowisku korporacyjnym. Próbowałem z nich korzystać (choć nie na długo), ale nie widziałem niczego, co wskazywałoby na to, że warto byłoby rzucić Mercurial.

Istnieje strona internetowa, na której możesz przechowywać swoje projekty. Godne uwagi jest to, że w przeciwieństwie do githuba, można za darmo tworzyć zamknięte repozytoria (repozytorium to miejsce, w którym przechowywane są projekty). Płacisz tylko za te projekty, które są zamknięte i nad którymi pracuje więcej niż 5 osób. Jednocześnie limit można zwiększyć do 8 poprzez wysłanie zaproszeń. Jeszcze nie przekroczyłem tego limitu. Ponadto istnieje wiki i narzędzie do śledzenia błędów, ogólnie rzecz biorąc, wszystko, czego potrzebujesz do rozwijania projektów.

Kiedy zaczynałem z nim pracować, strona obsługiwała tylko Mercurial (częściowo z tego powodu wybrałem Mercurial), ale teraz możesz tam tworzyć repozytoria git. Dodatkowo możesz połączyć swoją domenę z bitbucketem. Oto na przykład moja wersja: hg.bsvi.ru

Jak zaczac?

Najpierw musisz pobrać klienta. Używam tortoiseHg. Myślę, że z montażem nie będzie żadnych problemów.

Po instalacji warto ustawić domyślną nazwę użytkownika. W tym celu należy edytować plik C:/Users/BSVi/mercurial.ini, należy tam dodać linię

Nazwa użytkownika = bsvi

Naturalnie bsvi należy zastąpić swoim imieniem i nazwiskiem.

Teraz jesteśmy gotowi stworzyć projekt i zacząć coś robić. W tym celu kliknij „Utwórz repozytorium”:

Tam podajemy nazwę, opis, wybieramy język. Możesz dodać wiki i narzędzie do śledzenia błędów.

Teraz kliknij przycisk „klonuj” i skopiuj to, co się tam pojawi:

Dalsze operacje zależą od używanego menedżera plików. Osobiście używam daleko. Po prostu wklejam skopiowany wiersz do wiersza poleceń:

Jeśli używasz Explorera (um), Total Commandera lub czegoś podobnego, musisz kliknąć prawym przyciskiem myszy i wybrać:


Tam w polu źródłowym należy wstawić ścieżkę oczywiście bez hg clone:

Zostaniesz poproszony o podanie hasła i pojawi się katalog test-repo, w którym tak naprawdę będzie zlokalizowany projekt.

Dodajmy kilka plików

Jeśli masz już opracowania dla projektu, możesz po prostu skopiować je do katalogu. W celach edukacyjnych utworzymy plik main.c o następującej zawartości:

#włączać int main() (zwróć 0; )

Teraz zobowiążmy się. Zatwierdzenie polega na wprowadzeniu zmian w projekcie. Aby to zrobić, uruchom hg workbench. Po prostu piszę thg w wierszu poleceń, dla odkrywców menedżery plików musisz nacisnąć RMB->Hg Workbench.

Obok naszego pliku pojawi się znak zapytania (oznacza to, że nie został on dodany do projektu). Zaznaczmy obok i napiszmy opis tego co zostało zrobione:


Oczywiście po tym kliknij przycisk „zatwierdź”.

To wszystko, w projekcie wprowadzono zmiany. Tutaj należy zwrócić uwagę, aby zmiany zostały wprowadzone tylko na komputerze lokalnym (to znaczy nie ma ich jeszcze na serwerze). Aby przenieść zmiany na serwer należy kliknąć przycisk „push”, oto on:

Naturalnie, aby przesłać zmiany na serwer, będziesz potrzebować hasła.

Zmieńmy plik

Przyjrzyjmy się teraz jednej z bardzo ważnych funkcji systemów kontroli wersji – śledzeniu wersji plików. Dodajmy wyjście ekranowe do naszego programu:

#włączać int main() ( printf("reguły rtęciowe!"); return 0; )

Przejdźmy do stołu roboczego hg. Kiedy pracuję nad projektem, nawet go nie zamykam (więcej o tym później), wciskam f5, żeby zaktualizować listę plików. Teraz możesz zobaczyć, co się zmieniło od ostatniego zatwierdzenia:

A to jest bardzo potężne narzędzie. Zwykle podczas debugowania w plikach pojawia się mnóstwo różnych śmieci. Zatem przyjrzenie się temu, co zamierzasz zatwierdzić, bardzo dobrze oczyszcza projekt ze śmieci.

Co zrobić ze śmieciami?

Podczas pracy nad projektem pojawia się dużo śmieci - na przykład pliki obiektowe, pliki wygenerowane przez IDE, niektóre pliki tymczasowe, i tak dalej. Byłoby miło usunąć z repozytorium wszystko co nie jest związane z samym projektem. Istnieje plik this.hgignore (tak, z kropką na początku nazwy).

Dodajmy plik śmieci do projektu. Na przykład stworzyłem main.obj:

Jeśli teraz zaktualizujesz listę plików, hg workbench zaproponuje dodanie tego pliku do projektu:

Utwórzmy teraz plik.hgigonre i napiszmy tam, że chcemy ignorować wszystkie pliki z rozszerzeniem obj:
składnia:glob *.obj

Jeśli zaktualizujesz listę plików, pliki obj znikną, ale pojawi się plik .hgignore, który można zatwierdzić:

Jak mogę cofnąć zmiany?

Przywróćmy nasz program do stanu jaki miał przed wyświetleniem na ekranie. Aby to zrobić, po prostu wybierz zatwierdzenie, do którego chcesz przywrócić, i kliknij ten przycisk:

Możesz przywrócić oddzielny plik w prawie ten sam sposób.

Wniosek

To wszystko, to minimalna wiedza na temat systemów kontroli wersji, która pozwoli Ci zapisać historię rozwoju projektu. Oczywiście istnieje wiele innych możliwości, o których powiem później.

Wiele osób uważa, że ​​systemy kontroli wersji powinny być używane tylko wtedy, gdy tworzysz coś w dużym gronie, ale to nieprawda :) Nawet jeśli pracujesz nad projektem w pojedynkę, systemy kontroli wersji są bardzo pomocne.

Dla przykładu, oto zrzut ekranu mojego UTC (który sam rozwijam) w najtrudniejszym miejscu w środowisku roboczym hg:

Misza Radionow

Czym są systemy kontroli wersji i dlaczego ich potrzebujesz?

Wrócić do

Wyobraź sobie sytuację: zatrudniłeś programistę, aby dodał na przykład funkcję szybkiego składania zamówień do Twojego sklepu internetowego. Ponieważ strona musi cały czas funkcjonować i generować dochód, deweloper decyduje się na prowadzenie prac na swoim lokalnym serwerze.

Podczas pracy projektant wysłał nowe logo, który natychmiast zastąpiłeś w szablonie w głównej wersji witryny. Jednocześnie zmniejszyłeś czcionkę w nazwach produktów tak, aby wszystko mieściło się na ekranie netbooka jednego z Twoich klientów. Następnie zaktualizowałeś kilka zdjęć produktów. W tym momencie programista postanowił wyświadczyć Ci przysługę - usunąć ze swojej wersji witryny szczerze niepotrzebne funkcje, które napisał poprzedni programista. Jak to często bywa, oboje myślicie, że nie zrobiliście nic poważnego. Ale mylisz się.

Kiedy wersja deweloperska zostaje przesłana na stronę, wszyscy uczestnicy prac nad nią łapią się za głowy. Wyniki Twojej pracy zostają usunięte, pojawiają się błędy. Nie jest jasne, na czym polega problem. Miejmy nadzieję, że w tym momencie będziesz mieć przynajmniej działającą kopię zapasową pod ręką, a w najgorszym przypadku spędzisz kilka dni na ręcznym wychwytywaniu problemów. Jak nie wpaść w taką sytuację? Porozmawiajmy.

Co to jest VCS?

System kontroli wersji (z angielskiego Version Control System, VCS lub Revision Control System) - oprogramowanie ułatwiające pracę ze zmieniającymi się informacjami. Wikipedia

A teraz w prosty sposób

System kontroli wersji umożliwia przechowywanie wielu wersji tego samego dokumentu, w razie potrzeby przywracanie wcześniejszych wersji, ustalanie, kto i kiedy dokonał konkretnej zmiany, i wiele więcej.

Innymi słowy, VCS umożliwia wielu programistom jednoczesne modyfikowanie tych samych plików bez tworzenia lokalnych kopii na ich komputerach. W takim przypadku wszystkie opcje modyfikacji są zapisywane osobno i można je wykonać różne warianty ten sam plik, biorąc pod uwagę różne edycje z różni ludzie. Jeżeli kilka zmian dotyczy tego samego fragmentu dokumentu, system poprosi Cię o wybranie żądanej opcji.

Zazwyczaj do pracy z systemem kontroli wersji wykorzystywany jest osobny komputer (serwer) lub usługa internetowa, która zapewnia możliwość wynajmu takiego serwera.

Prosty przykład

Jeśli nad jednym dokumentem Excela pracuje kilka osób, to tylko jedna osoba może edytować plik, reszta ma dostęp tylko do odczytu. Korzystając z VCS, zyskujesz możliwość edycji pliku jednocześnie i przez wszystkich. Jedynym warunkiem jest to, że po dokonaniu zmian plik musi zostać zapisany na serwerze, a nie na komputer lokalny. Ale jak wspomniano powyżej, narzędzia pozwalają na łatwe i proste wykonywanie takich czynności.

System kontroli wersji w studiu Flag

W naszej pracy wykorzystujemy system kontroli wersji Git. System ten jest jednym z najpopularniejszych VCS. Powoduje to duże wsparcie ze strony społeczności Git. Kolejną zaletą jest łatwość opanowania systemu, ponieważ... istnieje szerokie spektrum produkty oprogramowania opracowany specjalnie dla tego systemu.

Korzystamy z programu do tworzenia kodu o nazwie IntelliJ IDEA. Udostępnia IDE, czyli dużą bazę funkcjonalną dla programistów m.in Przyjazny dla użytkownika interfejs na temat pracy z kontrolą wersji. Tak więc bez wychodzenia z programu możemy zobaczyć, jakie zmiany wprowadził ten czy inny programista w potrzebnej nam witrynie. Lub, bez obawy o utratę zmian, pobierz zmiany wprowadzone przez innego programistę. Interfejs IDEA wygląda mniej więcej tak:

Do przechowywania wersji korzystamy z usługi chmurowej Bitbucket. Usługa ta posiada wygodny interfejs i poza usługą przechowywania Twoich wersji, umożliwia zarządzanie regułami dostępu do Twoich produktów różni użytkownicy. Zaletą korzystania z przechowywania w chmurze jest to, że nie ma wymagań dotyczących znajomości konfiguracji i administracji serwerem. Dostajesz wszystko po wyjęciu z pudełka i możesz od razu zacząć z niego korzystać. Wszystko, co przesyłasz do Bitbucket, jest prywatne, tj. bez Twojej zgody nikt inny nie może nawet zobaczyć, co przechowujesz. Interfejs Bitbucketa:

Co daje nam korzystanie z VCS?

• Pełna pewność, że pliki, które otrzymujemy z systemu, są zawsze aktualne w danym momencie.
• Możliwość uzyskania wymaganej wersji z dowolnego komputera umożliwiającego połączenie się z serwerem.
• Zapisując plik w VCS nie musisz myśleć o tym, że ktoś pracujący z tym samym plikiem ponownie zapisze i nadpisze zmiany.
• Dla twórców oprogramowania korzystanie z systemu umożliwia także akceptację/odrzucenie zmian wprowadzonych przez jednego z twórców.

Co to daje naszym klientom?

Wróćmy do sytuacji omówionej na początku. Podobnie jak w przypadku VCS. Deweloper przesyła swój kod do osobnej gałęzi. Przeglądasz zmiany i stosujesz je tylko wtedy, gdy widzisz, że wszystko jest w porządku. Wszystko przechowywane jest w jednym miejscu, bezpiecznie, szybko i wygodnie. A gdy jest kilku programistów, w ogóle nie obejdzie się bez VCS.

Włącz JavaScript, aby zobaczyć

Podstawy VCS

Wstęp

Zanim zaczniesz mówić o jakimkolwiek konkretnym systemie kontroli wersji, musisz zrozumieć, czym jest, czym jest i dlaczego w ogóle się pojawił. Wykład ten ma na celu wstępne wprowadzenie w tematykę kontroli wersji i systemów kontroli wersji, najpierw omówię genezę narzędzi kontroli wersji, które systemy kontroli wersji są obecnie popularne i jakie są główne różnice między nimi.

O kontroli wersji

Co to jest kontrola wersji i dlaczego jej potrzebujesz?

Warto chyba zacząć od zdefiniowania systemu kontroli wersji (VCS) – jest to system rejestrujący zmiany w jednym lub większej liczbie plików, aby w przyszłości można było wrócić do pewnych starych wersji tych plików.

Ostatnio pliki są efektem końcowym wielu zawodów (na przykład pisania, pracy naukowej i oczywiście tworzenia oprogramowania). Tworzenie i utrzymywanie tych plików zajmuje dużo czasu i wysiłku, a nikt nie chce poświęcać jeszcze więcej czasu i wysiłku na odzyskiwanie danych utraconych w wyniku jakichkolwiek zmian.

Wyobraźmy sobie, że programista tworzy projekt składający się z jednego małego pliku (swoją drogą, przykład jest całkiem realny, a nie syntetyczny i spotkał się z realnym życiem). Po wydaniu pierwszej wersji projektu staje przed trudnym wyborem: trzeba naprawić problemy zgłaszane przez użytkowników pierwszej wersji i jednocześnie opracować coś nowego dla drugiej. Nawet jeśli wystarczy tylko naprawić powstałe problemy, istnieje duże prawdopodobieństwo, że po jakiejś zmianie projekt przestanie działać i trzeba określić, co zostało zmienione, aby ułatwić zlokalizowanie problemu. Wskazane jest także prowadzenie pewnego rodzaju dziennika wprowadzonych zmian i poprawek, aby nie wykonywać tej samej pracy kilka razy.

W najprostszym przypadku powyższy problem można rozwiązać przechowując kilka kopii plików, np. jedną do naprawy błędów w pierwszej wersji projektu i drugą do nowych zmian. Ponieważ zmiany zwykle nie są zbyt duże w porównaniu z rozmiarem pliku, możliwe jest przechowywanie tylko zmienionych linii za pomocą narzędzia diff, a później połączenie ich za pomocą narzędzia łatka. Co jednak, jeśli projekt składa się z kilku tysięcy plików i pracuje nad nim sto osób? Jeśli w tym przypadku użyjemy metody z magazynowaniem oddzielne kopie plików (lub nawet samych zmian), wówczas projekt bardzo szybko się zatrzyma. W kolejnych wykładach będę posługiwał się kodami źródłowymi programów jako przykładami, ale tak naprawdę niemal każdy typ pliku może zostać objęty kontrolą wersji.

Jeśli jesteś grafikiem lub projektantem stron internetowych i chciałbyś przechowywać każdą wersję obrazu lub układu – a prawdopodobnie byś to zrobił – wówczas skorzystanie z systemu kontroli wersji jest bardzo mądrą decyzją. VCS umożliwia powrót do poszczególnych plików jak wcześniej, wrócić do Poprzedni stan całego projektu, przeglądaj zmiany zachodzące w czasie, ustalaj, kto jako ostatni wprowadzał zmiany w module, który nagle przestał działać, kto i kiedy wprowadził jakiś błąd do kodu i wiele więcej. Ogólnie rzecz biorąc, jeśli podczas korzystania z VCS wszystko zepsujesz lub stracisz pliki, wszystko można łatwo przywrócić. Ponadto koszty ogólne wszystkiego, co otrzymasz, będą bardzo małe.

Lokalne systemy kontroli wersji

Jak wspomniano wcześniej, jeden z przykładów lokalnego SUV-a jest niezwykle prosty: wiele osób woli kontrolować wersje, po prostu kopiując pliki do innego katalogu (zwykle dodając bieżąca data do nazwy katalogowej). To podejście jest bardzo powszechne, ponieważ jest proste, ale też częściej zawodzi. Bardzo łatwo jest zapomnieć, że jesteś w złym katalogu i przypadkowo zmienić niewłaściwy plik lub skopiować pliki w niewłaściwe miejsce i nadpisać potrzebne pliki. Aby rozwiązać ten problem, programiści od dawna opracowują lokalny VCS z prostą bazą danych, która przechowuje wszystkie zmiany w niezbędnych plikach

Jednym z najpopularniejszych VCS-ów tego typu jest RCS (Revision Control System), który do dziś jest instalowany na wielu komputerach. Nawet w nowoczesnym systemie operacyjnym Mac OS X narzędzie rcs jest instalowane wraz z narzędziami programistycznymi. RCS został opracowany na początku lat 80. XX wieku przez Waltera F. Tichy'ego. System umożliwia przechowywanie wersji tylko jednego pliku, dlatego trzeba zarządzać wieloma plikami ręcznie. Informacje o wersji każdego pliku kontrolowanego przez system są przechowywane w specjalny plik z nazwą oryginalnego pliku, do której na końcu dodawane są znaki „,v”. Na przykład dla pliku file.txt wersje będą zapisane w pliku file.txt,v. Narzędzie to opiera się na pracy z zestawami poprawek pomiędzy parami wersji (łatka to plik opisujący różnicę między plikami). Pozwala to na odtworzenie dowolnego pliku w dowolnym momencie, nakładając poprawki sekwencyjnie. System używa narzędzia diff do przechowywania wersji. Chociaż RCS spełnia minimalne wymagania dla systemu kontroli wersji, ma następujące główne wady, które stały się również impulsem do stworzenia rozważanego systemu:

• Pracuj tylko z jednym plikiem, każdy plik musi być kontrolowany osobno;
• Niewygodny mechanizm jednoczesna praca kilku użytkowników z systemem, pamięć jest po prostu blokowana, dopóki użytkownik, który ją zablokował, nie odblokuje jej;
• Nikt nie zwalnia Cię z kopii zapasowych, ryzykujesz utratę wszystkiego.

Scentralizowane systemy kontroli wersji

Kolejnym poważnym wyzwaniem była konieczność współpracy z programistami na innych komputerach. Aby rozwiązać ten problem, stworzono scentralizowane systemy kontroli wersji (CVCS). Takie systemy, jak CVS, Subversion i Perforce, posiadają centralny serwer, który przechowuje wszystkie pliki pod kontrolą wersji, oraz pewną liczbę klientów, którzy otrzymują od niego kopie plików. Od wielu lat jest to standard w systemach kontroli wersji.

To podejście ma wiele zalet, szczególnie w porównaniu z lokalnym SLE. Na przykład każdy wie, kto co robi w projekcie. Administratorzy mają jasną kontrolę nad tym, kto może co robić, a CSKB jest oczywiście znacznie łatwiejsze w administrowaniu niż lokalne bazy danych na każdym kliencie. Jednakże podejście to ma kilka poważnych wad. Najbardziej oczywistym jest to, że scentralizowany serwer jest słabym punktem całego systemu. Jeśli serwer przestanie działać na godzinę, programiści nie będą mogli przez godzinę wchodzić w interakcje i nikt nie będzie mógł zapisać nowej wersji swojej pracy. Jeżeli dysk z centralną bazą danych ulegnie uszkodzeniu i nie będzie kopii zapasowej, tracisz absolutnie wszystko – całą historię projektu, z możliwym wyjątkiem kilku działających wersji zapisanych na komputerach roboczych użytkowników.

CVS

CVS (Concurrent Versions System) jest wciąż najpopularniejszym systemem, jednak szybko traci na popularności ze względu na niedociągnięcia, które omówię poniżej. Dick Grune opracował CVS w połowie lat 80. Do przechowywania pojedynczych plików CVS (podobnie jak RCS) wykorzystuje pliki w formacie RCS, ale pozwala na zarządzanie grupami plików zlokalizowanymi w katalogach. CVS wykorzystuje również architekturę klient-serwer, w której wszystkie informacje o wersji są przechowywane na serwerze. Zastosowanie architektury klient-serwer pozwala na korzystanie z CVS nawet przez rozproszone geograficznie zespoły użytkowników, gdzie każdy użytkownik ma swój własny katalog roboczy z kopią projektu. Jak sama nazwa wskazuje, użytkownicy mogą współużytkować system.

Ewentualne konflikty przy zmianie tego samego pliku rozwiązuje fakt, że system dopuszcza zmiany tylko do najnowszej wersji pliku. Dlatego zawsze zaleca się aktualizację kopii roboczej plików przed przesłaniem zmian w przypadku ewentualnych sprzecznych zmian. Podczas aktualizacji system automatycznie dokonuje zmian w kopii roboczej i dopiero w przypadku kolidujących ze sobą zmian w jednej z lokalizacji plików wymagana jest ręczna korekta konfliktowej lokalizacji.

CVS pozwala również na utrzymanie wielu linii rozwoju projektu przy użyciu gałęzi programistycznych. Tym samym, jak wspomniano powyżej, można poprawić błędy w pierwszej wersji projektu i jednocześnie opracować nową funkcjonalność.

CVS był używany w dużej liczbie projektów, ale oczywiście nie był pozbawiony wad, które później doprowadziły do ​​pojawienia się kolejnego rozważanego systemu. Spójrzmy na główne wady:

• Ponieważ wersje są przechowywane w plikach RCS, nie jest możliwe zapisanie wersji katalogowych. Metoda standardowa aby ominąć tę przeszkodę, należy zapisać jakiś plik (na przykład README.txt) w katalogu;
• Przenoszenie lub zmiana nazwy plików nie podlega kontroli wersji. Standardowym sposobem na to jest najpierw skopiowanie pliku, usunięcie starego za pomocą polecenia cvs Remove, a następnie dodanie go pod nową nazwą za pomocą polecenia cvs add;

Obalenie

Subversion (SVN) powstał w 2000 roku z inicjatywy CollabNet. SVN został pierwotnie opracowany jako „lepszy CVS”, a głównym celem twórców było poprawienie błędów popełnionych w projekcie CVS przy zachowaniu podobnego interfejsu. SVN, podobnie jak CVS, wykorzystuje architekturę klient-serwer. Do najważniejszych zmian w porównaniu do CVS należą:

• Zmiany atomowe (zatwierdzenie). Jeśli przetwarzanie zatwierdzeń zostanie przerwane, nie zostaną wprowadzone żadne zmiany.
• Zmiana nazwy, kopiowanie i przenoszenie plików powoduje zachowanie całej historii zmian.
• Katalogi, dowiązania symboliczne i metadane podlegają kontroli wersji.
• Wydajne przechowywanie zmian w plikach binarnych.

Rozproszone systemy kontroli wersji

W tej sytuacji do gry wchodzą rozproszone systemy kontroli wersji (DVCS). W systemach takich jak Git, Mercurial, Bazaar czy Darcs klienci nie tylko sprawdzają najnowsze wersje plików, ale kopiują całe repozytorium. Dlatego w przypadku, gdy serwer, przez który przebiegała praca, „umarł”, dowolne repozytorium klienta można skopiować z powrotem na serwer w celu przywrócenia bazy danych. Za każdym razem, gdy klient odbiera nową wersję plików, tworzy ją dla siebie pełna kopia wszystkie dane.

Dodatkowo większość tych systemów umożliwia pracę z wieloma zdalnymi repozytoriami, dzięki czemu można pracować odmiennie z różnymi grupami osób nad tym samym projektem w tym samym czasie. Tym samym w jednym projekcie można jednocześnie prowadzić kilka rodzajów procesów roboczych, co jest niemożliwe w systemach scentralizowanych.

Dlaczego potrzebne są systemy rozproszone?

Jak sama nazwa wskazuje, jedną z głównych idei systemów rozproszonych jest brak wyraźnie wyznaczonego centralnego magazynu wersji – repozytorium. W przypadku systemów rozproszonych zestaw wersji może być w całości lub częściowo dystrybuowany pomiędzy różnymi repozytoriami, w tym także zdalnymi. Model ten doskonale wpisuje się w pracę rozproszonych zespołów, np. zespołu programistów rozproszonych po całym świecie pracujących nad jednym projektem open source. kod źródłowy. Twórca takiego zespołu może pobrać wszystkie informacje o wersji i następnie pracować tylko na komputerze lokalnym. Po osiągnięciu wyniku jednego z etapów prac zmiany można wgrać do jednego z centralnych repozytoriów lub opublikować do wglądu na stronie internetowej dewelopera lub w Lista mailingowa. Pozostali uczestnicy projektu będą mogli z kolei zaktualizować swoją kopię repozytorium wersji o nowe zmiany lub wypróbować opublikowane zmiany na osobnej, testowej gałęzi deweloperskiej. Niestety bez dobrej organizacji projektu brak jednego centralnego repozytorium może być wadą systemów rozproszonych. Jeśli w przypadku systemów scentralizowanych zawsze istnieje jedno wspólne repozytorium, z którego można pobrać najnowszą wersję projektu, to w przypadku systemów rozproszonych trzeba organizacyjnie zdecydować, która z gałęzi projektu będzie główna. Dlaczego system rozproszony kontrola wersji może zainteresować kogoś, kto już korzysta ze scentralizowanego systemu - takiego jak Subversion? Każda praca wiąże się z podejmowaniem decyzji i w większości przypadków trzeba wypróbować różne opcje: podczas pracy z systemami kontroli wersji gałęzie programistyczne służą do rozważania różnych opcji i pracy nad dużymi zmianami. Chociaż jest to dość naturalna koncepcja, nie jest łatwa w użyciu w Subversion. Co więcej, wszystko komplikuje się w przypadku wielokrotnych, sekwencyjnych łączeń z jednej gałęzi do drugiej - w tym przypadku trzeba dokładnie wskazać wersję początkową i końcową każdej zmiany, aby uniknąć konfliktów i błędów. W przypadku rozproszonych systemów kontroli wersji gałęzie rozwojowe są jednym z podstawowych pojęć - w większości przypadków każda kopia magazynu wersji jest gałęzią programistyczną. Zatem mechanizm łączenia zmian z jednej gałęzi do drugiej w przypadku systemów rozproszonych jest jednym z głównych, który pozwala użytkownikom wkładać mniej wysiłku w obsługę systemu.

Krótki opis popularnych dystrybuowanych SUV-ów

• Git to rozproszony system kontroli wersji opracowany przez Linusa Torvaldsa. Git był pierwotnie przeznaczony do wykorzystania w procesie programowania Jądra Linuksa, ale później zaczęto go wykorzystywać w wielu innych projektach – takich jak np. X.org i Ruby on Rails, Drupal. Git jest obecnie najszybszym systemem rozproszonym korzystającym z najmniejszego magazynu wersji. Ale jednocześnie dla użytkowników migrujących na przykład z Subversion interfejs Git może wydawać się skomplikowany;
• Mercurial jest napisanym systemem rozproszonym Język Pythona z kilkoma rozszerzeniami w C. Projekty korzystające z Mercurial obejmują Mozilla i MoinMoin.
• Bazaar to system opracowany przez firmę Canonical, znaną z dystrybucji Ubuntu i strony internetowej https://launchpad.net/. System jest napisany głównie w języku Python i jest używany w projektach takich jak MySQL.
• Codeville to system rozproszony napisany w Pythonie, który wykorzystuje innowacyjny algorytm łączenia zmian (scalania). System wykorzystywany jest m.in. przy tworzeniu autorskiego klienta BitTorrent.
• Darcs to rozproszony system kontroli wersji napisany w Haskell, używany między innymi przez projekt Buildbot.
• Monotone to system napisany w C++ i wykorzystujący SQLite jako magazyn wersji.

Pytanie byłoby na miejscu 25 lat temu. Od około 10 lat korzystanie z systemu kontroli wersji jest koniecznością dla każdego zespołu. Wspólne, wygodne, bezpieczne przechowywanie kodów źródłowych z historią zmian, zbiorową własnością kodu, podziałem zadań i funkcjonalnością aplikacji w ramach zespołu. Oprócz automatyzacji kompilacji, wdrożeń i ogólnie ciągłej integracji.

Iwan Niemyczenko, GitLab
Ułatw sobie życie, wspólnie opracowując oprogramowanie.

Aleksander Makarczuk, qb
Optymalizacja rozwoju zespołu.

Petr Urwajew, SimbirSoft
Podczas programowania kod projektu aktywnie się zmienia. Jednocześnie konieczne jest prowadzenie ewidencji tego, co już zostało zrobione i koordynowanie działań poszczególnych uczestników, aby jednocześnie zmieniać kod tak, aby ulepszenia wprowadzane przez uczestników projektu uwzględniały wszystkie wcześniej wprowadzone zmiany przez innych uczestników. System kontroli wersji pozwala zautomatyzować ten proces.

2. Jakie czynniki wpływają na wybór systemu kontroli wersji?

Nikołaj Fetiukhin,MST
Wsparcie jądra systemu kontroli wersji i jego specyficznej implementacji, zapoznanie z nim zespołu. Najczęściej do wszystkich projektów wykorzystywany jest jeden system. Wyjątkiem mogą być na przykład wymagania klienta.

Iwan Niemyczenko, GitLab
Popularność konkretnego systemu, z którego wynika wszystko inne: wsparcie w zakresie aplikacji i usług, ilość i jakość dokumentacji, dostępność eksperta „w pobliżu” itp.

Aleksander Makarczuk, qb
W naszym przypadku wybór opiera się na popularności systemu kontroli wersji i poziomie biegłości w jego obsłudze programistów.

Petr Urwajew, SimbirSoft
Przede wszystkim możliwości systemu kontroli wersji odpowiadają przyjętemu przez zespół procesowi rozwoju. Po drugie, z jakim systemem kontroli wersji najczęściej korzystają uczestnicy projektu?

3. Jak wdrożyć wykorzystanie kontroli wersji w zespole?

Nikołaj Fetiukhin,MST
Obecnie nawet współcześni studenci kończą studia z ogólnym zrozumieniem, dlaczego potrzebne są systemy kontroli wersji, więc kwestia wdrożenia nie jest do końca poprawna. Zwykle wszystkie projekty rozpoczynają się od domyślnego utworzenia repozytorium. Jeśli w ogólnym przypadku powinieneś porozmawiać z zespołem, dowiedzieć się, dlaczego w projekcie nie ma systemu kontroli wersji (czasami istnieją różne bardzo specyficzne przypadki) i jeśli problemy można przezwyciężyć, zorganizuj kilka seminariów w zespole w określonym systemie kontroli wersji (jeśli jest to wymagane) i uruchom.

Iwan Niemyczenko, GitLab
Daj im możliwość pracy bez systemu kontroli wersji, aby odczuli cały ból. Następnie „wsuń” im ściągawkę Git, a oni sami nauczą się i zaimplementują wszystko. Ale w ten sposób możesz pracować z dziećmi w wieku szkolnym i studentami. Dojrzali programiści zwykle nie mają tego pytania.

Aleksander Makarczuk, qb
Powoli, ale pewnie, każdy dochodzi do tego sam.

Petr Urwajew, SimbirSoft
W większości nowoczesne projekty Konieczność stosowania systemu kontroli wersji nie budzi żadnych wątpliwości. Kiedy już nauczymy się z nim pracować, wystarczy go odpowiednio skonfigurować komfortową pracę i przeczytaj krótki wykład na temat głównych możliwości zastosowanego systemu kontroli wersji, podając przykłady użycia.

4. Co sprawiło, że Git stał się standardem w świecie systemów kontroli wersji? Czy ktoś będzie w stanie wyprzeć go z wiodącej pozycji?

Nikołaj Fetiukhin,MST
Git pierwotnie wprowadził kilka przydatnych rzeczy, takich jak lokalne zatwierdzenia, a także rozwiązał wiele problemów z łączeniem gałęzi, które nękały poprzedniego twórcę trendów, Subversion (SVN). Od samego początku walczył o popularność z Mercurialem (Hg), który pod pewnymi względami jest prostszy, ale ostatecznie objął prowadzenie.

Iwan Niemyczenko, GitLab
Dzięki temu, że Linus Torvalds zaatakował problem rozwoju rozproszonego od prawej strony, biorąc pod uwagę mankamenty poprzednich systemów. Przenosić? Po co?

Aleksander Makarczuk, qb
Dzięki temu, że Git jest świetny. Nikt go nie zastąpi przez bardzo długi czas.

Petr Urwajew, SimbirSoft
Główną zaletą Gita jest rozwój narzędzi do pracy z nim i możliwość przechowywania w nim wyników pracy nad kilkoma równoległymi otwartymi zadaniami, dzięki czemu wyniki pośrednie nie wpływają na siebie, a jednocześnie wyniki końcowe mogą można dość łatwo połączyć w jedną ostateczną wersję aplikacji. Ważną rolę w powszechnej popularności Gita w świecie CVS odegrał także zasób GitHub, w którym znajdują się tysiące repozytoriów w różnych językach.

5. Czego programiści nie lubią w Git? Dlaczego niektórzy wybierają inne, mniej popularne rozwiązania?

Nikołaj Fetiukhin,MST
Jedyną istotną wadą Gita dla nas są pewne problemy ze śledzeniem zmian: gałęzie można usunąć, a może pozostać jedynie zatwierdzenie scalania. Dzieje się tak głównie dlatego, że Git ma gałęzie dołączone do zatwierdzeń. Git ma również bardziej stromą krzywą uczenia się niż wspomniany wcześniej Mercurial lub Subversion.

Aleksander Makarczuk, qb
W ramach naszych zadań każdy jest zadowolony.

Petr Urwajew, SimbirSoft
Git jest całkiem wygodny, ale wymaga nauki (dla tych, którzy jeszcze go nie znają) i aktywnych kroków, aby się na niego przestawić, więc niektóre zespoły wolą pozostać przy używanych przez siebie systemach kontroli wersji. Również wybór systemu kontroli wersji może być uzależniony od zastosowanych narzędzi programistycznych.

6. Jak powszechne jest wykorzystywanie systemów kontroli wersji do zarządzania plikami innymi niż tylko kod?

Nikołaj Fetiukhin,MST
Obecnie wszędzie. Te same systemy chmurowe, jak One Drive, Yandex.Disk, Dropbox i Google Drive, opierają się na ideologii replikującej systemy kontroli wersji.

W praktyce stosowanie konwencjonalnych systemów kontroli wersji do przechowywania dokumentów jest powszechne, ale niezbyt powszechne; przy obliczaniu zmian pojawiają się subtelności, ponieważ większość współczesnych popularnych formatów dokumentów jest binarna, a ich zestawy zmian nie są czytelne dla człowieka.

Aleksander Makarczuk, qb
Stale używany.

Petr Urwajew, SimbirSoft
Systemy kontroli wersji są nastawione przede wszystkim na pracę z dużą liczbą małych plików, co jest wykorzystywane głównie w programowaniu. Stosowanie podobne systemy w przypadku plików w formatach nietekstowych (binarnych) z reguły jest to nieskuteczne, a w niektórych przypadkach całkowicie niemożliwe. Dlatego też do przechowywania innych plików wykorzystuje się zazwyczaj specjalizowane systemy, przystosowane do pracy z określonymi formatami danych.