Dlaczego wszyscy korzystają z Git w sposób scentralizowany?

Użyłem Git w moich dwóch poprzednich firmach do kontroli wersji. Z tego, co słyszałem, wydaje się, że około 90% firm korzysta z Git w porównaniu z innymi systemami kontroli wersji.

Jedną z największych zalet Git jest to, że jest zdecentralizowany, tzn. Wszystkie repozytoria są równe; nie ma centralnego repozytorium / źródła prawdy. To była funkcja, którą Linus Torvalds zdobył.

Wygląda jednak na to, że każda firma korzystała z Git w sposób scentralizowany, podobnie jak w przypadku SVN lub CVS. Na serwerze zawsze znajduje się centralne repozytorium (zwykle na GitHub), z którego ludzie ściągają i pchają. Nigdy nie widziałem ani nie słyszałem (z mojego, co prawda, ograniczonego doświadczenia), osób korzystających z Git w naprawdę zdecentralizowany sposób, w jaki był zamierzony, tj. Pchania i przyciągania do repozytoriów innych kolegów według własnego uznania.

Moje pytania to:

1. Dlaczego ludzie nie używają rozproszonego przepływu pracy dla Git w praktyce?
2. Czy umiejętność pracy w sposób rozproszony jest nawet ważna dla nowoczesnej kontroli wersji, czy może to po prostu ładnie brzmi?

Edytować

Uświadomiłem sobie, że w moim pierwotnym pytaniu nie usłyszałem właściwego tonu. Brzmiało to tak, jakbym pytał, dlaczego ktokolwiek miałby działać w sposób scentralizowany, gdy system rozproszonej kontroli wersji (DVCS) był tak wyraźnie lepszy. W rzeczywistości chciałem powiedzieć, że nie widzę żadnych korzyści dla DVCS . Jednak często słyszę ludzi głoszących o swojej wyższości, podczas gdy świat rzeczywisty wydaje się zgadzać z moim poglądem.

Ahh, ale w rzeczywistości są przy użyciu git w sposób zdecentralizowany!

Porównajmy poprzednika gita w myślach, svn. Subversion miało tylko jedno „repo”, jedno źródło prawdy. Kiedy dokonałeś zatwierdzenia, dotyczyło to jednego centralnego repozytorium, do którego zobowiązał się również każdy inny programista.

Ten rodzaj zadziałał, ale doprowadził do wielu problemów, z których największym był przerażający konflikt scalania . Okazało się, że są one wszędzie od irytujących po koszmarne. I mając jedno źródło prawdy, mieli paskudny zwyczaj zatrzymywania pracy wszystkich, aż do ich rozwiązania. Konflikty scalania z pewnością istnieją z git, ale nie są to zdarzenia zatrzymujące pracę i są o wiele łatwiejsze i szybsze do rozwiązania; na ogół wpływają tylko na programistów zaangażowanych w konfliktowe zmiany, a nie na wszystkich.

Potem jest cały pojedynczy punkt awarii i związane z tym problemy. Jeśli centralne repozytorium svn jakoś umrze, wszyscy jesteście wkręceni, dopóki nie będzie można go przywrócić z kopii zapasowej, a jeśli nie będzie żadnych kopii zapasowych, wszyscy podwójnie to skręcicie. Ale jeśli umrze „centralne” repozytorium git, możesz je przywrócić z kopii zapasowej, a nawet z jednej z innych kopii repo, które znajdują się na serwerze CI, stacjach roboczych programistów itp. Możesz to zrobić właśnie dlatego, że są rozproszone, a każdy programista ma pierwszorzędną kopię repozytorium.

Z drugiej strony, ponieważ twoje repozytorium git jest samo w sobie repozytorium pierwszej klasy, kiedy je zatwierdzasz, twoje zobowiązania idą do lokalnego repo. Jeśli chcesz się nimi dzielić z innymi lub do centralnego źródła prawdy, musisz to zrobić wyraźnie, naciskając na pilota. Inni programiści mogą następnie usuwać te zmiany, gdy jest to dla nich wygodne, zamiast stale sprawdzać svn, aby sprawdzić, czy ktoś zrobił coś, co je zepsuło.

Fakt, że zamiast przesyłać bezpośrednio do innych programistów, przesyłasz zmiany do nich pośrednio za pośrednictwem innego zdalnego repo, nie ma większego znaczenia. Ważną częścią z naszej perspektywy jest to, że lokalna kopia repozytorium jest repozytorium samym w sobie. W svn centralne źródło prawdy jest wymuszone przez projekt systemu. W git system nie ma nawet tej koncepcji; jeśli istnieje źródło prawdy, decyzja jest podejmowana na zewnątrz.

Kiedy Twój serwer kompilacji ( używasz CI, prawda?) Tworzy kompilację, skąd się bierze ? Oczywiście, kompilacja integracji, którą można argumentować, nie wymaga „jednego prawdziwego repozytorium”, ale z pewnością kompilacja dystrybucji (tj. To, co dajesz klientowi), robi.

Innymi słowy: fragmentacja. Jeśli wyznaczysz jedno repozytorium jako „repozytorium” i wyznaczysz opiekunów, którzy weryfikują żądania ściągnięcia, masz łatwy sposób, aby spełnić prośbę „daj mi kompilację oprogramowania” lub „Jestem nowy w zespole, gdzie jest kod?”

Siłą DVCS jest nie tyle aspekt peer-to-peer, ale fakt, że jest on hierarchiczny . Zmieniam mój obszar roboczy, a następnie zatwierdzam do lokalnego. Po ukończeniu funkcji łączę swoje zobowiązania i wypycham je do pilota. Wtedy każdy może zobaczyć mój niepewny kod, przekazać opinie itp., Zanim utworzę żądanie ściągnięcia, a administrator projektu połączy go z repozytorium One True.

W tradycyjnym CVCS albo popełniasz, albo nie. To jest dobre w przypadku niektórych przepływów pracy (używam obu typów VCS do różnych projektów), ale pada płasko na twarz w przypadku projektu publicznego lub OSS. Kluczem jest to, że DVCS składa się z wielu etapów, które są bardziej pracochłonne, ale zapewniają lepszy sposób integracji kodu od nieznajomych poprzez wbudowany proces, który umożliwia lepszą widoczność tego, co jest rejestrowane. Korzystanie z niego w sposób scentralizowany oznacza, że ​​nadal możesz mają ten złoty standard obecnego stanu projektu, a jednocześnie zapewniają lepszy mechanizm udostępniania kodu.

Nie wiem, jak definiujesz „wszyscy”, ale mój zespół ma „centralne repozytorium na serwerze”, a także od czasu do czasu korzystamy z repozytoriów innych kolegów, nie przechodząc przez centralne repozytorium. Kiedy to robimy, nadal przechodzimy przez serwer, ponieważ nie wysyłamy łatek na temat tego miejsca, ale nie przez centralne repozytorium. Zwykle dzieje się tak, gdy grupa współpracuje nad konkretną funkcją i chce być na bieżąco, ale jak dotąd nie jest zainteresowana publikowaniem tej funkcji dla wszystkich. Oczywiście, ponieważ nie jesteśmy tajnymi pracownikami silosu, takie sytuacje nie trwają długo, ale DVCS zapewnia elastyczność w robieniu tego, co jest najwygodniejsze. Możemy opublikować gałąź funkcji lub nie według gustu.

Ale w ponad 90% przypadków przechodzimy przez centralne repozytorium. Kiedy nie dbam o żadną konkretną zmianę lub pracę konkretnego kolegi, jest to wygodniejsze i lepiej skaluje się, aby wyciągnąć „wszystkie zmiany moich kolegów, które zostały sprawdzone w centralnym repozytorium”, zamiast osobno wyciągać zmiany z każdego z N koledzy. DVCS nie stara się zapobiegać najczęstszemu przepływowi pracy „ściągnij z głównego repozytorium”, ale stara się, aby nie był to jedyny dostępny przepływ pracy.

„Rozproszony” oznacza, że ​​wszystkie repozytoria są technicznie równoważne, jeśli chodzi o gitoprogramowanie, ale nie oznacza to, że wszystkie mają jednakowe znaczenie, jeśli chodzi o programistów i nasze przepływy pracy. Kiedy udostępniamy klientom lub serwerom produkcyjnym, używane przez nas repozytorium ma inne znaczenie niż repo używane tylko przez jednego programistę na ich laptopie.

Jeśli „prawdziwie zdecentralizowana” oznacza „nie ma specjalnych repo”, a następnie nie sądzę, że to co Linus znaczy mistrz, biorąc pod uwagę, że w gruncie rzeczy on musi zachować specjalne repo, które są bardziej istotne w wielkim schemacie rzeczy, niż jest jakiś losowy klon Linuksa, który utworzyłem wczoraj i planuję użyć tylko do opracowania małej łatki, a następnie usunięcia jej po zaakceptowaniu łatki. gitnie uprzywilejowuje swojego repozytorium nad moim, ale Linus go uprzywilejowuje. Jego „to obecny stan Linuksa”, mój nie. Więc naturalnie zmiany mają tendencjęprzejść przez Linusa. Siła DVCS w stosunku do scentralizowanego VCS nie polega na tym, że nie może istnieć de facto centrum, chodzi o to, że zmiany nie muszą przechodzić przez żadne centrum, ponieważ (jeśli pozwalają na to konflikty) każdy może scalić wszystko.

Systemy DVCS są również zmuszane , ponieważ są zdecentralizowane, aby zapewnić pewne wygodne funkcje oparte na tym, że koniecznie musisz mieć pełną historię (tj. Repo) lokalnie, aby cokolwiek zrobić. Ale jeśli się nad tym zastanowić, nie ma fundamentalnego powodu, dla którego nie można skonfigurować scentralizowanego VCS z lokalną pamięcią podręczną, która przechowuje całą historię operacji tylko do odczytu, które mogą być nieaktualne (myślę, że Perforce ma opcję dla tego trybu, ale nigdy nie korzystałem z Perforce). Lub w zasadzie można skonfigurować za gitpomocą swojego.git/katalog w zdalnie zamontowanym systemie plików w celu emulacji „funkcji” SVN, która nie działa, gdy nie masz połączenia sieciowego. W efekcie DVCS zmusza hydraulikę do większej niezawodności niż jest to możliwe w scentralizowanym VCS. Jest to (bardzo pożądany) efekt uboczny i pomógł zmotywować projekt DVCS, ale ten podział odpowiedzialności na poziomie technicznym nie jest tym samym, co w pełni decentralizacja całej ludzkiej odpowiedzialności.

Interesującą rzeczą dotyczącą natury DVCS jest to, że jeśli inni ludzie używają jej w sposób rozproszony, prawdopodobnie nie będziesz o tym wiedział, chyba że będą oni bezpośrednio z tobą kontaktować. Jedyne, co możesz powiedzieć definitywnie, to to, że ty i twoi bezpośredni członkowie drużyny nie używacie git w ten sposób. Nie wymaga to polityki obejmującej całą firmę. Więc będę cię zapytać, dlaczego nie możesz użyć git w sposób zdecentralizowany?

Aby poradzić sobie z edycją, być może potrzebujesz doświadczenia w pracy z rzeczywistą scentralizowaną kontrolą wersji, aby docenić różnice, ponieważ chociaż mogą wydawać się subtelne, są wszechobecne. Oto wszystkie rzeczy, które mój zespół faktycznie wykonuje w pracy, których nie moglibyśmy zrobić, kiedy scentralizowaliśmy VCS:

• Mają bardzo małą listę głównych programistów z dostępem do repozytorium „centralnego” dla każdej mikrousługi. Wszyscy inni mogą ćwiczyć z widelcami i przesyłać żądania ściągania.
• Może popełniać znacznie częściej, zwykle kilka razy na godzinę w porównaniu do raz lub dwa razy dziennie.
• Może tworzyć oddziały z dowolnego powodu, aby tymczasowo koordynować je ze współpracownikami, i naciskać na niego i wyciągać z niego kilka razy dziennie, a następnie zgnieść go, gdy jest gotowy do udostępnienia większej grupie. Czy masz pojęcie, jak trudno jest uzyskać pozwolenie na utworzenie tymczasowej gałęzi dla czegoś takiego w tradycyjnym CVCS?

Ryzykując, że zabrzmią stare, naprawdę nie wiesz, jak łatwo to masz.

Myślę, że twoje pytanie pochodzi z (zrozumiałego), zawsze połączonego sposobu myślenia. tzn . centralny serwer „prawdy” ci jest zawsze (lub prawie zawsze) dostępny. Chociaż jest to prawdą w większości środowisk, pracowałem w co najmniej jednym, który był daleki od tego.

Projekt symulacji wojskowej, nad którym mój zespół pracował kilka lat temu. Cały kod (mówimy o bazie kodu> 1 mld USD) musiał (zgodnie z prawem / umową międzynarodową, mężczyźni w ciemnych garniturach przychodzą, jeśli nie), na komputerach fizycznie odizolowanych od jakiegokolwiek połączenia z Internetem . Oznaczało to, że zwykle każdy z nas miał 2 komputery, jeden do pisania / uruchamiania / testowania kodu, drugi do Google, sprawdzania poczty e-mail i tym podobnych. W zespole tych maszyn istniała sieć lokalna , oczywiście nie związana w żaden sposób z Internetem.

„Centralnym źródłem prawdy” była maszyna na bazie wojskowej, w podziemnym pokoju pozbawionym okien w całości z żużlu (wzmocniony budynek, yada-yada). Ta maszyna również nie miała połączenia z Internetem.

Od czasu do czasu czyimś zadaniem byłoby przetransportowanie (fizycznie) dysku z repozytorium git (zawierającego wszystkie nasze zmiany kodu) do bazy wojskowej - która była kilkaset kilometrów stąd, więc można to sobie wyobrazić.

Ponadto w bardzo dużych systemach, w których masz wiele zespołów. Zazwyczaj każdy z nich ma własne „centralne” repozytorium, które następnie powraca do rzeczywistego (centralnego poziomu) repozytorium centralnego. Znam co najmniej 1 innego wykonawcę, który wykonał ten sam dysk twardy git repo z użyciem swojego kodu.

Ponadto, jeśli weźmiesz pod uwagę coś w skali jądra Linux ... Programiści nie wysyłają tylko żądania ściągnięcia do samego Linusa. Zasadniczo jest to hierarchia repozytoriów - z których każda była / jest „centralna” dla kogoś / zespołu.

Odłączony charakter git oznacza, że ​​można go używać w środowiskach, w których nie można używać narzędzi do kontroli źródła podłączonego modelu ( np. SVN) lub nie można go używać tak łatwo.

Ostatecznie budujesz produkt. Ten produkt reprezentuje Twój kod w jednym momencie. Biorąc to pod uwagę, twój kod musi się gdzieś łączyć . Punkt naturalny to serwer ci lub serwer centralny, z którego zbudowany jest produkt, i ma sens, że ten punkt centralny jest repozytorium git.

Rozproszony aspekt DVCS cały czas pojawia się w rozwoju open source, w formie rozwidlenia. Na przykład niektóre projekty, do których się przyczyniłem, zostały porzucone przez pierwotnego autora i mają teraz kilka rozwidleń, w których opiekunowie czasami ściągają od siebie określone funkcje. Nawet ogólnie rzecz biorąc, projekty OSS pobierają wkład z zewnątrz poprzez żądanie ściągnięcia, a nie poprzez udzielanie losowym osobom dostępu do repozytorium naziemnego.

Nie jest to bardzo częsty przypadek użycia podczas budowania konkretnego produktu z konkretną oficjalną wersją, ale w świecie F / OSS jest to norma, a nie wyjątek.

Dlaczego wszyscy używają git w sposób scentralizowany?

Nigdy się nie poznaliśmy, dlaczego mówisz, że wszyscy? ;)

Po drugie, istnieje więcej innych funkcji, które można znaleźć w Git, ale nie w CVS lub SVN. Może po prostu zakładasz, że musi to być jedyna funkcja dla wszystkich .

Pewnie wiele osób może używać go scentralizowanego, takiego jak CVS lub SVN. Ale nie zapominaj o innej funkcji, która z natury wiąże się z przypisanym VCS: wszystkie kopie są mniej więcej „kompletne” (wszystkie gałęzie i pełna historia jest dostępna), a wszystkie gałęzie można sprawdzić bez połączenia z serwerem.

Moim zdaniem jest to kolejna cecha, o której nie należy zapominać.

Chociaż nie możesz tego zrobić po wyjęciu z pudełka CVS i SVN, Git może być używany scentralizowany jak poprzednie bez żadnych problemów.

Więc jestem w stanie zatwierdzić moje zmiany, być może zmiażdżyć wspólne prace w toku, a następnie pobrać i przesunąć moją pracę na główną gałąź programistyczną.

Inne funkcje, które wchodzą w skład Git:

• podpisuje kryptograficznie zatwierdzenia
• rebasing (zmiana kolejności i zatwierdzanie squasha; edycja zatwierdzeń, nie tylko wiadomość)
• zbieranie wiśni
• dzieląc historię
• lokalne oddziały i zmiany składowania (w Wikipedii zwane „półkami”)

Zobacz także te trzy tabele w Wikipedii - Porównanie oprogramowania do kontroli wersji :

• cechy

• Podstawowe polecenia

• Zaawansowane polecenia

Więc może zdecentralizowany sposób nie jest jedyną funkcją, która sprawia, że ​​ludzie go używają.

1. Dlaczego ludzie nie używają rozproszonego przepływu pracy dla Git w praktyce?

Każdy, kto wnosi wkład lub jest gospodarzem większego projektu na Bitbucked, GitHub itp., Dokładnie to zrobi. Opiekunowie przechowują „główne” repozytorium, klonujący, zatwierdza, a następnie wysyła żądanie ściągnięcia.

W firmach, nawet z małymi projektami lub zespołami, rozproszony przepływ pracy jest opcją, gdy albo zlecają na zewnątrz moduły i nie chcą, aby zewnętrzni modyfikowali świętą gałąź rozwoju bez uprzedniej weryfikacji ich zmian.

2. Czy umiejętność działa w sposób rozproszony, jest nawet ważna dla nowoczesnej kontroli wersji, ...

Jak zawsze: zależy to od wymagań.

Użyj zdecentralizowanego VCS, jeśli ma zastosowanie którykolwiek punkt:

• chcesz zatwierdzić historię lub nawigować w trybie offline (tzn. ukończyć submoduł w kabinie górskiej podczas wakacji)
• zapewniają centralne repozytoria, ale chcą zachować „prawdziwe” repozytorium oddzielnie w celu przeglądu zmian (np. dla dużych projektów lub rozproszonych zespołów)
• chcesz od czasu do czasu udostępnić (kopię) całej historii i gałęzi, jednocześnie uniemożliwiając bezpośredni dostęp do centralnego repozytorium (podobnego do drugiego)
• chcesz coś git init .zaktualizować bez konieczności przechowywania tego zdalnie lub konfigurowania dedykowanego repozytorium (zwłaszcza w Git wystarczy, aby być gotowym na coś zaktualizować)

Jest ich więcej, ale cztery powinny wystarczyć.

... czy to po prostu ładnie brzmi?

Oczywiście brzmi nieźle - dla początkujących.

Elastyczność jest zarówno przekleństwem, jak i błogosławieństwem. A ponieważ Git jest niezwykle elastyczny, prawie zawsze jest zbyt elastyczny dla typowej sytuacji. W szczególności większość projektów Git nie jest Linuksem.

W rezultacie mądrym wyborem jest usunięcie części teoretycznej elastyczności podczas wdrażania Git. Teoretycznie repozytoria mogą tworzyć dowolny wykres, w praktyce zwykle wybiera się drzewo. Widzimy wyraźne korzyści z teorii grafów: w drzewie repozytoriów dowolne dwa repozytoria mają dokładnie jednego przodka. Na losowym wykresie idea przodka nawet nie istnieje!

Jednak twój klient git prawie na pewno domyślnie korzysta z modelu „pojedynczego przodka”. A wykresy, w których węzły mają jednego przodka (z wyjątkiem węzła głównego), są dokładnie drzewami. Więc twój klient git domyślnie przyjmuje model drzewa, a zatem scentralizowane repozytoria.

Logika biznesowa nagradza scentralizowany serwer. W prawie wszystkich realistycznych scenariuszach biznesowych scentralizowany serwer jest podstawową funkcją przepływu pracy.

To, że masz zdolność wykonywania DVCS, nie oznacza, że ​​twoim podstawowym przepływem pracy musi być DVCS. Kiedy używam git w pracy, używamy go w sposób scentralizowany, z wyjątkiem tych dziwnych dziwnych przypadków, w których rozproszony bit był niezbędny do utrzymania ruchu.

Rozproszona strona rzeczy jest skomplikowana. Zazwyczaj chcesz zachować płynność i łatwość. Jednak używając git, masz pewność, że masz dostęp do strony rozproszonej, aby poradzić sobie z trudnymi sytuacjami, które mogą się pojawić na drodze.

Dla współpracownika, aby pobrać z repozytorium git na moim komputerze, muszę mieć demona git działającego na poziomie root jako zadanie w tle. Jestem bardzo ostrożny z demonami działającymi na własnym komputerze lub laptopie dostarczonym przez firmę. Najłatwiejszym rozwiązaniem jest „NIE”! Aby współpracownik mógł pobrać z repozytorium git na moim komputerze, oznacza to również, że mój adres internetowy musi zostać naprawiony. Podróżuję, pracuję w domu, a czasem pracuję w biurze.

Z drugiej strony połączenie VPN z witryną korporacyjną i przekazanie oddziału do centralnego repozytorium zajmuje mniej niż minutę. Nie potrzebuję nawet VPN, jeśli jestem w biurze. Moi współpracownicy mogą łatwo wyciągnąć z tej gałęzi.

Z drugiej strony moje lokalne repozytorium git to repozytorium z pełną funkcjonalnością. Mogę podjąć nową pracę, stworzyć nową gałąź do pracy eksperymentalnej i cofnąć pracę, gdy robię bałagan, nawet gdy pracuję w samolocie lecącym na wysokości 30 000 stóp nad szczerym polu. Spróbuj to zrobić za pomocą scentralizowanego systemu kontroli wersji.

Złożoność:

W przypadku centralnego repozytorium typowy przepływ pracy może być

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

Złożoność w odniesieniu do liczby programistów w O (1).

Jeśli zamiast tego każdy programista ma własną gałąź główną, staje się, dla programisty 0:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

Podejście peer-to-peer to O (N).

Konsystencja:

Teraz zastanów się, czy występuje konflikt scalania między główną gałęzią Alicji a główną gałęzią Boba. Każdy z N programistów mógł rozwiązać konflikt inaczej. Wynik: chaos. Istnieją sposoby osiągnięcia ostatecznej spójności, ale do tego czasu można zmarnować wszelkiego rodzaju czas programisty.

Prosty:

Firmy są scentralizowanymi organizacjami o scentralizowanym przepływie pracy.

Każdy programista ma szefa i ma swojego szefa itp., Aż do CTO. CTO jest ostatecznym źródłem prawdy technicznej. Bez względu na to, jakiego narzędzia używa firma, musi odzwierciedlać ten łańcuch dowodzenia. Kompania jest jak armia - nie możesz pozwolić, by szeregowcy przegłosowali generała.

GIT oferuje funkcje, które są użyteczne dla firm (np. Ściąganie próśb o sprawdzenie kodu) i które same w sobie powodują przejście na GIT. Część zdecentralizowana jest po prostu funkcją, której nie potrzebują - dlatego ją ignorują.

Aby odpowiedzieć na twoje pytanie: Część rozproszona jest rzeczywiście lepsza w środowisku rozproszonym, np. Open source. Wyniki różnią się w zależności od tego, kto mówi. Linus Torvalds nie jest dokładnie twoim szczurem w kabinie, dlatego inne cechy GIT są dla niego ważne niż dla twojej firmy zorientowanej na github.

Być może dzieje się tak dlatego, że przetwarzanie płac jest scentralizowane, więc jeśli chcemy otrzymywać wynagrodzenie, musimy zadowolić centralną osobę.

Może dlatego, że tworzymy jeden produkt, dlatego potrzebujemy głównej kopii oprogramowania dla klientów.

Może dlatego, że programiście dużo łatwiej jest udać się w jedno miejsce, aby uzyskać zmiany dla wszystkich, niż połączyć się z wieloma różnymi maszynami.

Może dlatego, że baza błędów jest scentralizowana i musi być zsynchronizowana z kodem .

Centralizacja jest świetna, dopóki nie pojawi się problem…

Git jako system rozproszony umożliwia tworzenie nowego centrum po niskich kosztach z dowolnego aktualnego repozytorium (wystarczy udostępnić repozytorium w sieci). Git umożliwia także aktualizację nieaktualnej kopii zapasowej z repozytoriów na komputerach programistów, co ułatwia odzyskanie centrum.

Możliwość łączenia itp. Na lokalnej kopii repozytorium, gdy sieć jest wyłączona, jest świetna, ale nie wymaga systemu rozproszonego; potrzebuje tylko systemu, który przechowuje lokalną kopię wszystkich danych. Podobnie jest z odprawieniem kodu podczas lotu itp.

Na koniec dnia dystrybucja jest niewielka, a niektóre korzyści. Większość kosztów dystrybucji jest w obszarze, który jest potrzebny, jeśli chcesz doskonale śledzić oddziały itp. Jeśli miałbyś zaprojektować system do użytku w większości firm, nie zaprojektowałbyś go do dystrybucji, jako scentralizowana kontrola kodu źródłowego jest oczywiście podstawowym „przypadkiem użycia”.