[nieco przeredagowane i sformatowane] biorąc pod uwagę klon utworzony za pomocą git clone --single-branch --depth 1 url directory, Jak mogę go zaktualizować, aby osiągnąć ten sam wynik co rm -rf directory; git clone --single-branch --depth 1 url directory?

Zauważ, że --single-branch jest domyślnym przy użyciu --depth 1. Gałąź (pojedyncza) jest tą, którą dajesz -b. Jest długa strona, która idzie tutaj o użyciu -b z tagami, ale zostawię to na później. Jeśli nie używasz -b, Twój Git pyta" upstream " Git-the Git at url-which branch to wymeldował się i udaje, że użyłeś -b thatbranch. Oznacza to, że ważne jest, aby zachować ostrożność podczas używania --single-branch bez -b aby upewnić się, że bieżąca gałąź tego repozytorium jest rozsądna, i oczywiście, kiedy wykonasz użyj -b, aby upewnić się, że podany argument branch naprawdę nazywa gałąź, a nie znacznik.

Prosta odpowiedź jest w zasadzie ta, z dwoma niewielkimi zmianami:

Po https://stackoverflow.com/a/20508591/279335, próbowałem git fetch --depth 1; git reset --hard origin/master, ale dwie rzeczy: po pierwsze nie rozumiem, dlaczego git reset jest potrzebny, po drugie, chociaż pliki wydają się być aktualne, niektóre stare pliki pozostają i git clean -df nie usuwa tych plików.

Dwie niewielkie zmiany to: upewnij się, że używasz origin/branchname zamiast tego i dodaj -x (git clean -d -f -x lub git clean -dfx) do kroku git clean. Jeśli chodzi o dlaczego , to robi się trochę bardziej skomplikowane.

Co się dzieje na

bez --depth 1, krok {[33] } wywołuje drugi Git i pobiera z niego listę nazw gałęzi i odpowiadających im identyfikatorów skrótu zatwierdzania. Oznacza to, że znajduje listę wszystkich gałęzi upstream i ich bieżących commitów. Następnie, ponieważ posiadasz --single-branch repozytorium, Twój Git wyrzuca wszystkie gałęzie poza pojedynczą gałęzią i przenosi wszystko, czego Git potrzebuje, aby połączyć bieżący commit z powrotem do commitów, które już masz w swoim repozytorium. repozytorium.

z --depth 1, Twój Git nie przeszkadza w łączeniu nowego commita ze starszymi historycznymi commitami. Zamiast tego, uzyskuje tylko jeden commit i inne obiekty Git potrzebne do wykonania tego jednego commita. Następnie pisze dodatkowy wpis "shallow graft", aby oznaczyć jeden commit jako nowy commit pseudo-root.

Zwykłe (nie płytkie) klonowanie i pobieranie

To wszystko jest związane z tym, jak Git zachowuje się, gdy używasz normalnego (non-shallow, nie-single-branch) clone: git fetch wywołuje Git, pobiera listę wszystkiego, a następnie przynosi to, czego jeszcze nie masz . To dlatego początkowy klon jest tak powolny, a pobieranie do aktualizacji jest zwykle tak szybkie: gdy otrzymasz pełny klon, aktualizacje rzadko mają bardzo wiele do przekazania: może kilka commitów, może kilkaset, a większość z tych commitów też nie potrzebuje zbyt wiele więcej.

Historia repozytorium jest tworzona z commitów. Każdy commit nazywa swój rodzic commit (lub dla merges, parent commits, liczba mnoga), w łańcuchu, który przechodzi wstecz od "ostatniego commita", do poprzedniego commita, do jakiegoś bardziej-przodkowego commita, i tak dalej. Łańcuch ostatecznie zatrzymuje się, gdy osiągnie commit, który nie ma rodzica, np. pierwszy commit w repozytorium. Ten rodzaj commita to root commit.

Czyli możemy narysować wykres commitów. W naprawdę prostym repozytorium wykres jest tylko prostą linia, ze wszystkimi strzałkami skierowanymi do tyłu:

o <- o <- o <- o   <-- master

Nazwa master wskazuje na czwarty i ostatni commit, który wskazuje na trzeci, który wskazuje na drugi, który wskazuje na pierwszy.

Każdy commit niesie ze sobą pełną migawkę wszystkich plików, które wchodzą w ten commit. Pliki, które w ogóle nie zostały zmienione, są dzielone pomiędzy tymi commitami: czwarty commit "pożycza" niezmienioną wersję od trzeciego commita, który "pożycza" to od drugiego, i tak dalej. Dlatego każdy commit nazywa wszystkie "obiekty Git", których potrzebuje, a Git albo Znajduje te obiekty lokalnie-ponieważ już je posiada - albo Używa protokołu fetch, aby przenieść je z innego, wyższego Gita. Istnieje format kompresji o nazwie "packing" , oraz specjalny wariant transferu sieciowego o nazwie "thin packs", który pozwala Gitowi zrobić to jeszcze lepiej / bardziej fantazyjnie, ale zasada jest prosta: Git potrzebuje wszystkich i tylko tych obiektów, które idą z zbiera nowe commity. Twój Git decyduje, czy posiada te obiekty, a jeśli nie, pobiera je z ich Gita.

        o--o   <-- feature/tall
       /
o--o--o---o    <-- master
    \    /
     o--o      <-- bug/short

Tutaj branch bug/short jest scalony z powrotem do master, podczas gdy branch feature/tall jest nadal w fazie rozwoju. nazwa bug/short Można (prawdopodobnie) teraz całkowicie usunąć: nie potrzebujemy go już, jeśli skończymy robić commity na nim. Commit na końcu master nazywa dwa poprzednie commity, włączając commit na końcubug/short, więc pobierając master pobieramy commity bug/short.

Zauważ, że zarówno prosty jak i nieco bardziej skomplikowany Wykres ma tylko jeden commit główny. To dość typowe: wszystkie repozytoria posiadające commity mają co najmniej jeden commit główny, ponieważ pierwszy commit jest zawsze root commit; ale większość repozytoriów ma tylko jeden commit główny. Można jednak mieć różne commity roota, tak jak w przypadku tego wykresu:

 o--o
     \
o--o--o   <-- master

Lub ten:

 o--o     <-- orphan

o--o      <-- master

W rzeczywistości, jeden z tylko jeden master został prawdopodobnie wykonany przez połączenie orphan w master, a następnie usunięcie nazwy orphan.

Przeszczepy i zamienniki

Git od dłuższego czasu ma (prawdopodobnie chwiejne) wsparcie dla graftów, które zostało zastąpione (znacznie lepszym, w rzeczywistości-stałe) wsparcie dla generycznych zamienników. Aby je konkretnie zrozumieć, musimy dodać do powyższego pogląd, że każdy commit ma swój unikalny identyfikator. Te identyfikatory są wielkimi, brzydkimi 40-znakowymi hashami SHA-1, face0ff... i tak dalej. W rzeczywistości, każdy obiekt Git ma unikalny identyfikator, chociaż dla celów graficznych, wszystko na czym nam zależy to commity.

Do rysowania wykresów, te duże hash id są zbyt bolesne, aby ich używać, więc możemy używać jednoliterowych nazw A poprzez Z zamiast tego. Użyjmy tego wykresu jeszcze raz, ale wpisz jednoliterowe nazwy:

        E--H   <-- feature/tall
       /
A--B--D---G    <-- master
    \    /
     C--F      <-- bug/short

Commit H odnosi się z powrotem do commit E (E jest H'S rodzicem ). Commit G, który jest merge commit -co oznacza, że ma co najmniej dwoje rodziców-odnosi się do obu D i F, i tak dalej.

Zauważ, że oddział nazywa, feature/tall, master, i bug/short, każdy punkt do jednego commita. Nazwa bug/short wskazuje na commit F. To jest dlaczego commit F znajduje się na gałęzi bug/short ... tak samo jak commit C. Commit C jest włączony bug/short, ponieważ jest osiągalny od nazwy. Nazwa prowadzi nas do F, a F do C, więc C jest na gałęzi bug/short.

Zauważ jednak, że commit G, końcówka master, zmusza nas do commit F. Oznacza to, że commit F jest również na gałęzi master. jest to kluczowa koncepcja w Git: commity mogą być na jednym, wiele , lub nawet żadnych gałęzi. nazwa gałęzi jest tylko sposobem na rozpoczęcie pracy w grafie zatwierdzania. Są inne sposoby, takie jak nazwy tagów, refs/stash (które prowadzą do aktualnego schowka: każdy Schowek to w rzeczywistości kilka commitów) oraz reflogy (które zwykle są ukryte przed widokiem, ponieważ zwykle są po prostu bałaganem).

¹nie W bardziej ogólnym przypadku zalecałem użycie git replace zamiast, ponieważ to również było i jest , a nie. Jedynym zalecanym zastosowaniem dla przeszczepów jest-a przynajmniej było, lata temu-umieszczenie ich na tyle długo, aby uruchomić {83]} do {206]}skopiować {207]} zmienioną przeszczepioną historię, po czym należy całkowicie odrzucić przeszczepioną historię. Możesz w tym celu należy również użyć git replace, ale w przeciwieństwie do grafów, można użyć git replace na stałe lub na pół trwale, bez potrzebującego git filter-branch.

Tworzenie płytkiego klonu

Aby utworzyć płytką klon depth-1 bieżącego stanu repozytorium upstream, wybierzemy jedną z trzech nazw gałęzi-feature/tall, master, lub bug/short - i przetłumaczyć go na identyfikator commita. Wtedy napiszemy specjalny wpis, który mówi: "Kiedy zobaczysz ten commit, udawaj, że ma no commit nadrzędny, tzn. jest commitem głównym."

Powiedzmy, że wybierzemy master. Nazwa master wskazuje na commit G, więc aby utworzyć shallow klon commit G, jak zwykle otrzymujemy commit G Z Gita, ale potem piszemy specjalny wpis, który twierdzi, że commit Gma nie ma rodziców. Umieściliśmy to w naszym repozytorium, a teraz nasz wykres wygląda tak: {]}

G   <-- master, origin/master

Te identyfikatory rodziców są nadal w środku G; to tylko, że za każdym razem, gdy mamy Git use lub pokaż nam historię, natychmiast "grafts" nic-at-all on, tak że G wydaje się być głównym commitem do śledzenia historii.

Aktualizacja płytkiego klonu, który zrobiliśmy wcześniej

Ale co jeśli mamy już (głębokość-1) klon, i chcemy zaktualizować to? To nie problem. Załóżmy, że zrobiliśmy płytki klon upstream back kiedy master wskazał na commit B, zanim nowe gałęzie i poprawka błędu. Oznacza to, że obecnie mamy to:{[203]]}

B   <-- master, origin/master

B   <-- master

G   <-- origin/master

git reset --hard origin/master

B   [abandoned - but see below]

G   <-- master, origin/master

Po pierwsze, jeśli używasz --single-branch, Git zmienia normalną konfigurację fetch W Nowym repozytorium. Normalna konfiguracja fetch zależy od nazwy, którą wybierzesz dla remote , ale domyślnym jest origin, więc użyję origin tutaj. Czyta:

fetch = +refs/heads/*:refs/remotes/origin/*

Ponownie, jest to normalna konfiguracja dla normalnego klonu. Ta konfiguracja mówi git fetch co pobrać , czyli "wszystkie gałęzie". Gdy używasz --single-branch, zamiast tego otrzymujesz linię fetch, która odnosi się tylko do jednej gałęzi:

fetch = +refs/heads/zorg:refs/remotes/origin/zorg

whatever branch you / align = "left" / linearkażdy przyszłość git fetch będzie posłuszny tej linii,³ więc nie weźmiesz innych gałęzi. Jeśli czy chcesz później pobrać inne gałęzie, będziesz musiał zmienić tę linię lub dodać więcej linii.

Po drugie, jeśli użyjesz --single-branch i sklonujesz znacznik , Git umieści dość dziwną linię fetch. Na przykład z git clone --single-branch -b v2.1 ... otrzymuję:

fetch = +refs/tags/v2.1:refs/tags/v2.1

To oznacza, że dostaniesz No gałęzie, i chyba że ktoś przesunął znacznik,⁴git fetch nic nie zrobi!

Po Trzecie, domyślne zachowanie znaczników jest nieco dziwne ze względu na sposób uzyskiwania znaczników git clone i git fetch. Pamiętaj, że znaczniki są po prostu odniesieniem do jednego commita, podobnie jak gałęzie i wszystkie inne odniesienia. Istnieją dwie kluczowe różnice między gałęziami i znacznikami, chociaż: gałęzie są oczekiwane do przeniesienia (a znaczniki nie są), a gałęzie get przemianowane (A Tagi nie).

Pamiętajcie, że przez cały powyższy czas znajdujemy, że drugi (upstream) Gita master staje się naszym origin/master, i tak dalej. Jest to przykład procesu zmiany nazwy. Zobaczyliśmy także, krótko, dokładnie jak {207]} ta zmiana nazwy działa , poprzez linię fetch =: nasz Git bierze ich refs/heads/master i zmienia je na nasze {187]}. Ta nazwa jest nie tylko inna - patrząc (origin/master), ale dosłownie nie może być taki sam jak każdy z naszych oddziałów. Jeśli utworzymy gałąź o nazwie origin/master,⁵ w przeciwieństwie do innych gałęzi, które nie posiadają tej samej nazwy. Tylko wtedy, gdy Git używa krótszej nazwy, mamy jedną (regularną, lokalną) gałąź o nazwie origin/master i inną (zdalnie śledzącą) gałąź o nazwie origin/master. (To jest jak bycie w grupie, w której każdy ma na imię Bruce {224]}.)

Tagi nie przechodzą przez to wszystko. Znacznik v2.1 jest po prostu nazwany refs/tags/v2.1. Oznacza to, że nie ma możliwości oddzielenia znacznika "ich" od znacznika "Twój". Możesz mieć swoją metkę lub ich metkę. Tak długo, jak nikt nigdy nie przesunie znacznika, nie ma to znaczenia: jeśli oba znaczniki mają ten znacznik, musi on wskazywać na ten sam obiekt . (Jeśli ktoś zacznie przenosić znaczniki, robi się nieprzyjemnie.)

W każdym przypadku, Git implementuje "normalne" pobieranie tagów za pomocą prostej reguły:⁶gdy Git już ma commit, jeśli jakiś znacznik nazywa ten commit, Git również kopiuje znacznik. w przypadku zwykłych klonów, pierwszy klon pobiera wszystkie znaczniki, a następnie kolejne operacje git fetch otrzymują nowe znaczniki . Płytki klon, jednak z definicji pomija niektóre commity, a mianowicie wszystko poniżej dowolnego punktu grafu na wykresie. Te commity nie podniosą znaczników. They can ' t : aby mieć znaczniki, musisz mieć commity. Git nie jest dozwolony (z wyjątkiem płytkich grafts), aby mieć identyfikator commita bez jego posiadania.

³możesz podać git fetch niektóre refspec(y) w wierszu poleceń, a te nadpiszą domyślną wartość. Dotyczy to tylko domyślnego pobierania. Można również użyć wielu linii fetch = w konfiguracji, np. do pobrania tylko określonego zestawu gałęzi, chociaż normalnym sposobem na "ograniczenie" klonu początkowo z jedną gałęzią jest odłożenie zwykłego +refs/heads/*:refs/remotes/origin/* fetch Kolejka

⁴ponieważ znaczniki nie są przypuszczane do przeniesienia, możemy po prostu powiedzieć "to nic nie robi". Jeśli jednak się poruszają, + W refspec reprezentuje flagę siły, więc tag kończy się w ruchu.

⁵nie rób tego. To zagmatwane. Git poradzi sobie z tym dobrze-lokalna gałąź znajduje się w lokalnej przestrzeni nazw, a gałąź zdalnego śledzenia jest w zdalnej przestrzeni nazw-ale to naprawdę mylące.

⁶ta reguła nie pasuje do dokumentacji. Testowałem na Git w wersji 2.10.1; starsze Gits mogą używać innej metody.