Jak zaprojektowano Git?

Moje miejsce pracy niedawno przeszło na Git i uwielbiam je (i nienawidzę!). Naprawdę to uwielbiam i jest niezwykle potężny. Jedyne, czego nienawidzę, to to, że czasami jest zbyt potężny (i może trochę zwięzły / mylący).

Moje pytanie brzmi ... Jak zaprojektowano Git? Używając go przez krótki czas, masz wrażenie, że może on obsługiwać wiele niejasnych przepływów pracy, których inne systemy kontroli wersji nie mogłyby. Ale pod spodem jest też elegancko. I szybko!

Nie ulega wątpliwości po części talent Linusa. Ale zastanawiam się, czy ogólny projekt git był oparty na czymś? Czytałem o BitKeeperze, ale na kontach brakuje szczegółów technicznych. Kompresja, wykresy, pozbycie się numerów wersji, podkreślanie rozgałęzień, ukrywanie, piloty ... Skąd to wszystko?

Linus naprawdę wyrzucił ten z parku i prawie za pierwszym razem! Jest całkiem dobry w użyciu po przekroczeniu krzywej uczenia się.

Git nie został zaprojektowany tak bardzo, jak ewoluował .

Spójrz sam. Sklonuj oficjalne repozytorium git , otwórz je gitk(lub swoją ulubioną graficzną przeglądarkę logów git) i spójrz na jego najwcześniejsze wersje.

Zobaczysz, że pierwotnie miał tylko bardzo podstawową funkcjonalność (bazę danych obiektów i indeks). Cała reszta została wykonana ręcznie . Jednak ten mały rdzeń został zaprojektowany w taki sposób, aby można go było łatwo zautomatyzować za pomocą skryptów powłoki. Pierwsi użytkownicy git napisali własne skrypty powłoki, aby zautomatyzować typowe zadania; krok po kroku te skrypty włączano do dystrybucji git (patrz wczesny przykład 839a7a0 ). Za każdym razem, gdy pojawiła się nowa potrzeba, skrypty były dostosowywane, aby na to pozwolić. Znacznie później kilka z tych skryptów zostanie przepisanych w C.

Ta kombinacja czystego, ortogonalnego rdzenia (z którego możesz nadal korzystać bezpośrednio, jeśli potrzebujesz) z górną warstwą, która wyrosła nad nim organicznie, jest tym, co daje mu siłę. Oczywiście to właśnie daje mu dużą liczbę dziwnie nazwanych poleceń i opcji.

Kompresja, wykresy, pozbycie się numerów wersji, podkreślanie rozgałęzień, ukrywanie, piloty ... Skąd to wszystko?

Na początku dużo tego nie było.

Chociaż każdy obiekt był indywidualnie kompresowany, a jego nazwy unikały duplikatów, pliki „pack”, które odpowiadają za wysoką kompresję, do której jesteśmy przyzwyczajeni w git, nie istniały. Na początku filozofia brzmiała: „miejsce na dysku jest tanie”.

Jeśli przez „wykresy” masz na myśli przeglądarkę graficzną gitk, to pojawili się później (AFAIK, pierwsza była gitk). AFAIK, BitKeeper miał również graficzną przeglądarkę historii.

Pozbycie się numerów wersji, tak naprawdę podstawowa koncepcja gita polegająca na wykorzystaniu systemu plików adresowanego do przechowywania obiektów, przeważnie pochodzi z monotonu . W tym czasie monotonia była powolna; gdyby tak nie było, możliwe, że Linus użyłby go zamiast tworzyć git.

Podkreślanie rozgałęzień jest nieco nieuniknione w rozproszonym systemie kontroli wersji, ponieważ każdy klon działa jako osobna gałąź.

Stashing ( git stash) jest, IIRC, całkiem nowy . Rejestrów, których używa, nie było na początku.

Początkowo nie było tam nawet pilotów. Początkowo obiekty zostały skopiowane ręcznie przy użyciu rsync.

Jedna po drugiej, każda z tych funkcji została dodana przez kogoś. Nie wszystkie z nich - być może nawet większość - zostały napisane przez Linusa. Za każdym razem, gdy ktoś odczuwa potrzebę, której git nie spełnia, można utworzyć nową funkcję nad podstawową warstwą „hydrauliczną” gita i zaproponować jej włączenie. Jeśli jest dobry, prawdopodobnie zostanie zaakceptowany, co jeszcze bardziej zwiększy użyteczność gita (i jego złożoność wiersza poleceń).

Myślę, że główną kwestią jest po prostu to, że git został zaprojektowany przez najbardziej wykwalifikowaną osobę na świecie, aby to zrobić. I nie mówię o talencie, mówię o doświadczeniu: wątpię, czy ktoś jeszcze zarządzał bazą kodu o porównywalnej kombinacji wielkości i liczby współpracowników jak jądro Linuksa i nadal zajmuje się większością integracji pracować samemu.

Linus znał więc wymagania i przypadki użycia rozproszonego systemu kontroli wersji lepiej niż ktokolwiek inny. I oczywiście pomogło to, że większość tego kodowania, które miał do czynienia, była w C, a znaczna część miała krytyczne znaczenie dla wydajności.

Zasadniczo jest to najlepszy przykład drapania własnego swędzenia.

Został zaprojektowany prawie dokładnie tak, jak opisano w The Git Parable .

Wyobraź sobie, że masz komputer, na którym nie ma nic oprócz edytora tekstu i kilku poleceń systemu plików. Teraz wyobraź sobie, że zdecydowałeś się napisać duży program na tym systemie. Ponieważ jesteś odpowiedzialnym programistą, zdecydujesz, że musisz wymyślić jakąś metodę śledzenia wersji oprogramowania, aby móc odzyskać kod, który wcześniej zmieniłeś lub usunąłeś. Poniżej znajduje się historia o tym, jak zaprojektować jeden taki system kontroli wersji (VCS) oraz uzasadnienie tych wyborów projektowych.