Git 2.6+ (wydany 28 września 2015 r.)
Plik tylko git config
ustawienie, które mogłoby być interesujące, to:
rebase.autoStash
(z Git 2.27, Q2 2020, masz teraz również merge.autostash
, patrz poniżej)
Gdy ma wartość true, automatycznie tworzy tymczasowy magazyn przed rozpoczęciem operacji i stosuje go po zakończeniu operacji.
Oznacza to, że możesz uruchomić rebase na brudnym drzewie roboczym.
Należy jednak zachować ostrożność: ostatnia aplikacja skrytki po pomyślnym ponownym uruchomieniu może spowodować nietrywialne konflikty. Domyślnie false.
połącz to z:
pull.rebase
Gdy prawda, rebase rozgałęzia się na górze pobranej gałęzi, zamiast scalać domyślną gałąź z domyślnego pilota po uruchomieniu „git pull”.
git config pull.rebase true
git config rebase.autoStash true
To wystarczyłoby, aby prosty git pull
do pracy nawet na brudnym drzewie.
W takim przypadku alias nie jest potrzebny.
Zobacz commit 53c76dc (04 lipca 2015) autorstwa Kevina Daudta ( Ikke
) .
(Scalone przez Junio C Hamano - gitster
- w zatwierdzeniu e69b408 , 17 sierpnia 2015)
pull
: zezwala na brudne drzewo, gdy jest rebase.autostash
włączone
rebase nauczył się ukrywać zmiany, gdy napotka brudne drzewo pracy, ale git pull --rebase
tego nie robi.
Sprawdź tylko, czy drzewo robocze jest brudne, gdy rebase.autostash
nie jest włączone.
Uwaga: jeśli chcesz pobierać bez autostashu (nawet jeśli rebase.autoStash true
jest ustawiony), masz od wersji 2.9 (czerwiec 2016):
pull --rebase --no-autostash
Zobacz commit 450dd1d , commit 1662297 , commit 44a59ff , commit 5c82bcd , commit 6ddc97c , commit eff960b , commit efa195d (02 kwietnia 2016) i commit f66398e , commit c48d73b (21 marca 2016) przez Mehul Jain ( mehul2029
) .
(Scalone przez Junio C Hamano - gitster
- w zatwierdzeniu 7c137bb , 13 kwietnia 2016 r.)
Commit f66398e obejmuje w szczególności:
pull --rebase
: dodaj --[no-]autostash
flagę
Jeśli rebase.autoStash
zmienna konfiguracyjna jest ustawiona, nie ma możliwości zastąpienia jej dla " git pull --rebase
" z wiersza poleceń.
Naucz " git pull --rebase
" --[no-]autostash
flagi linii poleceń, która zastępuje bieżącą wartość rebase.autoStash
, jeśli jest ustawiona. Ponieważ " git rebase
" rozumie tę --[no-]autostash
opcję, chodzi tylko o przekazanie opcji do bazowego " git rebase
" when " git pull --rebase
" wywołania.
Ostrzeżenie: przed Git 2.14 (Q3 2017), " git pull --rebase --autostash
" nie był automatycznie ukrywany, gdy lokalna historia jest szybko przesyłana do nadawcy.
Zobacz commit f15e7cf (01 czerwca 2017) autorstwa Tyler Brazier ( tylerbrazier
) .
(Scalone przez Junio C Hamano - gitster
- w zobowiązaniu 35898ea , 05 czerwca 2017 r.)
pull
: ff --rebase --autostash
działa w brudnym repozytorium
Kiedy git pull --rebase --autostash
w brudnym repozytorium nastąpiło szybkie przewijanie do przodu, nic nie było automatycznie zapisywane, a ściąganie nie powiodło się.
Wynikało to ze skrótu, aby uniknąć uruchamiania rebase, gdy możemy przewinąć do przodu, ale autostash jest ignorowany w tej ścieżce kodu.
Aktualizacja: Mariusz Pawelski zadaje w komentarzach ciekawe pytanie:
Więc wszyscy piszą o tym, autostash
kiedy dokonujesz rebase (lub pull --rebase
).
Ale nikt nie zajmuje się autostashingiem, gdy wykonujesz normalne ciągnięcie z połączeniami .
Więc nie ma do tego automatycznego przełącznika? Albo coś mi brakuje? Wolę to robić, git pull --rebase
ale OP zapytał o „ standardowe ” git pull
Odpowiedź:
Oryginalne nici omówieniem tej autostash funkcji był realizowany zarówno początkowo git pull
(scalanie) i git pull --rebase
.
Ale ... Junio C Hamano (opiekun Git) zauważył, że:
Gdyby pull-merge
było coś, co wywołałoby "irytację", która wywołała ten temat, z definicji lokalna zmiana nakłada się na scalanie, a to wewnętrzne "wyskakujące okienko" dotknie ścieżek dotkniętych przez scalanie i prawdopodobnie nie spowoduje to "Porzucono „ale pozostawić dalsze konflikty do rozwiązania.
Podejrzewam, że pull.autostash
konfiguracja nie jest dobrym dodatkiem, ponieważ zachęca do złego, powodującego ból przepływu pracy.
W prostych przypadkach może to nie zaszkodzić, ale gdy lokalne zmiany są złożone, byłoby to bardziej szkodliwe niż ich brak, a konfiguracja pozbawia motywację do wyboru.
Równanie jest nieco inne dla „pull-rebase”, ponieważ „rebase” nalega na rozpoczęcie od czystego drzewa roboczego, więc irytacja „pobierz i zatrzymaj” wydaje się większa. Podejrzewam, że poluzowanie może być bardziej produktywnym rozwiązaniem prawdziwego problemu.
Tak więc, jeśli chodzi o klasyczne łączenie pull-merge, lepiej:
zachęć użytkownika do przemyślenia natury WIP w drzewie roboczym przed uruchomieniem " git pull
" .
Czy jest to zbyt złożona bestia, która może przeszkadzać innym, czy też jest to trywialna zmiana, którą może schować i odłożyć z powrotem?
Jeśli to pierwsze, dużo lepiej będzie dla niego " checkout -b
", kontynuuj pracę, aż lokalna zmiana przyjmie nieco lepszy kształt i "zatwierdź", zanim przejdzie do oryginalnej gałęzi.
Jeśli to drugie, lepiej zrobić:
- „
git pull
”,
- po znalezieniu konfliktu, biegnij
git stash
,
git merge FETCH_HEAD
i
git stash pop
To powiedziawszy, z Git 2.27 (Q2 2020), " git pull
" nauczył się ostrzegać, gdy żadna pull.rebase
konfiguracja nie istnieje i ani --[no-]rebase
nie --ff-only
jest podana (co spowodowałoby scalenie).
Zobacz commit d18c950 (10 marca 2020) autorstwa Alexa Henrie ( alexhenrie
) .
(Scalone przez Junio C Hamano - gitster
- w zatwierdzeniu 1c56d6f , 27 marca 2020 r.)
pull
: ostrzeż, jeśli użytkownik nie powiedział, czy zmienić bazę, czy scalić
Podpisał: Alex Henrie
Często początkujący użytkownicy Gita zapominają powiedzieć „ pull --rebase
” i kończą się niepotrzebnym łączeniem ze źródłami.
Zwykle chcą " pull --rebase
" albo " " w prostszych przypadkach, albo " pull --ff-only
" zaktualizować kopię głównych gałęzi integracji i oddzielnie odtworzyć ich pracę. Zmienna konfiguracja istnieje, aby pomóc im w prostszych przypadkach, ale nie ma mechanizmu, aby ci użytkownicy świadomi.
pull.rebase
Wyświetla komunikat ostrzegawczy, gdy nie ma --[no-]rebase
opcji z wiersza poleceń i nie pull.rebase
podano zmiennej konfiguracyjnej.
Będzie to niewygodne dla tych, którzy nigdy nie chcą " pull --rebase
" robić nic specjalnego, ale koszt niedogodności jest płacony tylko raz na użytkownika, co powinno być rozsądnym kosztem, aby pomóc wielu nowym użytkownikom.
W Git 2.27 (Q2 2020) " git merge
" uczy się --autostash
opcji " " i nowych merge.autostash
ustawień.
Zobacz popełnić d9f15d3 , popełnić f8a1785 , popełnić a03b555 , popełnić 804fe31 , popełnić 12b6e13 , popełnić 0dd562e , popełnić 0816f1d , popełnić 9bb3dea , popełnić 4d4bc15 , popełnić b309a97 , popełnić f213f06 , popełnić 86ed00a , popełnić facca7f , popełnić be1bb60 , popełnić efcf6cf , popełnić c20de8b , zobowiązać bfa50c2 , commit 3442c3d , commit 5b2f6d9 (07 kwietnia 2020), commit 65c425a(04 kwietnia 2020) i commit fd6852c , commit 805d9ea (21 Mar 2020) by Denton Liu ( Denton-L
) .
(Scalone przez Junio C Hamano - gitster
- w zobowiązaniu bf10200 , 29 kwietnia 2020 r.)
pull
: pass --autostash do scalenia
Podpisał: Denton Liu
Wcześniej --autostash
pracował tylko z git pull --rebase
.
Jednak w ostatnim patchu nauczyliśmy się --autostash
również scalania, więc nie ma powodu, dla którego mielibyśmy już mieć to ograniczenie.
Naucz pociągnij, aby przejść, --autostash
aby scalić, tak jak w przypadku rebase.
I:
rebase
: użyj apply_autostash()
z sequencer.c
Podpisał: Denton Liu
apply_autostash()
Funkcjonują w builtin/rebase.c
podobny tyle do apply_autostash()
funkcji w sequencer.c
które są one niemal wymienne, z wyjątkiem rodzaju arg akceptują. Utwórz sequencer.c
wersję extern i użyj jej w rebase.
Wersja rebase została wprowadzona w 6defce2b02 ("wbudowana rebase: --autostash
opcja wsparcia ", 2018-09-04, Git v2.20.0-rc0 - scalanie wymienione w partii nr 8 ) jako część konwersji powłoki na C.
Zdecydował się zduplikować tę funkcję, ponieważ w tamtym czasie istniał inny projekt konwertujący interaktywny rebase z powłoki na C i nie chcieli się z nimi kolidować poprzez refaktoryzację sequencer.c
wersji apply_autostash()
.
Ponieważ oba wysiłki są wykonywane od dawna, możemy je teraz dowolnie łączyć.