Dlaczego git używa skrótów zamiast numerów wersji?

Zawsze zastanawiałem się, dlaczego git woli skróty niż numery wersji. Numery wersji są znacznie wyraźniejsze i łatwiejsze do odniesienia (moim zdaniem): Istnieje różnica między poleceniem komuś spojrzenia na wersję 1200 lub zatwierdzeniem 92ba93e! (Podam tylko jeden przykład).

Czy jest więc jakiś powód tego projektu?

Pojedynczy, monotonicznie rosnący numer wersji ma sens tylko w przypadku scentralizowanego systemu kontroli wersji, w którym wszystkie wersje trafiają do jednego miejsca, które może śledzić i przypisywać numery. Po wejściu do świata DVCS, w którym istnieje wiele kopii repozytorium, a zmiany są pobierane i przekazywane do nich w dowolnych przepływach pracy, koncepcja po prostu nie ma zastosowania. (Na przykład, nie ma jednego miejsca do przypisania numerów wersji - jeśli rozwidlę twoje repozytorium, a rok później zdecydujesz się wycofać moje zmiany, w jaki sposób system może zapewnić, że nasze numery wersji nie powodują konfliktu?)

Potrzebujesz skrótów w systemie rozproszonym. Powiedzmy, że ty i kolega pracujecie nad tym samym repozytorium i oboje dokonacie zmiany lokalnie, a następnie wprowadzicie ją. Kto może być numerem wersji 1200, a kto numerem wersji 1201, skoro żadna ze stron nie ma o sobie wiedzy? Jedynym realistycznym rozwiązaniem technicznym jest utworzenie skrótu zmian za pomocą znanej metody i połączenie na tej podstawie różnych elementów.

Co ciekawe, HG obsługuje numery wersji, ale są one jawnie dostępne tylko lokalnie - twoje repozytorium ma jeden zestaw, repo twojego współpracownika będzie miało inny zestaw w zależności od tego, w jaki sposób pchały i wyciągały. Sprawia to, że korzystanie z wiersza poleceń jest nieco bardziej przyjazne niż Git.

Integralność danych.

Z szacunkiem nie zgadzam się z obecnymi odpowiedziami. Skróty nie są konieczne dla DVCS, patrz sposób bazarowy . Możesz zrobić to samo z dowolnym innym globalnie unikalnym identyfikatorem. Skróty są miarą gwarantującą integralność danych: reprezentują zestawienie informacji zawartych w obiekcie (zatwierdzenie, drzewa, ...), do których odwołuje się skrót. Zmiana zawartości bez zmiany skrótu (tj. Atak przedobrazowy lub atak kolizyjny ) uważa się za trudny, choć nie niemożliwy. (Jeśli naprawdę się tym interesujesz, spójrz na artykuł Marca Stevensa z 2011 roku ).

Odwołanie się do obiektów przez ich skrót SHA pozwala więc sprawdzić, czy zawartość została zmieniona. A ponieważ są (prawie) gwarantowane, że są unikalne, mogą być również używane jako identyfikatory wersji - tak wygodnie.

Więcej informacji znajduje się w rozdziale 9 książki Git.

Słowami laika:

• Hashe mają być niemal uniwersalnie wyjątkowe. NIE jest to gwarantowane, ale jest bardzo mało prawdopodobne, aby te same SHA były generowane dla różnych treści. W praktyce dla danego projektu można go traktować jako wyjątkowy.
• W przypadku numerów wersji należy użyć przestrzeni nazw, aby odnieść się konkretnie do wersji 1200.
• Git może działać zarówno rozproszone, jak i scentralizowane. Jak więc uzyskać poprawne i niepowtarzalne numery wersji?
• Również użycie numerów wersji stworzyłoby fałszywe przekonanie, że nowsze wersje powinny mieć wyższe liczby, a to nie byłoby prawdą z powodu rozgałęzienia, scalenia, zmiany bazy itp.
• Zawsze masz opcję dodawania tagów do zatwierdzeń.

W kategoriach matematycznych:

• W przypadku monotonicznie rosnących numerów wersji wymagane byłoby całkowite zamówienie w stosunku do zatwierdzeń Gita.
• Zatwierdzenia Gita tworzą ukierunkowany, acykliczny wykres (DAG), który można zamówić tylko częściowo / topologicznie .

Hash nie jest unikalnym rozwiązaniem dla rozproszonego VCS. Ale w przypadku systemu rozproszonego można rejestrować tylko częściowe uporządkowanie zdarzeń. (W przypadku VCS zdarzenie może być zatwierdzeniem.) Dlatego utrzymanie monotonicznie rosnącego numeru wersji jest niemożliwe. Zwykle przyjmujemy coś w rodzaju zegara wektorowego (lub znacznika czasu wektorowego), aby zarejestrować taką częściowo uporządkowaną relację. To jest rozwiązanie stosowane w Bazaar .

Ale dlaczego Git nie używa zegara wektorowego, ale hash? Myślę, że główną przyczyną jest wybranie . Kiedy wykonujemy cherry-pick w repozytorium, częściowe porządkowanie zatwierdzeń się zmienia. Zegary wektorowe niektórych zatwierdzeń muszą zostać ponownie przypisane, aby reprezentowały nowe częściowe uporządkowanie. Jednak takie przeniesienie w systemie rozproszonym spowodowałoby niespójne zegary wektorowe. To jest prawdziwy problem, z którym radzą sobie skróty.