Większość integracji kodu dzieje się z merge, ale czasami programista chce, aby ich lokalny kod dogonił gałąź master za pomocą rebase. W tym przykładzie zademonstrujemy jak git rebase gałęzi do master zamiast używać polecenia merge, jednocześnie wskazując na wpływ wykonania operacji Git rebase do master.
co oznacza Git rebase to master?,
w tym tutorialu weźmiemy gałąź o nazwie develop i przerobimy ją na końcówkę master.
gałąź develop oderwała się od master w commicie C, więc obie gałęzie współdzielą pliki a.html, b.html oraz c.html. Aby to zwizualizować, zobacz poniższy obrazek.
od pojawienia się gałęzi master dodał commity D i E. Oznacza to, że master ma dwa pliki, których nie posiada develop, a mianowicie d.html oraz e.html.,
tak wygląda repozytorium Git przed zmianą bazy git na master.
ponadto, od czasu podziału, w gałęzi develop pojawiły się dwa nowe commity, dodając pliki f.html oraz g.html. Są to pliki, które posiada gałąź develop, a nie gałąź master.
tak wygląda repozytorium GitLab po zmianie bazy na master.,
wpływ rebase Git
Po udanym wdrożeniu gałęzi develop do master rebase:
- pliki w gałęzi master Nie ulegną zmianie
- gałąź develop dodatkowo zdobędzie wszystkie nowe pliki gałęzi master
- punkt gałęzi develop stream ulegnie zmianie.
- pojawi się tak, jakby gałąź develop została podzielona po zatwierdzeniu e na gałęzi master.
- przed rebase ' em gałąź develop oddzieliła się od master w commit C.,
składnia polecenia git rebase to master
operacja wykonania polecenia git rebase to master jest prosta. Wystarczy dopisać na końcu polecenia nazwę gałęzi źródłowej, a następnie nazwę gałęzi do rebase. Aby rebase rozwinąć do opanowania polecenie jest następujące:
git rebase master develop
Ostrzeżenie: istnieje rebase git na Switchu, który czasami deweloperzy błędnie uważają, że muszą dołączyć do polecenia rebase. Spowoduje to dyskowanie commitów i utratę plików., Nie popełniaj błędu podczas wykonywania rebase ' u git na operacji.
przed rebase ' em gałąź developerska miała tylko pięć plików.
każda gałąź ma pięć plików przed operacją Git rebase do master.
Po zmianie bazy Git na master, gałąź develop ma siedem plików. Zachowało wszystkie swoje oryginalne akta i pozyskało dwa nowe akta z końcówki gałęzi master., Jednak liczba plików w gałęzi master pozostaje bez zmian.
Po rebase Git develop do master, gałąź develop przejmuje wszystkie pliki master.
fakt, że gałąź master nie nabyła żadnych plików z gałęzi develop często wyrzuca nowych użytkowników Gita, ale jest to oczekiwane zachowanie. Git rebase nie synchronizuje się między gałęziami. Po prostu łapie jedną gałąź z najnowszymi zmianami z innej.,
liczba plików w rozwijaniu zwiększa się po zmianie bazy git na master.
zachowaj ostrożność
gdy nastąpi zmiana bazy Git, historia zmian w repozytorium zostanie nieodwracalnie zmieniona. Po zmianie bazy w naszym przykładzie, commity F I G są przypisywane nowiutkie identyfikatory commitów, a stare identyfikatory commitów są odrzucane. Z tego powodu często zobaczysz zmiany oznaczone jako F 'I G', aby podkreślić fakt, że nowe identyfikatory zmian zostały przypisane.,
jeśli przełączysz gałąź współdzieloną z innym deweloperem i przeniesiesz zmiany z powrotem na GitHub lub GitLab, inny programista będzie miał różne problemy podczas próby wciągnięcia repozytorium w swoje lokalne środowisko programistyczne. Commity, które mają lokalnie, znikną na zdalnej gałęzi, a zdalna gałąź będzie miała niezgodną historię gałęzi. Jak możesz sobie wyobrazić, zmiana współdzielonej gałęzi lub zgniatanie git commit może siać spustoszenie.,
Rebase do GitHub lub GitLab
w rzeczywistości, jeśli rebase i spróbować wcisnąć do GitLab lub GitHub, serwer nie pozwoli na wykonanie operacji. Aby zmienić wersję na GitHub lub GitLab, programista musi dodać –force switch do polecenia git push, aby zmusić zmiany do zaakceptowania.
git push origin --force
a GitLab or GitHub rebase naciśnięcie zostanie odrzucone, chyba że zostanie wymuszone.,
akceptowana logika to tylko git rebase do master branchs local to your personal workspace. W ten sposób Twoje polecenia git clean up nie mają wpływu na nikogo innego. Nie wykonuj rebase git do opanowania w gałęziach udostępnianych innym programistom. Rebase NA master jest w porządku, tylko nie na odwrót. W przeciwnym razie prawdopodobnie złamiesz kompilację, a operacje push lub pull zostaną uruchomione w trybie stand-by, utrudniając dalszy rozwój i sprawiając, że będziesz persona non grata z resztą programistów i zespołu DevOps.