Rozproszona kontrola wersji - Distributed version control

W rozwoju oprogramowania , rozproszona kontrola wersji (znana również jako rozproszona kontrola wersji ) jest formą kontroli wersji, w której cała baza kodu , w tym jej pełna historia, jest dublowana na komputerze każdego programisty. W porównaniu ze scentralizowaną kontrolą wersji umożliwia to automatyczne rozgałęzianie i łączenie zarządzania , przyspiesza większość operacji (z wyjątkiem wypychania i wyciągania), poprawia możliwość pracy w trybie offline i nie polega na jednej lokalizacji kopii zapasowych. Git , najpopularniejszy na świecie system kontroli wersji, to rozproszony system kontroli wersji.

W 2010 roku autor oprogramowania, Joel Spolsky, opisał rozproszone systemy kontroli wersji jako „prawdopodobnie największy postęp w technologii tworzenia oprogramowania w ciągu ostatnich dziesięciu lat”.

Rozproszone a scentralizowane

Rozproszone systemy kontroli wersji (DVCS) wykorzystują podejście peer-to-peer do kontroli wersji, w przeciwieństwie do podejścia klient-serwer w systemach scentralizowanych. Rozproszona kontrola wersji synchronizuje repozytoria poprzez przesyłanie poprawek od peera do peera. Nie ma jednej centralnej wersji bazy kodu; zamiast tego każdy użytkownik ma kopię roboczą i pełną historię zmian.

Zalety DVCS (w porównaniu z systemami scentralizowanymi) to:

  • Umożliwia użytkownikom wydajną pracę bez połączenia z siecią.
  • Typowe operacje (takie jak zatwierdzanie, przeglądanie historii i cofanie zmian) są szybsze w przypadku DVCS, ponieważ nie ma potrzeby komunikowania się z serwerem centralnym. W przypadku DVCS komunikacja jest konieczna tylko w przypadku udostępniania zmian innym równorzędnym użytkownikom.
  • Pozwala na pracę prywatną, dzięki czemu użytkownicy mogą używać swoich zmian nawet w przypadku wczesnych wersji roboczych, których nie chcą publikować.
  • Kopie robocze skutecznie działają jako zdalne kopie zapasowe, co pozwala uniknąć polegania na jednej fizycznej maszynie jako pojedynczym punkcie awarii.
  • Umożliwia stosowanie różnych modeli rozwoju, takich jak wykorzystanie gałęzi rozwoju lub modelu dowódcy/porucznika.
  • Umożliwia scentralizowaną kontrolę „wydanej wersji” projektu
  • W przypadku projektów oprogramowania FOSS znacznie łatwiej jest utworzyć widelec projektowy z projektu, który został zablokowany z powodu konfliktów przywództwa lub nieporozumień projektowych.

Wady DVCS (w porównaniu z systemami scentralizowanymi) obejmują:

  • Wstępne pobieranie repozytorium jest wolniejsze w porównaniu do pobierania w scentralizowanym systemie kontroli wersji, ponieważ wszystkie gałęzie i historia wersji są domyślnie kopiowane na komputer lokalny.
  • Brak mechanizmów blokowania, które są częścią większości scentralizowanych systemów VCS i nadal odgrywają ważną rolę, jeśli chodzi o niescalalne pliki binarne, takie jak zasoby graficzne lub zbyt złożone jednoplikowe pakiety binarne lub XML (np. dokumenty biurowe, pliki PowerBI, SQL Server Pakiety narzędzi danych BI itp.).
  • Dodatkowa pamięć wymagana dla każdego użytkownika, aby mieć pełną kopię pełnej historii kodu.
  • Zwiększona ekspozycja bazy kodu, ponieważ każdy uczestnik ma lokalnie wrażliwą kopię.

Niektóre pierwotnie scentralizowane systemy oferują teraz pewne funkcje rozproszone. Na przykład Subversion może wykonywać wiele operacji bez sieci. Team Foundation Server i Visual Studio Team Services obsługują teraz scentralizowane i rozproszone repozytoria kontroli wersji za pośrednictwem usługi Git.

Podobnie niektóre systemy rozproszone oferują teraz funkcje, które łagodzą problemy związane z czasem realizacji transakcji i kosztami przechowywania, takie jak wirtualny system plików dla Git opracowany przez firmę Microsoft do pracy z bardzo dużymi bazami kodu, który udostępnia wirtualny system plików, który pobiera pliki tylko do pamięci lokalnej jak są potrzebne.

Model pracy

Model rozproszony jest ogólnie lepiej dostosowany do dużych projektów z częściowo niezależnymi programistami, takimi jak projekt jądra Linux, ponieważ programiści mogą pracować niezależnie i zgłaszać swoje zmiany do scalenia (lub odrzucenia). Rozproszony model elastycznie umożliwia przyjmowanie niestandardowych przepływów pracy dotyczących wkładu kodu źródłowego. Integrator workflow jest najczęściej używany. W modelu scentralizowanym programiści muszą serializować swoją pracę, aby uniknąć problemów z różnymi wersjami.

Repozytoria centralne i oddziałowe

Każdy projekt ma centralne repozytorium, które jest uważane za oficjalne repozytorium, zarządzane przez opiekunów projektu. Deweloperzy klonują to repozytorium, aby utworzyć identyczne lokalne kopie bazy kodu. Zmiany kodu źródłowego w centralnym repozytorium są okresowo synchronizowane z lokalnym repozytorium.

Deweloper tworzy nową gałąź w swoim lokalnym repozytorium i modyfikuje kod źródłowy w tej gałęzi. Po zakończeniu rozwoju zmiana musi zostać zintegrowana z centralnym repozytorium.

Żądania ściągnięcia

Wkłady do repozytorium kodu źródłowego, które wykorzystuje rozproszony system kontroli wersji, są zwykle dokonywane za pomocą żądania ściągnięcia , znanego również jako żądanie scalania . Kontrybutor żąda, aby opiekun projektu ściągnął zmianę kodu źródłowego, stąd nazwa „żądanie ściągnięcia”. Opiekun musi scalić żądanie ściągnięcia, jeśli wkład powinien stać się częścią bazy źródłowej.

Deweloper tworzy żądanie ściągnięcia, aby powiadomić opiekunów o nowej zmianie; z każdym żądaniem ściągnięcia jest powiązany wątek komentarzy. Pozwala to na skoncentrowaną dyskusję na temat zmian w kodzie . Przesłane żądania ściągnięcia są widoczne dla każdego, kto ma dostęp do repozytorium. Prośba o ściągnięcie może zostać zaakceptowana lub odrzucona przez opiekunów.

Po przejrzeniu i zatwierdzeniu żądania ściągnięcia jest ono scalane z repozytorium. W zależności od ustalonego przepływu pracy, kod może wymagać przetestowania przed włączeniem go do oficjalnej wersji. Dlatego niektóre projekty zawierają specjalną gałąź do łączenia nieprzetestowanych pull requestów. Inne projekty uruchamiają zautomatyzowany zestaw testów przy każdym żądaniu ściągnięcia, używając narzędzia do ciągłej integracji , takiego jak Travis CI , a recenzent sprawdza, czy każdy nowy kod ma odpowiednie pokrycie testami.

Historia

Pierwsze systemy DVCS o otwartym kodzie źródłowym obejmowały Arch , Monotone i Darcs . Jednak DVCS o otwartym kodzie źródłowym nigdy nie były bardzo popularne, aż do wydania Git i Mercurial .

BitKeeper był używany w rozwoju jądra Linuksa w latach 2002-2005. Rozwój Gita , obecnie najpopularniejszego na świecie systemu kontroli wersji, został skłoniony do decyzji firmy, która zmusiła BitKeepera do cofnięcia darmowej licencji, którą Linus Torvalds i niektórzy inni programiści jądra Linuksa wcześniej wykorzystali.

Zobacz też

Bibliografia

Zewnętrzne linki