[ Pobierz całość w formacie PDF ]
.WGicie nazywa się to zmianą bazy (ang.rebase).Dzięki poleceniu rebase możesz wziąć wszystkie zmiany, które zostałyzatwierdzone w jednej gałęzi i zaaplikować je w innej.W tym wypadku, mógłbyś uruchomić następujące polecenie:$ git checkout experiment$ git rebase masterFirst, rewinding head to replay your work on top of it.Applying: added staged commandPolecenie to działa przesuwając się do ostatniego wspólnego przodka obu gałęzi (tej w której się znajdujesz oraz tej doktórej robisz zmianę bazy), pobierając różnice opisujące kolejne zmiany (ang.diffs) wprowadzane przez kolejne rewizje wgałęzi w której się znajdujesz, zapisując je w tymczasowych plikach, następnie resetuje bieżącą gałąz do tej samej rewizji doktórej wykonujesz operację zmiany bazy, po czym aplikuje po kolei zapisane zmiany.Ilustruje to rysunek 3-29. W tym momencie możesz wrócić do gałęzi master i scalić zmiany wykonując proste przesunięcie wskaznika (co przesuniewskaznik master na koniec) (rysunek 3-30).Teraz migawka wskazywana przez C3 jest dokładnie taka sama jak ta, na którą wskazuje C5 w przykładzie ze scalaniem.Nie ma różnicy w produkcie końcowym integracji.Zmiana bazy tworzy jednak czystszą historię.Jeśli przejrzysz historięgałęzi po operacji rebase, wygląda ona na liniową: wygląda jakby cała praca była wykonywana stopniowo, nawet jeślioryginalnie odbywała się równolegle.Warto korzystać z tej funkcji, by mieć pewność, że rewizje zaaplikują się w bezproblemowy sposób do zdalnej gałęzi - byćmoże w projekcie w którym próbujesz się udzielać, a którym nie zarządzasz.W takim wypadku będziesz wykonywał swojąpracę we własnej gałęzi, a następnie zmieniał jej bazę na origin/master, jak tylko będziesz gotowy do przesłania własnychpoprawek do głównego projektu.W ten sposób osoba utrzymująca projekt nie będzie musiała dodatkowo wykonywaćintegracji - jedynie prostolinijne scalenie lub czyste zastosowanie zmian.Zauważ, że migawka wskazywana przez wynikową rewizję bez względu na to, czy jest to ostatnia rewizja po zmianie bazylub ostatnia rewizja scalająca po operacji scalania, to taka sama migawka - różnica istnieje jedynie w historii.Zmiana bazynanosi zmiany z jednej linii pracy do innej w kolejności, w jakiej były one wprowadzane, w odróżnieniu od scalania, którebierze dwie końcówki i integruje je ze sobą.Ciekawsze operacje zmiany bazyPoleceniem rebase możesz także zastosować zmiany na innej gałęzi niż ta, której zmieniasz bazę.Dla przykładu - wezhistorię taką jak na rysunku 3-31.Utworzyłeś gałąz tematyczną (server), żeby dodać nowe funkcje do kodu serwerowego, poczym utworzyłeś rewizję.Następnie utworzyłeś gałąz, żeby wykonać zmiany w kliencie (client) i kilkukrotnie zatwierdziłeśzmiany.W końcu wróciłeś do gałęzi server i wykonałeś kilka kolejnych rewizji.Załóżmy, że zdecydowałeś się scalić zmiany w kliencie do kodu głównego, ale chcesz się jeszcze wstrzymać ze zmianamipo stronie serwera, dopóki nie zostaną one dokładniej przetestowane.Możesz wziąć zmiany w kodzie klienta, których nie maw kodzie serwera (C8 i C9) i zastosować je na gałęzi głównej używając opcji --onto polecenia git rebase:$ git rebase --onto master server clientOznacza to mniej więcej "Przełącz się do gałęzi klienta, określ zmiany wprowadzone od wspólnego przodka gałęzi client iserver, a następnie nanieś te zmiany na gałąz główną master.Jest to nieco skomplikowane, ale wynik (pokazany na rysunku 3- 32) całkiem niezły.Teraz możesz zwyczajnie przesunąć wskaznik gałęzi głównej do przodu (rysunek 3-33):$ git checkout master$ git merge clientPowiedzmy, że zdecydujesz się pobrać i scalić zmiany z gałęzi server.Możesz zmienić bazę gałęzi server na wskazywanąprzez master bez konieczności przełączania się do gałęzi server używając git rebase [gałąz bazowa] [gałąz tematyczna] - w ten sposóbzmiany z gałęzi server zostaną zaaplikowane do gałęzi bazowej master:$ git rebase master serverPolecenie odtwarza zmiany z gałęzi server na gałęzi master tak, jak pokazuje to rysunek 3-34.Następnie możesz przesunąć gałąz bazową (master):$ git checkout master$ git merge serverMożesz teraz usunąć gałęzie client i server, ponieważ cała praca jest już zintegrowana i więcej ich nie potrzebujeszpozostawiając historię w stanie takim, jaki obrazuje rysunek 3-35:$ git branch -d client$ git branch -d serverZagrożenia operacji zmiany bazy Błogosławieństwo, jakie daje możliwość zmiany bazy, ma swoją mroczną stronę.Można ją podsumować jednym zdaniem:Nie zmieniaj bazy rewizji, które wypchnąłeś już do publicznego repozytorium.Jeśli będziesz się stosował do tej reguły, wszystko będzie dobrze.W przeciwnym razie ludzie cię znienawidzą, a rodzina iprzyjaciele zaczną omijać szerokim łukiem [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl milosnikstop.keep.pl
.WGicie nazywa się to zmianą bazy (ang.rebase).Dzięki poleceniu rebase możesz wziąć wszystkie zmiany, które zostałyzatwierdzone w jednej gałęzi i zaaplikować je w innej.W tym wypadku, mógłbyś uruchomić następujące polecenie:$ git checkout experiment$ git rebase masterFirst, rewinding head to replay your work on top of it.Applying: added staged commandPolecenie to działa przesuwając się do ostatniego wspólnego przodka obu gałęzi (tej w której się znajdujesz oraz tej doktórej robisz zmianę bazy), pobierając różnice opisujące kolejne zmiany (ang.diffs) wprowadzane przez kolejne rewizje wgałęzi w której się znajdujesz, zapisując je w tymczasowych plikach, następnie resetuje bieżącą gałąz do tej samej rewizji doktórej wykonujesz operację zmiany bazy, po czym aplikuje po kolei zapisane zmiany.Ilustruje to rysunek 3-29. W tym momencie możesz wrócić do gałęzi master i scalić zmiany wykonując proste przesunięcie wskaznika (co przesuniewskaznik master na koniec) (rysunek 3-30).Teraz migawka wskazywana przez C3 jest dokładnie taka sama jak ta, na którą wskazuje C5 w przykładzie ze scalaniem.Nie ma różnicy w produkcie końcowym integracji.Zmiana bazy tworzy jednak czystszą historię.Jeśli przejrzysz historięgałęzi po operacji rebase, wygląda ona na liniową: wygląda jakby cała praca była wykonywana stopniowo, nawet jeślioryginalnie odbywała się równolegle.Warto korzystać z tej funkcji, by mieć pewność, że rewizje zaaplikują się w bezproblemowy sposób do zdalnej gałęzi - byćmoże w projekcie w którym próbujesz się udzielać, a którym nie zarządzasz.W takim wypadku będziesz wykonywał swojąpracę we własnej gałęzi, a następnie zmieniał jej bazę na origin/master, jak tylko będziesz gotowy do przesłania własnychpoprawek do głównego projektu.W ten sposób osoba utrzymująca projekt nie będzie musiała dodatkowo wykonywaćintegracji - jedynie prostolinijne scalenie lub czyste zastosowanie zmian.Zauważ, że migawka wskazywana przez wynikową rewizję bez względu na to, czy jest to ostatnia rewizja po zmianie bazylub ostatnia rewizja scalająca po operacji scalania, to taka sama migawka - różnica istnieje jedynie w historii.Zmiana bazynanosi zmiany z jednej linii pracy do innej w kolejności, w jakiej były one wprowadzane, w odróżnieniu od scalania, którebierze dwie końcówki i integruje je ze sobą.Ciekawsze operacje zmiany bazyPoleceniem rebase możesz także zastosować zmiany na innej gałęzi niż ta, której zmieniasz bazę.Dla przykładu - wezhistorię taką jak na rysunku 3-31.Utworzyłeś gałąz tematyczną (server), żeby dodać nowe funkcje do kodu serwerowego, poczym utworzyłeś rewizję.Następnie utworzyłeś gałąz, żeby wykonać zmiany w kliencie (client) i kilkukrotnie zatwierdziłeśzmiany.W końcu wróciłeś do gałęzi server i wykonałeś kilka kolejnych rewizji.Załóżmy, że zdecydowałeś się scalić zmiany w kliencie do kodu głównego, ale chcesz się jeszcze wstrzymać ze zmianamipo stronie serwera, dopóki nie zostaną one dokładniej przetestowane.Możesz wziąć zmiany w kodzie klienta, których nie maw kodzie serwera (C8 i C9) i zastosować je na gałęzi głównej używając opcji --onto polecenia git rebase:$ git rebase --onto master server clientOznacza to mniej więcej "Przełącz się do gałęzi klienta, określ zmiany wprowadzone od wspólnego przodka gałęzi client iserver, a następnie nanieś te zmiany na gałąz główną master.Jest to nieco skomplikowane, ale wynik (pokazany na rysunku 3- 32) całkiem niezły.Teraz możesz zwyczajnie przesunąć wskaznik gałęzi głównej do przodu (rysunek 3-33):$ git checkout master$ git merge clientPowiedzmy, że zdecydujesz się pobrać i scalić zmiany z gałęzi server.Możesz zmienić bazę gałęzi server na wskazywanąprzez master bez konieczności przełączania się do gałęzi server używając git rebase [gałąz bazowa] [gałąz tematyczna] - w ten sposóbzmiany z gałęzi server zostaną zaaplikowane do gałęzi bazowej master:$ git rebase master serverPolecenie odtwarza zmiany z gałęzi server na gałęzi master tak, jak pokazuje to rysunek 3-34.Następnie możesz przesunąć gałąz bazową (master):$ git checkout master$ git merge serverMożesz teraz usunąć gałęzie client i server, ponieważ cała praca jest już zintegrowana i więcej ich nie potrzebujeszpozostawiając historię w stanie takim, jaki obrazuje rysunek 3-35:$ git branch -d client$ git branch -d serverZagrożenia operacji zmiany bazy Błogosławieństwo, jakie daje możliwość zmiany bazy, ma swoją mroczną stronę.Można ją podsumować jednym zdaniem:Nie zmieniaj bazy rewizji, które wypchnąłeś już do publicznego repozytorium.Jeśli będziesz się stosował do tej reguły, wszystko będzie dobrze.W przeciwnym razie ludzie cię znienawidzą, a rodzina iprzyjaciele zaczną omijać szerokim łukiem [ Pobierz całość w formacie PDF ]