Jak i / lub dlaczego scalanie w Git jest lepsze niż w SVN?

Twierdzenie, dlaczego scalanie jest lepsze w DVCS niż w Subversion, opierało się w dużej mierze na tym, jak rozgałęzianie i scalanie działało w Subversion jakiś czas temu. Subversion przed 1.5.0 nie przechowuje żadnych informacji o tym, kiedy gałęzie zostały scalone, więc gdy chcesz scalić, musisz określić zakres wersji, które mają zostać scalone.

Więc dlaczego Subversion Scala ssać ?

Zastanów się nad tym przykładem:

      1   2   4     6     8
trunk o-->o-->o---->o---->o
       \
        \   3     5     7
b1       +->o---->o---->o

Kiedy chcemy połączyć b1 zmienia się w trunk, gdy stajemy na folderze, który ma sprawdzony trunk, wydajemy następującą komendę:

svn merge -r 2:7 {link to branch b1}

... który spróbuje scalić zmiany z b1 do lokalnego katalogu roboczego. A następnie zatwierdzasz zmiany po rozwiązaniu wszelkich konfliktów i przetestowaniu wyniku. Po zatwierdzeniu drzewo rewizji wyglądałoby tak:

      1   2   4     6     8   9
trunk o-->o-->o---->o---->o-->o      "the merge commit is at r9"
       \
        \   3     5     7
b1       +->o---->o---->o

Jednak ten sposób określania zakresów wersji szybko wymyka się spod kontroli, gdy drzewo wersji rośnie jako subversion nie miał żadnych metadanych na temat tego, kiedy i jakie poprawki zostały połączone razem. Zastanów się nad tym, co dzieje się później:

           12        14
trunk  …-->o-------->o
                                     "Okay, so when did we merge last time?"
              13        15
b1     …----->o-------->o

Jest to w dużej mierze problem związany z projektem repozytorium, który ma Subversion, aby utworzyć gałąź, musisz utworzyć nowy wirtualny katalog w repozytorium, który będzie zawierał kopię trunka, ale nie przechowuje żadnych informacji o tym, kiedy i do czego rzeczy zostały ponownie scalone. To prowadzi czasami do nieprzyjemnych konfliktów scalania. Co było nawet co gorsza, Subversion używa domyślnie scalania dwukierunkowego, które ma pewne ograniczenia w automatycznym scalaniu, gdy dwie odgałęzienia nie są porównywane ze wspólnym przodkiem.

Aby złagodzić tę Subversion przechowuje teraz metadane dla gałęzi i scalania. To rozwiąże wszystkie problemy, prawda?

W scentralizowanym systemie, takim jak subversion, wirtualne katalogi są do bani. Dlaczego? Ponieważ każdy ma dostęp do widoku nawet te śmieciowe. Rozgałęzianie jest dobre, jeśli chcesz eksperymentować , ale nie chcesz widzieć eksperymentów everyones i ich ciotek . To poważny szum poznawczy. Im więcej gałęzi dodasz, tym więcej gówna zobaczysz.

Im więcej publicznych gałęzi masz w repozytorium, tym trudniej będzie śledzić wszystkie różne gałęzie. Więc pytanie będzie brzmiało, czy gałąź jest nadal w rozwoju lub czy jest naprawdę martwy, co jest trudne powiedzieć w dowolnym scentralizowanym systemie kontroli wersji.

Przez większość czasu, z tego co widziałem, organizacja domyślnie używa jednego dużego oddziału. A szkoda, bo to z kolei będzie trudne do śledzenia wersji testowych i wydawniczych, a co innego dobrego wynika z rozgałęzień.

Więc dlaczego DVC, takie jak Git, Mercurial i Bazaar, są lepsze niż Subversion w rozgałęzianiu i scalaniu?

Jest bardzo prosty powód, dla którego: rozgałęzianie jest koncepcja pierwszej klasy . Nie ma żadnych wirtualnych katalogów, a gałęzie są twardymi obiektami w DVC, które muszą być takie, aby działać po prostu z synchronizacją repozytoriów (np. push i pull).

Pierwszą rzeczą, którą robisz podczas pracy z DVCS, jest klonowanie repozytoriów (Gita clone, hg ' s clone i bzr branch). Klonowanie jest koncepcyjnie tym samym co tworzenie gałęzi w wersji Kontrola. Niektórzy nazywają to rozwidleniem lub rozgałęzieniem (chociaż to ostatnie często jest również używane w odniesieniu do współpołożonych gałęzi), ale jest to po prostu to samo. Każdy użytkownik prowadzi własne repozytorium, co oznacza, że masz dla każdego użytkownika rozgałęzienie.

Struktura wersji jest nie drzewem , ale raczej wykresem . A dokładniej skierowany Graf acykliczny (dag, co oznacza Graf, który nie ma żadnych cykli). Naprawdę. nie trzeba rozwodzić się nad specyfiką DAG innej niż każdy commit ma jedną lub więcej referencji nadrzędnych (na których podstawie powstał commit). Tak więc poniższe wykresy pokażą strzałki między wersjami w odwrotnej kolejności z tego powodu.

         a…   b…   c…
origin   o<---o<---o
                   ^master
         |
         | clone
         v

         a…   b…   c…
alice    o<---o<---o
                   ^master
                   ^origin/master

To, co dzieje się podczas klonu, to to, że każda zmiana jest kopiowana do Alice dokładnie tak, jak były one (co jest potwierdzone przez jednoznacznie identyfikowalne hash-id) i oznaczają, gdzie znajdują się gałęzie pochodzenia.

         a…   b…   c…
origin   o<---o<---o
                   ^ master

              "what'll happen after a push?"


         a…   b…   c…   d…   e…
alice    o<---o<---o<---o<---o
                             ^master
                   ^origin/master

Rozwiązanie jest dość proste, jedyne co repozytorium origin musi zrobić, to przyjąć wszystkie nowe wersje i przenieść gałąź do najnowszej wersji (którą git nazywa "fast-forward"): {]}

         a…   b…   c…   d…   e…
origin   o<---o<---o<---o<---o
                             ^ master

         a…   b…   c…   d…   e…
alice    o<---o<---o<---o<---o
                             ^master
                             ^origin/master

Przypadek użycia, który zilustrowałem powyżej, nie musi nawet łączyć niczego. Tak więc problem naprawdę nie dotyczy algorytmów scalania, ponieważ algorytm scalania trójstronnego jest prawie taki sam między wszystkimi systemami kontroli wersji. problem dotyczy bardziej struktury niż czegokolwiek .

Więc może pokażesz mi przykład, który ma prawdziwe połączenie?

Wprawdzie powyższy przykład jest bardzo prostym przypadkiem użycia, więc zróbmy o wiele bardziej Pokręcony, choć bardziej powszechny. Pamiętaj, że origin zaczęło się od trzech zmian? Cóż, facet, który to zrobił, nazwijmy go Bobem, pracował sam i zrobił commit na swoim repozytorium:]}

         a…   b…   c…   f…
bob      o<---o<---o<---o
                        ^ master
                   ^ origin/master

                   "can Bob push his changes?" 

         a…   b…   c…   d…   e…
origin   o<---o<---o<---o<---o
                             ^ master

Teraz Bob nie może przesyłać swoich zmian bezpośrednio do repozytorium origin. Jak system wykrywa to jest przez sprawdzenie, czy zmiany Boba bezpośrednio schodzi z origin ' s, co w tym przypadku nie. każda próba wciśnięcia spowoduje, że system powie coś podobnego do "Uh... Obawiam się, że nie mogę ci na to pozwolić. Bob ."

Więc Bob musi wciągnąć, a następnie połączyć zmiany (z Gitem pull; lub hg pull oraz merge; lub bzr merge). Jest to proces dwuetapowy. Najpierw Bob musi pobrać nowe wersje, które skopiują je tak, jak są z repozytorium origin. Teraz widzimy, że wykres jest rozbieżny:

                        v master
         a…   b…   c…   f…
bob      o<---o<---o<---o
                   ^
                   |    d…   e…
                   +----o<---o
                             ^ origin/master

         a…   b…   c…   d…   e…
origin   o<---o<---o<---o<---o
                             ^ master

Drugim krokiem procesu pull jest połączenie rozbieżnych końcówek i wykonanie commit z wynik:

                                 v master
         a…   b…   c…   f…       1…
bob      o<---o<---o<---o<-------o
                   ^             |
                   |    d…   e…  |
                   +----o<---o<--+
                             ^ origin/master

Mam nadzieję, że połączenie nie spowoduje konfliktów (jeśli je przewidujesz, możesz wykonać dwa kroki ręcznie w git z fetch oraz merge). Następnie należy ponownie wprowadzić te zmiany do origin, co spowoduje szybkie scalanie, ponieważ commit merge jest bezpośrednim potomkiem najnowszego w repozytorium origin:

                                 v origin/master
                                 v master
         a…   b…   c…   f…       1…
bob      o<---o<---o<---o<-------o
                   ^             |
                   |    d…   e…  |
                   +----o<---o<--+

                                 v master
         a…   b…   c…   f…       1…
origin   o<---o<---o<---o<-------o
                   ^             |
                   |    d…   e…  |
                   +----o<---o<--+

Istnieje jeszcze jedna opcja łączenia w git i hg, o nazwie rebase, która przenieś zmiany Boba na po najnowszych zmianach. Ponieważ nie chcę, aby ta odpowiedź była bardziej gadatliwa, pozwolę ci przeczytać git, mercurial lub bazaar docs about that instead.

Jako ćwiczenie dla czytelnika, spróbuj wyciągnąć, jak to będzie działać z innym użytkownikiem zaangażowanym. Podobnie jak w powyższym przykładzie z Bobem. Łączenie między repozytoriami jest łatwiejsze niż myślisz, ponieważ wszystkie zmiany/zmiany są unikalne / align = "left" /

Istnieje również problem wysyłania łatek pomiędzy każdym deweloperem, co było ogromnym problemem w Subversion, który jest łagodzony w git, hg i bzr przez unikalnie identyfikowalne poprawki. Gdy ktoś połączy swoje zmiany (np. zrobi commit scalający) i wyśle je do wszystkich innych członków zespołu, aby je zużyć poprzez wpychanie do centralnego repozytorium lub wysyłanie łatek, nie musi się martwić o scalenie, ponieważ już się to stało. Martin Fowler nazywa ten sposób praca rozwiązła integracja .

Ponieważ struktura różni się od Subversion, zamiast tego wykorzystuje DAG, umożliwia rozgałęzianie i scalanie w łatwiejszy sposób nie tylko dla systemu, ale także dla użytkownika.