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

289

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.

ogrodnik
źródło
31
Czuję dokładnie to samo i nie rozumiem tego.
Snoop,
57
Osobiście po prostu nie znam przypadków użycia wielu pilotów, innych niż widelce do tworzenia PR na głównym pilocie. Rozproszona rzecz jest nadal przydatna, ponieważ oznacza, że ​​mam pełną historię na moim komputerze bez konieczności rozmowy z siecią, i mogę trochę pracować offline, jeśli naprawdę chcę, i znacznie łatwiej jest migrować z jednego hosta repo online do inne. Co dokładnie masz na myśli, mówiąc o „rozproszonym przepływie pracy”?
Ixrec
43
Jestem całkiem pewien, że Torvalds od początku zamierzał mieć jedno „źródło prawdy” repozytorium jądra Linux.
Steven Burnap,
67
Ostatecznie samo oprogramowanie jest scentralizowane. Klienci nie kupują oddziałów ani pilotów, kupują gotowy, złożony produkt. Zawsze musi być jakaś centralna ścieżka naprzód.
Brandon,
37
Dla mnie „zdecentralizowana” git jest jedną z najmniej ważnych funkcji, które ją polecają. Możliwość częstego zatwierdzania i cofania zmian lokalnie, bez wpływu na innych, lub potężne techniki, takie jak zmiana bazy danych, gdzie git naprawdę błyszczy w moim przepływie pracy. Możliwe (nawet prawdopodobne), że wszystkie te są możliwe dzięki zdecentralizowaniu, ale „D” w DVCS nie jest dla mnie tak ważne.
Jay

Odpowiedzi:

257

Ahh, ale w rzeczywistości 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.

Michael Hampton
źródło
15
Scalanie SVN wpływa również tylko na programistów zaangażowanych w konfliktowe zmiany. Jedno zatwierdzenie przechodzi do repozytorium, żadne konfliktowe scalenie nie może przejść do repo, dopóki konflikty nie zostaną rozwiązane (możesz również zatwierdzić równolegle do osobnej gałęzi / ścieżki, ale to tak naprawdę nie powoduje konfliktu, prawda?)
Ben Voigt
30
Uważam, że główną różnicą, gdy istnieje serwer centralny, jest to, że GIT zezwala na bieżącą lokalną wersję, gdy sieć jest wyłączona, a SVN nie (niektóre inne systemy kontroli wersji są jeszcze gorsze i przestają działać, gdy sieć jest nieosiągalna , ponieważ nie pozwalają zmienić pliku, dopóki go nie wypiszesz).
Ben Voigt,
17
@BenVoigt Och, praca się kończy. Pamiętaj, że musisz svn upbyć na bieżąco z repozytorium, zanim będziesz mógł się meldować. Gdy inni kontynuują meldowanie się, gdy próbujesz rozwiązać konflikty scalania, i dają ci inny zestaw konfliktów scalania ... albo przestajesz to robić lub stracisz to, co zostało z twojego zdrowia psychicznego.
Michael Hampton
21
Nie, ludzie z pewnością mogą nadal angażować się w gałąź, z której scalasz zmiany, bez zakłócania przepływu pracy.
Ben Voigt,
29
Ben ma rację. Repozytorium SVN właściwie zarządzane i używane przez zespół, który został odpowiednio przeszkolony w zakresie tworzenia oprogramowania, nigdy nie powinno skutecznie łączyć konfliktów na linii głównej. Dostaniesz je tylko wtedy, gdy ktoś zrobi coś złego i trzeba go zwolnić (: P). inb4 jest łatwiej, gdy nie musisz edukować ludzi, jak korzystać z ich narzędzi. Tak, cóż, o Git jest dużo więcej do nauczenia niż o SVN!
Wyścigi lekkości na orbicie
118

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.


źródło
2
Ogólnie dobra odpowiedź, ale jestem prawie pewien, że Git był w powszechnym użyciu przed ciągłą integracją; Nawiasem mówiąc, nasz zespół używa CI, dziękuję za sprawdzenie: D.
ogrodnik
5
@gardenhead: nie trafiłeś w sedno: ten sam argument obowiązuje, jeśli integracja jest wykonywana ręcznie. „CI” to po prostu automatyzacja procesu znacznie starszego niż Git.
Doc Brown,
25
„każdy może zobaczyć mój wstępny kod” - a także może pobrać Twój wstępny kod, scalić go ze swoim wstępnym kodem i uruchomić testy. Jest to uciążliwe dla scentralizowanych VCS, ponieważ wymaga rozgałęzień i zmian w One True Copy. Rozproszone, po prostu konfigurujesz dodatkowe piloty, a następnie zaczynasz scalać, łatać i wybierać. Śledzisz to, co zrobiłeś, ale nikt nigdy nie musi zobaczyć, jakie masz zamiary, chyba że zdecydujesz się je opublikować. Ogólnie rzecz biorąc, zalecam, aby nikt nie oświadczył, że DVCS jest bezcelowy, dopóki nie użyje SVN do dużego projektu ...
Steve Jessop
9
Ponieważ nie ma „jednej prawdziwej wersji” jądra Linux. Ponieważ wszyscy budują je sami, repozytorium Linusa nie jest bardziej kanoniczne niż repozytorium kogokolwiek innego. Jeśli sprzedajesz produkt, który nie działa tak dobrze.
Miles Budnek,
2
@ Superbest: duża część (jeśli nie wszystkie) projektu git była oparta na Bitkeeper. Git powstał po implodacji kontrowersji dotyczącej Linuksa.
whatsisname
40

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 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.

Steve Jessop
źródło
7
technicznie równoważne, a nie społecznie równoważne.
curiousdannii
3
Poprawki wysyłane pocztą elektroniczną są dość bezbolesne, na wypadek, gdyby ktoś to rozważał, wystarczy użyć git format-patch, a następnie git send-email . Zrobiłem to, gdy nie chciałem manipulować kontrolą dostępu Github i było to bardzo proste, w końcu wszyscy mają e-maile.
Rudolf Olah
1
„koniecznie musi mieć pełną historię [...] lokalnie, aby cokolwiek zrobić” - nieprawda; nowoczesne DSCM obsługują częściowe repo („płytkie kasy” w kategoriach bzr, „płytkie klony” w kategoriach git).
Charles Duffy,
27

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.

Karl Bielefeldt
źródło
1
Pytanie, jak trudno jest utworzyć gałąź w tradycyjnym CVCS, zależy wyłącznie od polityki: akurat pracuję z repozytorium SVN w górę (naturalnie poprzez klon git-svn!) I mam pełne prawo do tworzenia dowolnych gałęzi I chcę, mimo że jest to dość duży projekt. Po prostu nie wolno mi dotykać szeregu wyznaczonych gałęzi integracji, nie mówiąc już o pniu, bez uprzedniej rozmowy z przełożonymi. Inne firmy mogą mieć inne zasady, które mogą być bardziej restrykcyjne, ale na pewno nie muszą.
cmaster 10.04.16
7
Masz rację, nie wiem jak łatwo to mam. Chciałbym być w czasach dominacji SVN, aby docenić, jak daleko zaszliśmy. Jako bardzo młody programista często powtarzam ten sam schemat: bardziej doświadczeni deweloperzy mówią mi, że stary sposób robienia czegoś był zły, a ten nowy sposób / technologia jest znacznie łatwiejsza. Ale muszę po prostu uwierzyć im na słowo; Nigdy nie mogę naprawdę docenić zalet. Zawsze uważałem ten dysonans za trudny do pokonania.
ogrodnik
1
@gardenhead zawsze możesz stworzyć własne repozytorium SVN i spróbować je złamać;) (i zwróć uwagę, o ile trudniejsze niż tworzenie repozytorium git i klonowanie go ...) - Inną ważną cechę, którą zauważyłem (przynajmniej w szczególnie w środowiskach korporacyjnych) jest to, że udostępnianie plików jest albo trochę niewygodne, albo odbywa się w taki sposób, że przerabia repozytoria (ponieważ na przykład skaner antywirusowy blokuje się na dysku sieciowym).
Wayne Werner,
4
@gardenhead: cóż, uważaj się za szczęściarza, że ​​nie utknąłeś w starym projekcie, ze starymi programistami, którzy mówią ci, że stary sposób robienia rzeczy jest w porządku ... czasami nie możesz nie myśleć, że są po prostu cieszę się, że nie muszą uczyć się nowych technologii!
lewo wokół około
1
@gardenhead najwyraźniej projekty są wydawane w dość szalonym tempie. Zdolność do kontynuowania nauki jest konieczna, jeśli chcesz znaleźć świetną pracę.
Wayne Werner
19

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.

Tersozaury
źródło
3
Należę do klubu Mile High (oprogramowanie) - kod został przyznany na 35 000 stóp. Oczywiście samoloty mają teraz Wi-Fi , ale nie zawsze tak było. Miło jest wiedzieć, że przynajmniej w razie awarii istnieje możliwość, że mój zespół nie zmieni kodu.
Wayne Werner,
@WayneWerner to prawda. Myślałem o zapewnieniu bardziej ogólnych sytuacji, w których nie byłoby możliwe (prawie) zawsze połączenie. Np. Samolotem, łodzią na morzu, stacją kosmiczną, odległymi miejscami w Afryce itp.
Tersosauros 11.04.16
18

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.

Bryan Oakley
źródło
14

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.

puszysty
źródło
4
To właściwa odpowiedź, także z historycznego punktu widzenia. Jądro Linux ma od dawna wiele repozytoriów źródłowych (zwanych przez programistów „drzewami”, takimi jak „drzewo Linusa” lub „drzewo Andrew”). Linux chciał czegoś, co wesprze ten rodzaj rozproszonego rozwoju, kiedy opracował git.
śleske,
@Luaan Po dłuższym zastanowieniu zdałem sobie sprawę, że masz rację. Trochę zmieniłem sformułowanie - czy to lepiej oddaje to rozróżnienie?
puszysty
@fluffy Brzmi dobrze dla mnie;)
Luaan,
9

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 :

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.

  1. 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.

spróbuj złapać w końcu
źródło
Czy SVN nie zyskał svn initw pewnym momencie?
immibis
5

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.

MSalters
źródło
1
Zgadzam się, że elastyczność Git musi być stonowana w większości przypadków użycia. W mojej ostatniej pracy nie mieliśmy wskazówek, jak korzystać z git, i były z tego powodu ciągłe konflikty i uszkodzenia. W mojej nowej firmie korzystamy z modelu Git Flow, który sprawia, że ​​rozwój jest znacznie usprawniony i bezstresowy.
ogrodnik
1
To nie jest „teoretyczna elastyczność”, aby pozwolić innym niż drzewa. Ogranicz się do „tylko drzew”, a nigdy nie będziesz w stanie scalić swoich zmian, przez co cały twój VCS będzie trochę bezcelowy.
Wildcard
2
@Wildcard: Scalanie nie stanowi żadnego problemu z drzewami, dlaczego tak się dzieje? Oczywiście nie można łączyć między losowymi węzłami, tylko między rodzicem / dzieckiem.
MSalters
1
Najwyraźniej nie byłem wystarczająco jasny. Miałem na myśli drzewo zatwierdzeń, a nie drzewo systemu plików. Z definicji zatwierdzenie scalania ma więcej niż jednego rodzica, dlatego wykres historii nie jest już drzewem, lecz DAG.
Wildcard
2
@Wildcard: MSalters powiedział, że repozytoria są zwykle połączone jako drzewa, a nie że zatwierdzenia. Mówi, że repo zwykle mają tylko jednego pilota „upstream”, do którego wypychają (lub wysyłają żądania ściągania). Nie mam żadnych statystyk, czy to prawda, czy nie, ale jest to całkowicie odrębne roszczenie od wszystkiego, co ma związek z tym, ilu rodziców ma zamiar scalenia.
Steve Jessop
4

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.

Cort Ammon
źródło
3

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.

David Hammen
źródło
„Jestem bardzo ostrożny z demonami działającymi na własnym komputerze lub laptopie dostarczonym przez firmę”. - ponieważ oprócz czegokolwiek innego, uruchomienie usługi na moim laptopie oznacza, że ​​usługa jest niedostępna po zamknięciu pokrywy! DynDNS może pomóc w wielu lokalizacjach (do pewnego stopnia nadal możesz być uwięziony za NAT), ale nie pomaga w wyłączeniu karty sieciowej ...
Steve Jessop
Istnieje wiele sposobów na pokazanie repozytorium git bez uruchamiania specjalnego demona; można uzyskać do niego dostęp za pośrednictwem praktycznie dowolnego udziału plików (smb, sshfs itp.), a nawet można go udostępnić jako zwykły magazyn HTTP.
puszysty
2

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.

Theodore Norvell
źródło
Jeśli zamierzasz głosować w dół, czy możesz skomentować dlaczego?
Theodore Norvell,
Nie to, że mam coś przeciwko głosom negatywnym. Chcę tylko wiedzieć, czy odpowiedź jest w jakiś sposób błędna.
Theodore Norvell,
1

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.

Agent_L
źródło
-2

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”.

Ian
źródło