git ściągnij z mistrza do działu rozwoju

494

Mam gałąź o nazwie dmgr2 (programowanie) i chcę pobrać z gałęzi master (strona na żywo) i uwzględnić wszystkie zmiany w mojej gałęzi programistycznej. czy jest na to lepszy sposób? oto, co planowałem zrobić po dokonaniu zmian:

git checkout dmgr2
git pull origin master

to powinno pociągnąć za sobą zmiany na żywo w mojej branży programistów, czy mam to źle?

git branch pull

— Matthew Colley
źródło

1

najpierw zatwierdź wszystkie zmiany w gałęzi dmgr2. a następnie wskaż polecenie master 1.git checkout master, a następnie pobierz najnowszą zmianę 2.git pull 3.git merge dmgr2 4.git push -u origin master A następnie wróć do swojego dmgr2 5.git checkout dmgr2

— mat_vee

wszystkie moje zmiany zostały już zatwierdzone w oddziale dmgr2, przepraszam, że zapomniałem dodać

— Matthew Colley,

1

jeśli wykonam krok 4, czy to nie spowoduje, że moje zmiany rozwojowe zostaną wprowadzone w trybie głównym? nie chcę tego robić

— Matthew Colley,

Więc chcesz powiedzieć, że chcesz wprowadzić zmiany z gałęzi master do gałęzi deweloperów?

— JcKelley,

9

Przejdź do devoddziału za pomocą git checkout dev. Potem git pull --rebase origin master. Jeśli będziesz miał szczęście, nie będzie konfliktów, a programista otrzyma najnowsze zmiany od mistrza.

— jww

724

Wymienione kroki będą działać, ale istnieje dłuższy sposób, który daje więcej opcji:

git checkout dmgr2      # gets you "on branch dmgr2"
git fetch origin        # gets you up to date with origin
git merge origin/master

fetchPolecenie może być wykonane w dowolnym momencie przed merge, czyli można zamienić kolejność fetch i kasa, bo fetchpo prostu podchodzi do wskazanego zdalnego ( origin) i mówi do niego: „daj mi wszystko, co masz, że nie mam ”, tzn. wszystkie zatwierdzenia we wszystkich oddziałach. Są one kopiowane do twojego repozytorium, ale nazwane origin/branchdla dowolnego oddziału wymienionego branchna pilocie.

W tym momencie możesz użyć dowolnej przeglądarki ( git log, gitkitp.), Aby zobaczyć „to, co mają”, czego nie masz, i odwrotnie. Czasami przydaje się to tylko w przypadku Ciepłych Rozmytych Uczuć („och, tak, to jest właśnie to, czego chcę”), a czasem przydaje się całkowicie do zmiany strategii („kurwa, jeszcze tego NIE chcę”).

Na koniec mergepolecenie przenosi dane zatwierdzenie, które można nazwać jako origin/master, i robi wszystko, co konieczne, aby wprowadzić to zatwierdzenie i jego przodków, do dowolnej gałęzi, na której się znajdujesz podczas uruchamiania merge. Możesz wstawić --no-fflub, --ff-onlyaby zapobiec szybkiemu przewijaniu do przodu, lub scalić tylko, jeśli wynik jest szybkim przewijaniem do przodu, jeśli chcesz.

Podczas korzystania z sekwencji:

git checkout dmgr2
git pull origin master

że pullprzesyła zlecenie polecenia git uruchomić git fetch, a następnie moralnym odpowiednikiem git merge origin/master. Jest to więc prawie to samo, co wykonanie dwóch kroków ręcznie, ale istnieją pewne subtelne różnice, które prawdopodobnie nie dotyczą ciebie zbytnio. (W szczególności fetchkrok po kroku pullprzynosi tylko origin/master i nie aktualizuje referencji w twoim repozytorium: ¹ wszelkie nowe zatwierdzenia kończą się odniesieniem tylko przez specjalne FETCH_HEADodniesienie).

Jeśli użyjesz bardziej wyraźnego git fetch origin(a następnie opcjonalnie rozejrzyj się), a następnie git merge origin/mastersekwencji, możesz również masterzaktualizować swój lokalny za pomocą pilota, z tylko jednym fetchuruchomieniem w sieci:

git fetch origin
git checkout master
git merge --ff-only origin/master
git checkout dmgr2
git merge --no-ff origin/master

na przykład.

¹ Druga część została zmieniona - mówię „naprawiona” - w git 1.8.4, która teraz aktualizuje oportunistycznie odniesienia do „zdalnej gałęzi”. (Była to, jak mówią informacje o wydaniu, celowa decyzja projektowa, aby pominąć aktualizację, ale okazuje się, że więcej osób woli, aby git ją aktualizował. Jeśli chcesz mieć stary SHA-1 ze zdalnej gałęzi, domyślnie jest zapisywany w , a tym samym możliwe do odzyskania po ponownym logowaniu. Umożliwia to także nową funkcję git 1.9 / 2.0 do znajdowania wcześniejszych wersji bazy).

— Trek
źródło

28

Proszę tylko o przyjaciela - jak byś cofnął pierwszy blok kodu, który masz tutaj (kasa / pobranie / scalenie)?

— Rich Bradshaw,

10

@RichBradshaw: git checkoutjest zwykle nieniszczący i zwykle nie ma powodu, aby cofać git fetch, więc wygląda na to, że pytasz, jak wycofać zatwierdzenie scalenia. Odpowiedź jest taka sama jak dla innych zatwierdzeń: albo git resetalbo git revert. W przypadku niepublikowanych zmian git resetjest zwykle najlepszą metodą; zmiany, które inni już wprowadzili, git revertmogą być lepsze, ale zobacz poradę Linusa

— Torvalda dotyczącą cofania

2

@WeDoTDD: Nie rozumiem pytania. Istnieje szereg poleceń do przeglądania commit wykres ( gitk, git log --graphz lub bez --oneline, i tak dalej) i można git showlub git show -mscalanie popełnić lub wykorzystanie git diff. We wszystkich tych przypadkach program podajesz, wpisując polecenie w wierszu polecenia.

— torek

1

@torek: wypróbowałem: git checkout branch, a następnie git pull origin master, ale ściągnął wszystkie zmiany master jako pojedynczą zmianę, którą należy ponownie zatwierdzić lokalnie, zamiast wyciągać je z ich historią zatwierdzania i wiadomościami, więc po aktualizacji lokalnej master i przełączanie do gałęzi, „git rebase master” wykonuje zadanie przy rozwiązywaniu wszystkich konfliktów, a następnie dodaję do „git pull --rebase” i obsługuję ponownie wszystkie konflikty, a następnie git push origin gałąź, aby wszystko wyrównać. Myślę, że powinien istnieć lepszy sposób - mam rację?

— user10556443

1

@torek: Zgadzam się, że otrzymany przeze mnie wynik jest męczący, co zmusza mnie do radzenia sobie z powtarzaniem bazy i łączenia i ... za każdym razem, gdy chcę uzyskać aktualizację od mistrza ... Ale proponowany sposób, który przyznaję, jest dużo łatwiej, wszystkie zmiany wprowadzono w ramach jednej niezatwierdzonej zmiany w oddziale lokalnym bez zachowania kolejności / historii zatwierdzeń głównych. Z przyjemnością nauczę się lepszych sugestii, jak używać „pobierania” i śledzić master, bez potrzeby używania „pull” itp.

— użytkownik10556443

14

Sytuacja : Pracuję w moim oddziale lokalnym, ale uwielbiam na bieżąco otrzymywać informacje o nazwie gałąź rozwoju dev.

Rozwiązanie : zazwyczaj wolę robić:

git fetch
git rebase origin/dev

— zieloność
źródło

15

Przy zwykłym zastrzeżeniu, że zmiana bazy powinna być wykonana tylko wtedy, gdy lokalny oddział jest tylko lokalny, to znaczy nie został nigdzie wypchnięty, ponieważ przepisuje historię.

— Locus

8

To zadziałało dla mnie. Za pobranie najnowszego kodu z master do mojego oddziału

git rebase origin/master

— Pratik Gaurav
źródło

Nie zapomnij git fetch originnajpierw.

— lenooh

3

Scenariusz :

Mam aktualizację master i aktualizację mojego oddziału, chcę, aby mój oddział śledził master z rebasingiem, aby właściwie śledzić całą historię, nazwijmy mój oddział Mybranch

Rozwiązanie :

git checkout master    
git pull --rebase    
git checkout Mybranch    
git rebase master
git push -f origin Mybranch

trzeba rozwiązać wszystkie konflikty z git Fibletool &, git rebase - continue, git rebase --skip, git add -u, zgodnie z sytuacją i podpowiedzi git, aż wszystko zostanie rozwiązane

(poprawka do ostatniego etapu, dzięki uprzejmości Tzachi Cohen, użycie „-f” zmusza gita do „aktualizacji historii” na serwerze)

teraz gałąź powinna być wyrównana z głównym i ponownie bazowana, również ze zdalną aktualizacją, więc w git log nie ma żadnych „za” ani „naprzód”, wystarczy usunąć wszystkie lokalne pliki konfliktu * .orig, aby utrzymać folder „czysty”

— użytkownik10556443
źródło