Git Pull wyjaśnił

Streszczenie:

Git Pull to powszechnie używane polecenie w GIT, które służy do pobierania i scalania zmian z zdalnego repozytorium z lokalnym repozytorium. Aktualizuje lokalne repozytorium o najnowsze zmiany w zdalnym repozytorium.

Kluczowe punkty:

1. Git Pull łączy polecenia Git Fetch i Git Scal w jednym wygodnym poleceniu.
2. Służy do pobierania najnowszych zmian z zdalnego repozytorium i połączenia ich z lokalnym oddziałem.
3. Git Pull może być używany do aktualizacji wielu oddziałów w lokalnym repozytorium.
4. Po uruchomieniu git ciągnie, sprawdza, czy występują jakieś nowe zmiany w zdalnym repozytorium od ostatniego pociągnięcia lub pobierania.
5. Jeśli pojawiają się nowe zmiany, git pobieraj pobieranie i stosuje te zmiany w lokalnym repozytorium.
6. Git Pull automatycznie łączy zmiany z oddziałem lokalnym.
7. Jeśli podczas procesu scalania występują jakieś konflikty, musisz je rozwiązać ręcznie.
8. Możesz użyć pochodzenia git pull polecenie aktualizacji określonej gałęzi.
9. Git Pull to przydatne polecenie do aktualizacji lokalnego repozytorium za pomocą zdalnego repozytorium.
10. Zaleca się regularne uruchamianie git, aby upewnić się, że masz najnowsze zmiany.

Pytania:

1. Czy git ciągną wszystkie gałęzie?

Po uruchomieniu git Pull, aktualizuje bieżącą gałąź w lokalnym repozytorium o zmiany ze zdalnego repozytorium. Nie aktualizuje automatycznie wszystkich oddziałów w lokalnym repozytorium.

2. Jak Git ciągnie pracuje?

Git Pull łączy polecenia Git Fetch i Git Scal. Najpierw pobiera najnowsze zmiany w zdalnym repozytorium, a następnie łączy te zmiany z oddziałem lokalnym. Jeśli podczas procesu scalania występują jakieś konflikty, musisz je rozwiązać ręcznie.

3. Czy git może zaktualizować określoną gałąź?

Tak, możesz użyć pochodzenia git pull polecenie aktualizacji określonej gałęzi w lokalnym repozytorium za pomocą zmian w zdalnym repozytorium.

4. Jak często powinienem biegać git ciągnie?

Zaleca się regularne uruchamianie git, zwłaszcza przed rozpoczęciem jakiejkolwiek pracy lub popchnięcia zmian w zdalnym repozytorium. Zapewnia to najnowsze zmiany i zmniejsza szanse na konflikty.

5. Co się stanie, jeśli pojawią się konflikty podczas gita?

Jeśli występują konflikty podczas procesu scalania, Git Pulls i zachęca do ręcznego rozwiązania konfliktów. Musisz edytować sprzeczne pliki, rozwiązać konflikty, a następnie popełnić zmiany.

6. Czy mogę cofnąć git ciągnięcia?

Zrzucenie gita może być nieco trudne. Po pobraniu zmian ze zdalnego repozytorium i połączeniu ich w lokalny oddział, staje się częścią Twojej historii zatwierdzenia. Możesz użyć GIT Reverse, aby przywrócić zmiany, ale zaleca się utworzenie kopii zapasowej lub skonsultowanie się z zespołem przed wykonywaniem jakichkolwiek operacji cofania.

7. Może git ciągnąć zmiany lokalne?

Jeśli wprowadziłeś lokalne zmiany w pliku, który został również zmodyfikowany w zdalnym repozytorium, Git Pull próbuje automatycznie scalić te zmiany. Jeśli istnieją konflikty, zachęca do ich ręcznego rozwiązania. Domyślnie Git Pull nie nadpisuje lokalne zmiany bez zgody.

8. Jak mogę sprawdzić, czy mój lokalny oddział jest aktualny z zdalnym oddziałem?

Możesz użyć polecenia git oddziału, aby sprawdzić, czy lokalny oddział jest aktualny w zdalnej gałęzi. Po uruchomieniu git pull możesz użyć git gałąź -vv, aby pokazać bardziej szczegółowe informacje o lokalnych i zdalnych gałęziach.

9. Czy mogę użyć git pull, aby zaktualizować wiele gałęzi?

Tak, git Pull może być używany do aktualizacji wielu oddziałów w lokalnym repozytorium. Możesz przełączyć się na określoną gałąź i uruchomić git Pull, aby zaktualizować tę gałąź o najnowsze zmiany z zdalnego repozytorium.

10. Czy git ciągnie to samo co git fetch?

Nie, git ciągnie nie jest tym samym jak git fetch. Git Fetch tylko pobiera najnowsze zmiany z zdalnego repozytorium, ale nie łączy ich z oddziałem lokalnym. Z drugiej strony git przyciąga zmiany i łączy je z lokalną gałęzią.

11. Można użyć git do aktualizacji oddziału z innego zdalnego repozytorium?

Tak, możesz określić zdalne repozytorium podczas uruchamiania polecenia git pull. Na przykład Git Pull aktualizuje określony oddział z określonego zdalnego repozytorium.

12. Czy mogę uruchomić git ciągnie bez określenia gałęzi?

Jeśli uruchomisz git ciągnie bez określenia gałęzi, aktualizuje bieżącą gałąź w lokalnym repozytorium o zmiany w zdalnym repozytorium.

13. Czy mogę użyć git pull, aby zaktualizować gałąź do konkretnego zatwierdzenia?

Nie, git Pull jest używany przede wszystkim do aktualizacji oddziału o najnowsze zmiany w zdalnym repozytorium. Jeśli chcesz zaktualizować gałąź do konkretnego zatwierdzenia, możesz użyć polecenia GIT RESET.

14. Jak mogę uniknąć konfliktów podczas git?

Aby uniknąć konfliktów podczas Pull Pull, zaleca się regularną aktualizację lokalnego repozytorium o najnowsze zmiany z zdalnego repozytorium poprzez uruchamianie git Pull. Pomaga to w synchronizacji lokalnych i zdalnych gałęzi. Dobrą praktyką jest również komunikacja i koordynowanie z zespołem, aby zminimalizować szanse na sprzeczne zmiany.

15. Czy git może pobrać pliki usuwania w moim lokalnym repozytorium?

Nie, git Pull nie usuwa plików w lokalnym repozytorium, chyba że zostały one usunięte w zdalnym repozytorium. Nawet w takim przypadku Git Pull próbuje połączyć zmiany i w miarę możliwości zachowuje lokalne modyfikacje. Jednak zawsze jest dobrą praktyką, aby wykonać kopię zapasową lokalnego repozytorium przed wykonaniem operacji scalania.

Git Pull wyjaśnił

Uruchomić GIT Branch Ponownie i sprawdź, czy gałęzie istnieją lokalnie:

Czy git ciągną wszystkie gałęzie

Zmiany w Git-pull podręcznik

1. 2.40.1 Brak zmian
2. 2.40.0 03/12/23
3. 2.36.1 → 2.39.3 Brak zmian
4. 2.36.0 04/18/22
5. 2.35.1 → 2.35.8 Brak zmian
6. 2.35.0 01/24/22
7. 2.34..34.8 Brak zmian
8. 2.34.0 11/15/21
9. 2.33.2 → 2.33.8 Brak zmian
10. 2.33.1 10/12/21
11. 2.33.0 08/16/21
12. 2.32.1 → 2.32.7 Brak zmian
13. 2.32.0 06/06/21
14. 2.31.1 → 2.31.8 Brak zmian
15. 2.31.0 03/15/21
16. 2.30.1 → 2.30.9 Brak zmian
17. 2.30.0 27/27/20
18. 2.29.1 → 2.29.3 Brak zmian
19. 2.29.0 10.04.20
20. 2.27.1 → 2.28.1 Brak zmian
21. 2.27.0 06/01/20
22. 2.25.2 → 2.26.3 Brak zmian
23. 2.25.1 02/17/20
24. 2.25.0 01/13/20

Sprawdź swoją wersję GIT, uruchamiając

NAZWA

git -pull – pobieraj i integruj z innym repozytorium lub oddziałem lokalnym

STRESZCZENIE

git ciągnie [] [[…]]

OPIS

Zawiera zmiany z zdalnego repozytorium w bieżącą gałęzie. Jeśli bieżąca gałąź znajduje się za pilotem, wówczas domyślnie będzie szybko do przodu, aby pasować do pilota. Jeśli bieżąca gałąź i pilot rozeszły się, użytkownik musi określić, jak pogodzić rozbieżne gałęzie z –rebase lub-no-rebase (lub odpowiednia opcja konfiguracji w Pull.Rebaz).

Mówiąc dokładniej, GIT Pull uruchamia Git Fetch z danymi parametrami, a następnie w zależności od opcji konfiguracji lub flag wiersza poleceń, wywoła git rebase lub git scal, aby pogodzić rozbieżne gałęzie.

powinna być nazwą zdalnego repozytorium przekazanego do git-fetch [1]. może wymienić dowolne zdalne ref (na przykład nazwa znacznika) lub nawet zbiór ref z odpowiednimi odległymi gałęziami (e.G., Refs/Heads/*: Refs/Remotes/Origin/*), ale zwykle jest to nazwa gałęzi w zdalnym repozytorium.

Wartości domyślne dla i są odczytywane z konfiguracji „zdalnego” i „scalania” dla bieżącej gałęzi jako ustalonej przez GIT-Branch [1]-Track .

Załóżmy, że istnieje następująca historia, a obecny oddział jest „mistrzem”:

A --- B --- C Master o pochodzeniu / d --- e --- f --- g master ^ pochodzenie / master w twoim repozytorium

Następnie „Git Pull” przyniesie i odtworzy zmiany ze zdalnej gałęzi głównej, ponieważ odchylił się od lokalnego mistrza (i.mi., E) Aż do obecnego zatwierdzenia (c) na szczycie Master i nie zarejestruje wyniku nowego zatwierdzenia wraz z nazwami dwóch zobowiązań nadrzędnych i komunikatem dziennika od użytkownika opisującego zmiany.

A --- B --- C ONISION / MASTER / \ D --- E --- F --- G --- H Master

Szczegółowe informacje znajdują się w Git-Merge [1], w tym sposób prezentacji konfliktów i obsługi.

W Git 1.7.0 lub później, aby anulować sprzeczne scalanie, użyj GIT Reset -Merge . Ostrzeżenie: W starszych wersjach Git, działających git ciągnie Z niepokojącymi zmianami zostaje zniechęcone: chociaż możliwe, pozostawia cię w stanie, z którego może być trudne do wycofania się w przypadku konfliktu.

Jeśli którekolwiek ze zdalnych zmian pokrywa się z lokalnymi niezwiązanymi zmianami, scalanie zostanie automatycznie anulowane, a drzewo robocze nietknięte. Zasadniczo najlepiej jest uzyskać wszelkie lokalne zmiany w zakresie pracy przed wyciągnięciem ich lub schwytaniem ich git-sklasy [1].

Opcje

Jest to przekazywane zarówno podstawowi git-fett do raportowania Squelcha podczas transferu, jak i podstawowego git-merge, aby zamknąć wyjście podczas łączenia.

Pass-czasownik do git-fetch i git-merge.

Ta opcja kontroluje, jeśli należy pobrać nowe zobowiązania zaludnionych podmodułów, a jeśli należy zaktualizować również robocze drzewa aktywnych submodułów (patrz Git-Fetch [1], Git-Config [1] i Gitmodules [5]).

Jeśli kasa jest wykonywana za pośrednictwem Rebase, lokalne zobowiązania podmodułowe są również reningowe.

Jeśli aktualizacja jest wykonywana za pośrednictwem scalania, konflikty submodułu są rozwiązane i sprawdzone.

Opcje związane z połączeniem

–commit-No-Commit

Wykonaj scalanie i popełnij wynik. Tę opcję można użyć do zastąpienia-No-Commit. Tylko przydatne podczas łączenia.

Z-No-Commit wykonaj scalanie i zatrzymaj tuż przed utworzeniem zatwierdzenia scalania, aby dać użytkownikowi szansę na sprawdzenie i dalsze dostosowanie wyniku scalania przed popełnieniem.

Zauważ, że aktualizacje szybkich do przodu nie tworzą zatwierdzenia scalania i dlatego nie ma możliwości zatrzymania tych scalonych z-No-Commit. .

–Edytuj -e -no -edit

Przywołaj redaktor przed popełnieniem udanego połączenia mechanicznego w celu dalszej edycji automatycznego wygenerowanego komunikatu scalania, aby użytkownik mógł wyjaśnić i uzasadnić scalanie. Opcję-No-Edit może być użyta do zaakceptowania automatycznego wygenerowanego wiadomości (jest to ogólnie zniechęcone).

Starsze skrypty mogą zależeć od historycznego zachowania braku umożliwienia użytkownikowi edytowania komunikatu dziennika scalania. Zobaczą edytora otwartego, gdy uruchomi git scal . Aby ułatwić dostosowanie takich skryptów do zaktualizowanego zachowania, zmienna środowiskowa git_merge_autoedit może być ustawiona na nie na początku.

Ta opcja określa, w jaki sposób komunikat scalania zostanie oczyszczony przed zaangażowaniem. Zobacz Git-Commit [1], aby uzyskać więcej informacji. Ponadto, jeśli jest podana wartość nożyczek, nożyczki zostaną dołączone do scerge_msg przed przekazaniem maszyny zatwierdzenia w przypadku konfliktu scalania.

Aktualizacja nowej historii, jeśli nie ma rozbieżnej historii lokalnej. Jest to domyślne, gdy nie podano metody uzgadniania rozbieżnych historii (za pośrednictwem –Rebase =* Flags).

Scal się, a nie odmiany, określa, w jaki sposób scalanie się jest obsługiwane, gdy połączona historia jest już potomkiem obecnej historii. Jeśli wymagane jest scalanie, –ff jest domyślnie, chyba że połączenie tagu z adnotacjami (i prawdopodobnie podpisaniem), który nie jest przechowywany w jego naturalnym miejscu w refs/ tags/ hierarchia, w którym to przypadku-No-Ff, w którym.

Z –ff, jeśli to możliwe, rozwiąż scalanie jako szybki do przodu (zaktualizuj wskaźnik oddziału, aby pasował do scalonej gałęzi; nie utwórz zatwierdzenia scalania). Jeśli nie jest to możliwe (gdy połączona historia nie jest potomkiem obecnej historii), stwórz zatwierdzenie scalania.

Z-NO-F, Utwórz zatwierdzenie scalania we wszystkich przypadkach, nawet jeśli scalanie można zamiast tego rozwiązać jako szybki do przodu.

-S []–gpg-sign [=]-no-gpg-podpis

GPG-podpisanie wynikowego zatwierdzenia scalania. Kluczowy argument jest opcjonalny i jest domyślny tożsamości komisji; Jeśli zostanie określony, musi to utknąć w opcji bez miejsca. –No-GPG-Sign jest przydatne do przeciwdziałania obu zatwierdzeniu.Zmienna konfiguracji GPGSIGN i wcześniejszy-GPG-SIGN .

Oprócz nazw gałęzi, wypełnij komunikat dziennika z opisami jednowierszowymi z większości rzeczywistych zobowiązań, które są scalane. Zobacz także GIT-FMT-MERGE-MSG [1]. Tylko przydatne podczas łączenia.

Z-NO-LOG nie wymieniaj jedno-linii z faktycznych zatrudnionych.

–Signoff-No-Signoff

Dodaj podpisaną przyczepę przez komisję na końcu komunikatu dziennika zatwierdzenia. Znaczenie podpisania zależy od projektu, do którego ty’ponownie popełnić. Na przykład może poświadczyć, że komisja ma prawa do przedstawienia pracy w ramach projektu’licencja S lub zgadza się na pewną reprezentację współpracowników, takich jak certyfikat pochodzenia programistów. (Patrz http: // rozwójercertificate.org dla tego, który używany przez jądro Linux i GIT.) Zapoznaj się z dokumentacją lub kierownictwem projektu, do którego ty’Przyczyniając się do zrozumienia, w jaki sposób podpisy są wykorzystywane w tym projekcie.

Opcję-NO-SIGNOFF może być użyta do przeciwdziałania wcześniejszej opcji Signoff w wierszu poleceń.

–Stat -n -no -stat

Pokaż diffstat na końcu scalania. Diffstat jest również kontrolowany przez połączenie opcji konfiguracji.Stat.

Z -n lub -statem nie pokazuje diffstat na końcu scalania.

–Squash-No-Squash

Wyprodukuj stan roboczy i stan indeksu, tak jakby miało miejsce prawdziwe scalanie (z wyjątkiem informacji scalania), ale nie dokonuj zatwierdzenia, nie przesuń głowy ani nie zapisuj $ git_dir/merge_head (aby spowodować, że następne polecenie zatwierdzenia tworzenia zatwierdzenia scalania). Pozwala to na utworzenie jednego zatwierdzenia na bieżącym gałęzi, którego efekt jest taki sam, jak połączenie innej gałęzi (lub więcej w przypadku ośmiornicy).

Z-no-squash wykonuje scalanie i zatwierdź wynik. Tę opcję można użyć do zastąpienia -Squash.

Z – -squash, -commit nie jest dozwolone i zawiedzie.

Tylko przydatne podczas łączenia.

Domyślnie uruchamiane są haki przedwczeniowe i zatwierdzenia. Kiedy podawane jest-No-Verify, są one oni omijane. Zobacz także Githooks [5]. Tylko przydatne podczas łączenia.

Użyj danej strategii scalania; mogą być dostarczane więcej niż raz, aby określić je w kolejności, że należy wypróbować. Jeśli nie ma opcji -S, zamiast tego używana jest wbudowana lista strategii (ORT podczas połączenia pojedynczej głowy, ośmiornica w inny sposób).

Przejdź specyficzną opcję strategii scalania do strategii scalania.

Sprawdź, czy zatwierdzenie końcówki połączonej gałęzi bocznej jest podpisane z ważnym kluczem, i.mi. Klucz, który ma prawidłowy UID: W domyślnym modelu zaufania oznacza to, że klawisz podpisania został podpisany przez zaufany klucz. Jeśli zatwierdzenie końcówki gałęzi bocznej nie jest podpisane z prawidłowym kluczem, scalanie jest przerwane.

Tylko przydatne podczas łączenia.

–Podsumowanie-No-Summary

Synonimy –stat i-no-stat; Są one przestarzałe i zostaną usunięte w przyszłości.

Automatycznie utwórz tymczasowy wpis na stas. Oznacza to, że możesz uruchomić operację na brudnej robocie. Jednak używaj z ostrożnością: końcowa aplikacja do zapasów po pomyślnym scalaniu może spowodować konflikty nietrywialne.

Domyślnie polecenie Git Merge odmawia scalania historii, które nie dzielą wspólnego przodka. Tę opcję można wykorzystać do zastąpienia tego bezpieczeństwa podczas łączenia historii dwóch projektów, które rozpoczęły ich życie niezależnie. Ponieważ jest to bardzo rzadka okazja, żadna zmienna konfiguracyjna, aby to domyślnie włączyć i nie zostanie dodane.

Tylko przydatne podczas łączenia.

-R –Rebase [= Fałsz | True | Merges | Interactive]

Kiedy to prawda, Rebase bieżącą gałąź na szczycie gałęzi w górę po pobraniu. Jeśli istnieje zdalnie śledząca gałąź odpowiadająca gałęzi powyżej, a gałąź upstream została odniesiona od czasu ostatniego pobrania, rebaza wykorzystuje te informacje, aby uniknąć ponownego ponownego zmiany zmian nielokalnych.

Po scalaniu, Rebase używające GIT Rebase-Rebase-Merges, aby lokalne zatrudnienia scalania były zawarte w rebazie (szczegółowe informacje patrz Git-Rebaza [1]).

Gdy fałsz, scal gałąź w górę w bieżącą gałęzie.

Podczas interaktywnej włącz interaktywny tryb rebazy.

Zobacz Pull.Rebase, oddział..REBASE I BANCED.autosetuprebase w git-config [1] Jeśli chcesz, aby git ciągnie się przy użyciu-Rebase zamiast scalania.

To jest skrót dla –Rebase = false.

Opcje związane z pobieraniem

Pobieraj wszystkie piloty.

Dołącz nazwy ref i nazwy obiektów pobieranych ref one do istniejącej zawartości .git/fetch_head . Bez tej opcji stare dane .git/fetch_head zostanie zastąpiony.

Użyj transakcji atomowej, aby aktualizować lokalne ref. Albo wszystkie Ref są aktualizowane, albo w przypadku błędu, żadne Ref nie są aktualizowane.

Ograniczenie przyciągania do określonej liczby zatrudnienia z końca każdej odległej historii oddziału. Jeśli przynosi do płytki Repozytorium utworzone przez GIT Clone z opcją-Depth = (patrz git-klon [1]), pogłębiaj lub skróć historię do określonej liczby zatrudnienia. Tagi na pogłębione zatrudnienia nie są pobierane.

Podobne do -głębokie, z wyjątkiem tego, że określa liczbę zobowiązań z obecnej płytkiej granicy zamiast z końcówki każdej odległej historii gałęzi.

Pogłębiaj lub skróć historię płytkiego repozytorium, aby uwzględnić wszystkie osiągalne zatwierdzenia .

Pogłębiaj lub skróć historię płytkiego repozytorium, aby wykluczyć zobowiązania osiągalne z określonej zdalnej gałęzi lub znacznika. Tę opcję można określić wiele razy.

Jeżeli repozytorium źródłowe zostanie zakończone, przekonwertuj płytkie repozytorium na kompletne, usuwając wszystkie ograniczenia nałożone przez płytkie repozytoria.

Jeżeli repozytorium źródłowe jest płytkie, pobieraj jak najwięcej, aby obecne repozytorium ma tę samą historię, co repozytorium źródłowe.

–aktualizacja-shallow

Domyślnie podczas pobierania z płytkiego repozytorium Git Fetch odmawia Refs, które wymagają aktualizacji .git/płytki. Ta opcja aktualizuje .git/płytki i zaakceptuj takie ref.

Domyślnie GIT zgłosi na serwerze, zobowiązuje się do osiągnięcia od wszystkich lokalnych sędzie. Jeśli zostanie określone, GIT zgłosi tylko zobowiązania osiągalne z podanych wskazówek. Jest to przydatne do przyspieszenia pobierania, gdy użytkownik wie, który lokalny sędzia prawdopodobnie będzie wspólny z przynoszącym sof.

Ta opcja może być określona więcej niż raz; Jeśli tak, Git zgłosi zobowiązania do osiągnięcia dowolnego z podanych zobowiązań.

Argumentem tej opcji może być glob na nazwach ref, ref lub (prawdopodobnie skróconego) SHA-1 zatwierdzenia. Określenie globu jest równoważne do określenia tej opcji wielokrotnie, po jednym dla każdej pasującej nazwy ref.

Zobacz także Fetch.Negocjowanie i pchanie.Negocjuj zmienne konfiguracyjne udokumentowane w Git-Config [1] i opcji-Negotiate poniżej.

–Negocjowanie tylko

Nie pobieraj niczego z serwera i zamiast tego wydrukuj przodków dostarczonych-Negogotiation-Tip =* Argumenty, które mamy wspólne z serwerem.

Jest to niezgodne z–recurse-submodules = [tak | na żądanie] . Wewnętrznie służy to do wdrożenia push.Negocjuj opcję, patrz Git-Config [1].

Pokaż, co by się stało, bez wprowadzania żadnych zmian.

Gdy Git Fetch jest używany z: refspec może odmówić aktualizacji oddziału lokalnego, jak omówiono w części dokumentacji git-fetch [1]. Ta opcja zastępuje tę kontrolę.

Keep Pobierz Pack.

Zmodyfikuj skonfigurowany refspec, aby umieścić wszystkie ref. Zobacz zadanie prefetch w Git-Matenance [1].

Przed pobraniem usuń wszelkie odniesienia zdalne, które już nie istnieją na pilocie. Tagi nie podlegają przycinaniu, jeśli są pobierane tylko z powodu domyślnego tagu automatycznego podsumowującego lub z powodu opcji-tagów. Jeśli jednak znaczniki są pobierane z powodu jawnego refspec (w wierszu poleceń lub w konfiguracji zdalnej, na przykład, jeśli zdalne było sklonowane z opcją -mirror), wówczas podlegają one przycinaniu. Dostarczanie-PRUNE-TAGS to stenografia do dostarczania tag refspec.

Domyślnie znaczniki, które punktem w obiektach pobieranych z zdalnego repozytorium są pobierane i przechowywane lokalnie. Ta opcja wyłącza ten automatyczny tag następujący. Domyślne zachowanie dla pilota można określić za pomocą pilota..Ustawienie tagopt. Patrz Git-Config [1].

.*.Pobierz zmienne konfiguracyjne dla zdalnego repozytorium. Zapewnienie pustej opcji –refMap powoduje, że GIT ignoruje skonfigurowane refspecs i polegać całkowicie na refspecs dostarczonych jako argumenty wiersza poleceń. Szczegółowe informacje znajdują się w sekcji „Skonfigurowane gałęzie zdalnego śledzenia”.

Pobrać wszystkie tagi z pilota (i.mi., Fetch Fetch Remote Tags Refs/Tags/* w znacznikach lokalnych o tej samej nazwie), oprócz tego, co inaczej byłoby pobrane. Samo użycie tej opcji nie poddaje tagów na przycinanie, nawet jeśli -PRUNE jest używany (chociaż znaczniki i tak mogą być przycinane, jeśli są również miejscem docelowym jawnego refspec; patrz –prune).

Liczba równoległych dzieci do użycia dla wszystkich form pobierania.

Jeśli określono opcję -multiple, różne piloty zostaną pobrane równolegle. Jeśli przyciągnie wiele podmodułów, zostaną one pobierane równolegle. Aby kontrolować je niezależnie, użyj ustawień konfiguracji.równoległe i submodule.Fetchjobs (patrz Git-Config [1]).

Zazwyczaj równoległe pobieranie rekurencyjne i wielozadaniowe będą szybsze. Domyślnie pobieranie są wykonywane sekwencyjnie, a nie równolegle.

–Upstream

Jeśli pilot zostanie pomyślnie pobierany, sformuj odniesienie w górę (śledzenie), używane przez pozbawione argumentu git-pull [1] i inne polecenia. Aby uzyskać więcej informacji, zobacz Oddział..Scal i gałąź..pilot w Git-Config [1].

Po podaniu, a repozytorium do pobierania jest obsługiwane przez Git Fetch-Pack, –exec = jest przekazywany do polecenia w celu określenia ścieżki bez default dla uruchomienia polecenia na drugim końcu.

Status postępu jest zgłaszany w standardowym strumieniu błędów domyślnie, gdy jest on dołączony do terminala, chyba że podano -q. Ta flaga zmusza status postępu, nawet jeśli standardowy strumień błędu nie jest skierowany do terminala.

Przesyłać podany ciąg na serwer podczas komunikowania się za pomocą protokołu w wersji 2. Dany ciąg nie może zawierać znaku NUL lub LF. Serwer’Obsługa opcji serwera, w tym nieznanych, jest specyficzna dla serwera. Po podaniu wielu–server-option = wszystkie są wysyłane na drugą stronę w kolejności wymienionej w wierszu poleceń.

Domyślnie GIT sprawdza, czy gałąź jest zmuszona podczas pobierania. Można to wyłączyć za pośrednictwem Fetch.showForcedUpdates, ale opcja-Show Pral-Updates gwarantuje ten czek. Patrz Git-Config [1].

Domyślnie GIT sprawdza, czy gałąź jest zmuszona podczas pobierania. Pass-No-Show Corned-Datates lub Set Fetch.showForcedUpdates to False, aby pominąć tę kontrolę od powodów wydajności. Jeśli używany w trakcie Git-pull Opcja tylkofff będzie nadal sprawdzać wymuszone aktualizacje przed próbą aktualizacji szybkiej do przodu. Patrz Git-Config [1].

Użyj tylko adresów IPv4, ignorując adresy IPv6.

Użyj tylko adresów IPv6, ignorując adresy IPv4.

Repozytorium „zdalnego”, które jest źródłem operacji pobierania lub ciągnięcia. Ten parametr może być albo adresem URL (patrz sekcja GIT URL poniżej) lub nazwę pilota (patrz sekcja Poniższa Poniższa).

Określa, które sędzie. Kiedy w wierszu poleceń nie pojawiają się nie..Zamiast tego zmienne pobierające (patrz sekcja „Skonfigurowane gałęzie zdalnego śledzenia” w Git-Fetch [1]).

Format parametru jest opcjonalnym plus +, a następnie źródłem, a następnie dwukropek:, a następnie ref dla docelowego . Okrężnicy można pominąć, kiedy jest pusta. Zazwyczaj jest ref, ale może być również w pełni napisana nazwa obiektu sześciokątnego.

A może zawierać * w IT, aby wskazać prosty dopasowanie wzoru. Taka refspec funkcjonuje jak glob, który pasuje do dowolnego sędziego z tym samym prefiksem. Wzór musi mieć * w i . Będzie mapować ref one do miejsca docelowego, zastępując * zawartością dopasowaną ze źródła.

Jeśli refspec jest poprzedzony przez ^, zostanie interpretowany jako negatywny refspec. Zamiast określać, które sędzie. Ref zostanie uznany za pasuje, jeśli będzie pasował do co najmniej jednego pozytywnego refspec i nie pasuje do żadnego negatywnego refspec. Negatywne refspecs mogą być przydatne do ograniczenia zakresu wzoru refspec, aby nie zawierały określonych ref. Negatywne refspecs mogą same być wzorcami. Mogą jednak zawierać tylko a . W pełni napisane nazwy obiektów sześciokątnych również nie są obsługiwane.

Tag oznacza to samo co refs/tags/: refs/tags/; prosi o przyniesienie wszystkiego do danego tagu.

Zdalny sędzia, który pasuje, jest pobierany, a jeśli nie jest pustym ciągiem, podejmuje się próba aktualizacji lokalnego sędziego, który go pasuje.

To, czy ta aktualizacja jest dozwolona bez -Force, zależy od przestrzeni nazw SHE’jest pobierany, rodzaj obiektu pobieranego i czy aktualizacja jest uważana za szybkie do przodu. Zasadniczo te same zasady mają zastosowanie do pobierania, jak podczas pchania, zobacz . Część Git-Push [1] za to, czym one są. Wyjątki od tych zasad szczególnych Git Fetch są zauważone poniżej.

Do wersji 2 GIT.20, i w przeciwieństwie do pchania za pomocą git-push [1], wszelkie aktualizacje refs/tagów/* zostaną zaakceptowane bez + w refspec (lub-force). Podczas pobierania, rozważnie rozważaliśmy wszystkie aktualizacje tagów z pilota, które są wymuszone. Od wersji 2 GIT.. I.mi. Wszelkie aktualizacje zostaną odrzucone bez + w refspec (lub -force).

W przeciwieństwie do pchania z git-push [1], wszelkie aktualizacje poza refs //* zostaną zaakceptowane bez + w refspec (lub-force), czy to’S Zmienanie e.G. obiekt drzewa dla kropki lub zobowiązania za kolejne zobowiązanie’S’T mieć poprzednie zatwierdzenie jako przodek itp.

W przeciwieństwie do pchania z git-push [1], nie ma konfiguracji, która’LL zmienia te zasady i nie ma nic takiego jak hak wstępny analogiczny do haka wstępnego.

Podobnie jak w przypadku pchania za pomocą git-push [1], wszystkie reguły opisane powyżej o tym, co’S niedozwolone jako aktualizacja można zastąpić, dodając opcjonalne prowadzenie + do refspec (lub używając opcji wiersza poleceń -Force). Jedynym wyjątkiem jest to, że żadna ilość wymuszania nie spowoduje, że przestrzeń nazw Refs/Heads/*.

Git Pull wyjaśnił

Git Pull to polecenie GIT używane do aktualizacji lokalnej wersji repozytorium z pilota.

Jest to jedno z czterech poleceń, które montują interakcję sieciową przez GIT. Domyślnie Git Pull robi dwie rzeczy.

1. Aktualizuje bieżący lokalny oddział roboczy (obecnie sprawdzony oddział)
2. Aktualizuje gałęzie zdalnego śledzenia dla wszystkich innych gałęzi.

Git Pull Fetches (Git Fetch) Nowe zatwierdzenia i łączy (git łączy) je w lokalnym oddziale.

To polecenie’Składnia S jest następująca:

# Ogólny format git opcje Pull Repository Refspec # wyciągnij z określonej gałęzi git Pull zdalny nazwa-nazwa oddziału

• Opcje to opcje poleceń, takie jak -Quiet lub -serwis . Możesz przeczytać więcej o różnych opcjach w dokumentacji GIT
• MAGAZYN jest adresem URL do twojego repozytorium. Przykład: https: // github.com/freecodecamp/freecodecamp.git
• Refspec Określa, które sędzie
• Zdalny nazwa to nazwa Twojego zdalnego repozytorium. Na przykład: pochodzenie.
• NAZWA FILII to nazwa twojej gałęzi. Na przykład: rozwijać.

Notatka

Jeśli masz niezaangażowane zmiany, część scalania polecenia git pull nie powiedzie.

Tak więc powinieneś zawsze popełniaj zmiany w gałęzi przed pociągnięciem Nowe zatwierdzenia z zdalnego repozytorium.

Spis treści

• Za pomocą git ciągnięcia
• Kontrola wersji rozproszonej
• git fetch + git scal
• git wciągnij ides

Za pomocą git ciągnięcia

Użyj git Pull, aby zaktualizować lokalne repozytorium z odpowiedniego zdalnego repozytorium. Np.: Pracując lokalnie na Master, wykonaj Git Pull, aby zaktualizować lokalną kopię Master i zaktualizować inne oddziały zdalne śledzenia. (Więcej informacji na temat gałęzi zdalnego śledzenia w następnej sekcji.)

Ale jest kilka rzeczy, o których należy pamiętać, aby ten przykład był prawdziwy:

Lokalne repozytorium ma połączone zdalne repozytorium

• Sprawdź to, wykonując git zdalny -v
• Jeśli istnieje wiele pilotów, Git Pull może nie mieć wystarczającej ilości informacji. Może być konieczne wejście do git ciągnących lub git naciągnięcia w górę .

Oddział, do którego aktualnie się sprawdzasz

• Sprawdź to, wykonując status GIT . Jeśli nie ma gałęzi zdalnego śledzenia, Git nie’Nie wiem, gdzie wyciągnąć informacje z.

Kontrola wersji rozproszonej

Git jest System sterowania wersją rozproszoną (DVC). Dzięki DVC programiści mogą jednocześnie pracować nad tym samym plikiem w osobnych środowiskach. Po popychanie Kod do wspólnego zdalnego repozytorium, inni programiści mogą ciągnąć Zmieniony kod.

Interakcje sieciowe w Git

Istnieją tylko cztery polecenia, które montują interakcje sieciowe w GIT. Lokalne repozytorium nie ma świadomości na temat zmian w zdalnym repozytorium, dopóki nie pojawi się żądanie informacji. I zdalne repozytorium nie ma świadomości na temat zmian lokalnych, dopóki nie zostaną popchnięte.

Cztery polecenia sieciowe to:

• Git Clone
• Git Fetch
• git ciągnie
• Git Push

Gałęzie w DVC

Podczas pracy z Git może się wydawać, że istnieje wiele kopii tego samego kodu, które unoszą się w całym miejscu. Istnieją różne wersje tego samego pliku na każdej gałęzi. Oraz różne kopie tych samych oddziałów na każdym programistie’S komputer i na pilocie. Aby to śledzić, Git używa czegoś, co nazywa się Zdalne śledzenie gałęzi.

Jeśli wykonasz gałęznę GIT -wszystko w ramach repozytorium GIT, gałęzie zdalnego śledzenia pojawiają się na czerwono. Są to kopie kodu tylko do odczytu, ponieważ pojawia się na pilocie. (Kiedy była ostatnia interakcja sieciowa, która przyniosłaby informacje lokalnie? Pamiętaj, kiedy te informacje zostały ostatnio aktualizowane. Informacje w gałęzi zdalnego śledzenia odzwierciedlają informacje z tej interakcji.)

Z Zdalne śledzenie gałęzi, Możesz pracować w git na kilku oddziałach bez interakcji sieciowych. Za każdym razem, gdy wykonujesz polecenia GIT Pull lub Git Fetch, aktualizujesz Zdalne śledzenie gałęzi.

git fetch plus git scal

Git Pull to polecenie kombinacji, równe git fetch + git scal .

Git Fetch

Same, Git Fetch aktualizuje wszystkie oddziały zdalne śledzenia w lokalnym repozytorium. Żadne zmiany nie są w rzeczywistości odzwierciedlone na żadnej z lokalnych gałęzi roboczych.

Git Scal

Bez żadnych argumentów Git Scal połączy odpowiednią gałęzie zdalnego śledzenia do lokalnego oddziału roboczego.

git ciągnie

Git Fetch aktualizuje gałęzie zdalnego śledzenia. Git Scal Aktualizuje bieżącą gałąź z odpowiedniej gałęzi zdalnego śledzenia. Korzystając z gita, otrzymujesz obie części tych aktualizacji. Oznacza to jednak, że jeśli zostaniesz sprawdzony, aby Feature Branch i wykonujesz git Pull, podczas kasy do mistrza, wszelkie nowe aktualizacje nie zostaną uwzględnione. Za każdym razem, gdy sprawdzasz się do innej gałęzi, która może mieć nowe zmiany, to’zawsze dobrym pomysłem, aby wykonać git ciągnięcia .

git wciągnij ides

Wspólny język w innych IDE może nie zawierać słowa Pull . Jeśli szukasz słów git ciągnie się, ale don’T zobacz, zamiast tego poszukaj słowa synchronizacja.

Pobieranie zdalnego PR (żądanie Pull) do lokalnego repozytorium

W celu przeglądu i tym podobnych PR w pilocie należy pobrać do lokalnego repozytorium. Możesz użyć polecenia git fetch w następujący sposób, aby to osiągnąć.

Git Fetch Origin Pull/ID/Head: BranchName

Identyfikator to identyfikator żądania Pull, a BranchName to nazwa oddziału, którą chcesz utworzyć. Po utworzeniu gałęzi możesz użyć git kasu, aby przejść do tego brachu.

Inne zasoby na git, które możesz polubił:

• Git Scal i Git Rebase
• Git Checkout
• Git zatwierdzić
• Git Stash
• GIT Branch

Jak pociągnąć wszystkie gałęzie w git

Git to system kontroli wersji, który pozwala użytkownikom utrzymywać wiele linii programistycznych, i.mi., oddziały w jednym projekcie. Kiedy zaczynasz pracować nad projektem i chcesz sklonować repozytorium do komputera lokalnego, Git pozwala jednocześnie odzyskać poszczególne gałęzie lub wszystkie zdalne gałęzie.

W tym samouczku nauczysz się, jak ciągnąć wszystkie gałęzie w Git.

• Git zainstalowany (patrz, jak zainstalować git na Ubuntu, macOS, Windows, Centos 7 lub Centos 8).
• Repozytorium Git.

Ciągnięcie wszystkich gałęzi w Git

Gałęzie git można przechowywać w zdalnym lub lokalnym repozytorium. Kiedy chcesz pracować nad funkcją z oddziału przechowywanego w zdalnym repozytorium, musisz najpierw pobrać go do lokalnego repozytorium.

Dwa polecenia GIT używane do pobierania treści z zdalnego repozytorium są git ciągnących i Git Fetch :

• Git Fetch jest bezpieczniejszą wersją git ciągnie . Pobiera zdalną treść bez aktualizacji stanu roboczego lokalnego repozytorium, co oznacza, że ​​Twoja praca pozostaje nienaruszona.
• git ciągnie jest bardziej agresywny, ponieważ pobiera treść z zdalnego repozytorium i wykonuje git scal się w lokalnej aktywnej gałęzi. Scal tworzy nowe zatwierdzenie scalania i integruje treść z Twoją pracą. Jednak scalanie takiej treści może powodować konflikty z pracą w toku i może wymagać ręcznego rozwiązania.

Poniższe sekcje pokazują, jak przyciągnąć wszystkie gałęzie git do lokalnego repozytorium za pomocą dwóch poleceń.

Metoda git fetch

Z Git Fetch , Możesz pobrać metadane z zdalnego repozytorium bez wpływu na pracę lokalną. Jest to przydatna opcja, gdy chcesz sprawdzić, czy inny programista wprowadził jakiekolwiek zmiany w zdalnym repozytorium. Git Fetch jest również używany podczas klonowania repozytorium i pobierania danych na komputer lokalny.

Git Fetch Polecenie pobiera najnowsze aktualizacje z zdalnego repozytorium. W zależności od tego, czy chcesz pobrać metadane dla poszczególnych gałęzi, czy wszystkich gałęzi, polecenie ma następujące odmiany:

Git Fetch

• Dowódca pobiera tylko określoną gałąź z zdalnego repozytorium.

Git Fetch -All

• Polecenie jest uważane za ruch mocy, ponieważ pobiera wszystkie zarejestrowane piloty i ich gałęzie.

W tym samouczku sklonujemy nowe repozytorium i pobramy wszystkie powiązane gałęzie. Wykonaj poniższe kroki:

1. Otwórz wiersz polecenia git bash w systemie Windows lub otwórz nowe okno terminala w Linux (klawisz kontrolny+Alt+T) lub macOS.

2. Przejdź do katalogu, w którym chcesz przechowywać pliki repozytorium. Użyj polecenia CD, aby zmienić katalog.

3. Na GitHub zlokalizuj zdalne repozytorium, które chcesz sklonować i kliknij <> Kod przycisk. Na przykład sklonujemy repozytorium programu programistycznego programistycznego programu API Feenixnap. BMC Github Actions Platform umożliwia automatyzację zadań w repozytorium GIT.

4. Z menu rozwijanego wybierz opcję bezpieczeństwa, której chcesz użyć dla git i Skopiuj adres URL. W tym samouczku użyjemy HTTPS, ponieważ jest to najłatwiejsze do skonfigurowania. Jeśli chcesz bezpieczniejszą opcję, idź z SSH.

5. W Git Bash klon zdalne repozytorium za pomocą Git Clone polecenie i skopiowałeś adres URL. Składnia to:

Git Clone

6. Po klonowaniu repozytorium sprawdź oddziały dostępne w lokalnych i zdalnych repozytoriach. Aby sprawdzić lokalne oddziały, uruchom:

GIT Branch

Sprawdź zdalnie dostępne oddziały, uruchamiając:

git gałąź -r

Tylko rozwijać Oddział jest dostępny w lokalnym repozytorium, co oznacza, że ​​musimy pobrać pozostałe.

7. Pobierz metadane dla zdalnych gałęzi i zacznij je śledzić. Uruchomić:

Git Fetch -All

–Wszystko Flaga każe Gitowi pobrać metadane dla wszystkich gałęzi w repozytorium.

8. Po pobraniu metadanych zacznij śledzić gałęzie za pomocą tego polecenia:

Git Branch -r | grep -v '\ ->' | sed "s, \ x1b \ [[0-9;]*[a-za-z] ,, g" | Czytając zdalne; do git oddział -„$” „$ remote”; zrobione

Polecenie konfiguruje gałęzie w lokalnym repozytorium i sprawia, że ​​śledzą ich odpowiedniki w zdalnym repozytorium.

Uruchomić GIT Branch Ponownie i sprawdź, czy gałęzie istnieją lokalnie:

W powyższym przykładzie widzimy, że wszystkie gałęzie z zdalnego repozytorium istnieją teraz również w lokalnym.

Notatka: Przeczytaj nasze porównanie SSH i HTTPS dla git.

Git Pull Method

git ciągnie Metoda jest kombinacją Git Fetch I Git Scal . Polecenie pobiera metadane oddziału ze zdalnego repozytorium i aktualizuje lokalną kopię roboczą, aby odzwierciedlić zmiany.

Notatka: git ciągnie Metoda najlepiej działa w istniejącym repozytorium, w którym chcesz, aby zmiany zaimplementowane przez innych programistów zastanawiają się w lokalnym repozytorium. Klonowanie repozytorium, a następnie uruchomienie git ciągnie nie przyniosłoby żadnego rezultatu, ponieważ wszystko jest już aktualne.

Postępuj zgodnie z poniższymi krokami, aby pociągnąć wszystkie zdalne gałęzie:

1. Otwórz okno Git Bash i zmień lokalizację na lokalne repozytorium.

2. Uruchom następujące polecenie, aby upewnić się, że Git zaczyna śledzić wszystkie zdalne oddziały, w tym te, które nie istnieją w lokalnej kopii:

Git Branch -r | grep -v '\ ->' | sed "s, \ x1b \ [[0-9;]*[a-za-z] ,, g" | Czytając zdalne; do git oddział -„$” „$ remote”; zrobione

7. Wyciągnij wszystkie gałęzie ze zdalnego repozytorium GIT:

Git Pull -wszystko

Wyjście pokazuje, że wszystkie zdalne gałęzie zostały pomyślnie wyciągnięte i wyświetla zmiany.

Ten samouczek pokazał, jak wyciągnąć wszystkie gałęzie z zdalnego repozytorium do lokalnej kopii roboczej. Dostępne są dwie metody – Git Fetch I git ciągnie , każdy odpowiedni do własnego przypadku użycia.

Dowiedz się więcej o GIT w naszym przewodniku Git dla początkujących lub pobierz poręczne ściąganie poleceń git i zapisz go do użytku w przyszłości.

Git: pociągnij wszystkie gałęzie

Git pozwala zachować wiele osobnych linii rozwoju dla projektu. Te linie rozwoju nazywane są gałęziami. Możesz odzyskać najnowszą wersję oddziału ze zdalnego repozytorium niezależnie lub możesz pobrać najnowszą wersję wszystkich oddziałów jednocześnie.

W tym przewodniku mówimy o tym, jak używać git fetch – wszystko i git pull – wszystko, aby odzyskać zmiany ze zdalnego repozytorium.

Co się rozgałęzi?

Pozwalać&rsquo;s, powiedzmy, że pracujemy na stronie blogu. My&rsquo;Zamierzam dodać funkcję do bloga, która pozwala użytkownikom komentować. Don&rsquo;T nie chcę, aby ta funkcja była częścią głównej wersji naszego projektu, ponieważ nadal nad nią pracujemy.

Znajdź dopasowanie bootcamp

• Kariera karma pasuje do ciebie z najlepszymi bootcampami technologicznymi
• Uzyskaj dostęp do ekskluzywnych stypendiów i kursów przygotowawczych

Wybierz swoje zainteresowanie
Imię

Nazwisko

E-mail

Kontynuując, zgadzasz się na nasze Warunki Polityki usług i prywatności, a wyrażasz zgodę na otrzymywanie ofert i możliwości od kariery kariery telefonicznej, wiadomości tekstowych i e -maila.

Możemy do tego użyć gałęzi git. Możemy utworzyć gałąź o nazwie &ldquo;uwagi&rdquo; Aby przechowywać cały kod dla naszej funkcji komentowania. Pozwoli nam to pracować nad naszą funkcją komentowania bez zmiany głównej wersji naszej bazy kodowej, która jest wdrażana na stronie internetowej.

Oddziały mogą być przechowywane lokalnie lub zdalnie. Jeśli pracujesz nad lokalną wersją projektu, oddział będzie lokalny. Zdalne oddziały są przechowywane w głównej wersji projektu.

Git: Pobieraj wszystkie gałęzie

My&rsquo;Ponowna praca nad projektem o nazwie Blog Site. Ten projekt zawiera dwie oddziały: Origin Master i Origin Dev.

Oddział Dev zawiera wszystkie eksperymentalne funkcje, z którymi pracujemy. Uważamy, że inny współpracownik popchnął zmiany w obu oddziałach. Chcemy upewnić się i odzyskać metadane dla wszelkich zmian, jeśli zostały wprowadzone.

Możemy to zrobić za pomocą polecenia Fetch. Polecenie Fetch każe Gitowi odzyskać metadane ze zdalnej gałęzi w najnowszych aktualizacjach. Polecenie Fetch nie aktualizuje plików przechowywanych w lokalnej wersji repozytorium.

Aby śledzić wszystkie zdalne gałęzie i pobierać metadane dla tych gałęzi, możemy użyć polecenia Git Fetch z flagą –

To polecenie powraca:

Pobieranie Pochodzenia zdalne: Obiekty wyliczające: 5, gotowe. Pilot: Liczenie obiekty: 100% (5/5), gotowe. Remot: Ogółem 3 (Delta 0), ponownie użyty 0 (Delta 0), wciągnięta w pakiet 0 obiektów rozpakowywania: 100% (3/3), gotowe. Z https: // github.com/kariera-karma-samorial/blog 3fcea0c..DA74D68 Dev -> Origin/Dev

Polecenie Fetch przyniosło wszystkie zmiany&rsquo;Wykonane do naszego zdalnego repozytorium. Polecenie Fetch wie, że nasz zdalny oddział dev zawiera zmiany, których nie mamy na naszym komputerze lokalnym. Właśnie odzyskaliśmy metadane dla tych zobowiązań.

Możemy odzyskać metadane dla poszczególnych gałęzi za pomocą polecenia Git Fetch Origin.

Git: pociągnij wszystkie gałęzie

Co jeśli chcesz zaktualizować lokalną kopię roboczą, a także odzyskać metadane? To&rsquo;s, gdzie przydaje się komenda git pull.

&bdquo;Kariera karma weszła w moje życie, kiedy najbardziej jej potrzebowałem i szybko pomogła mi dopasować się do bootcamp. Dwa miesiące po ukończeniu studiów znalazłem swoją wymarzoną pracę, która dostosowała się do moich wartości i celów w życiu!”

Wenus, inżynier oprogramowania w Rockbot

Znajdź dopasowanie bootcamp

Wiemy teraz, że zmiany zostały wprowadzone w naszym repozytorium. Jesteśmy zadowoleni z połączenia tych zmian z naszym lokalnym repozytorium. Aby pobrać zmiany na naszym komputerze lokalnym, musimy użyć polecenia GIT Pull:

My&rsquo;użył flagi – call, aby wskazać, że chcemy odzyskać zmiany z każdej gałęzi. Nasze polecenie powraca:

Pobieranie Pochodzenia zdalne: Obiekty wyliczające: 5, gotowe. Pilot: Liczenie obiekty: 100% (5/5), gotowe. Remot: Ogółem 3 (Delta 0), ponownie użyty 0 (Delta 0), wciągnięta w pakiet 0 obiektów rozpakowywania: 100% (3/3), gotowe. Z https: // github.com/kariera-karma-samorial/blog 3fcea0c..DA74D68 Dev -> Origin/Dev Aktualizacja 3fcea0c..DA74D68 Szybkie readme.MD | 1 + 1 Zmieniony plik, 1 wstawienie ( +)

Polecenie Git Pull najpierw uruchamia polecenie git fetch, aby sprawdzić zmiany. Operacja pobierania zwraca metadane dla naszych zobowiązań . Następnie polecenie Git Pull pobiera wszystkie zmiany, które wprowadziliśmy w naszym zdalnym repozytorium i zmienia nasze pliki lokalne.

Widzimy Readme.plik MD został zmieniony w naszym zdalnym repozytorium. Teraz, kiedy my&rsquo;uruchomić operację ciągnięcia, mamy zmianę na naszym komputerze lokalnym.

Aby pobrać kod z jednej gałęzi, moglibyśmy użyć polecenia GIT Pull Origin.

Wniosek

Git Fetch – Wszystkie polecenie pobiera metadane na każdej zmianie dokonanej na wszystkie gałęzie w repozytorium. Polecenie git pull – wszystko pobiera wszystkie zmiany wprowadzone we wszystkich gałęziach na komputerze lokalnym.
Teraz masz wiedzę, którą potrzebujesz, aby wyciągnąć wszystkie gałęzie z git jak profesjonalista !

O nas: Career Karma to platforma zaprojektowana, aby pomóc osobom poszukującym pracy w znalezieniu, badaniu i kontaktach z programami szkolenia zawodowego w celu rozwinięcia kariery. Dowiedz się o publikacji CK.

Co dalej?

James Gallagher

O autorze: James Gallagher jest programistą samoukiem i kierownikiem ds. Treści technicznej w karierze karmiki. Ma doświadczenie w zakresie języków programowania i obszernej wiedzy specjalistycznej w zakresie Python, HTML, CSS i JavaScript. James napisał setki samouczków programowania i często przyczynia się do publikacji takich jak Codecademy, Treehouse, Repl.to, afrotech i inni.

Powiązane artykuły

• Git ciągnie
• Błąd: nie udało się popchnąć niektórych remontów do pilota
• Git: list zdalnych gałęzi
• Cofnij się git: przewodnik
• Git: pociągnij wszystkie gałęzie

• Git zresetuj na ratunek
• Git Pull Request: Jak utworzyć żądanie ciągnięcia
• Git Fetch: przewodnik krok po kroku
• Git Cherry Pick: przewodnik krok po kroku