Żądanie ściągnięcia GitHub pokazujące zatwierdzenia, które są już w gałęzi docelowej

155

Próbuję przejrzeć żądanie ściągnięcia w GitHub do oddziału, który nie jest nadrzędny. Gałąź docelowa znajdowała się za masterem, a żądanie ściągnięcia pokazywało zatwierdzenia z mastera, więc połączyłem mastera i wysłałem go do GitHub, ale zatwierdzenia i różnice dla nich nadal pojawiają się w żądaniu ściągnięcia po odświeżeniu. Podwójnie sprawdziłem, czy gałąź na GitHubie ma zatwierdzenia z mastera. Dlaczego nadal pojawiają się w żądaniu ściągnięcia?

Sprawdziłem również lokalnie żądanie ściągnięcia i pokazuje tylko niezintegrowane zatwierdzenia.

lobati
źródło
Czy ma to wpływ na zachowanie łączenia PR?
Nathan Hinchey
Nie, tylko różnica na Githubie.
lobati
Czy ktoś wie, czy Gitlab z własnym hostingiem cierpi z tego samego powodu?
Jeff Welling,
4
Sugeruję, abyśmy wszyscy skontaktowali się z GitHub, aby wyrazić zainteresowanie zmianą tego zachowania ( support.github.com/contact ). Jeśli nie otrzymają od nas wiadomości, nie będą wiedzieć, jakie to ważne i tak będzie na zawsze.
steinybot

Odpowiedzi:

117

Wygląda na to, że pull request nie śledzi zmian w gałęzi docelowej (skontaktowałem się z pomocą techniczną GitHub i otrzymałem odpowiedź 18 listopada 2014 r., W której stwierdzono, że jest to zgodne z projektem).

Możesz jednak sprawić, by pokazywał zaktualizowane zmiany, wykonując następujące czynności:

http://githuburl/org/repo/compare/targetbranch...currentbranch

Wymienić githuburl, org, repo, targetbranch, i currentbranchw razie potrzeby.

Lub, jak wskazał hexsprite w swojej odpowiedzi, możesz również zmusić go do aktualizacji, klikając EditPR i tymczasowo zmieniając bazę na inną gałąź iz powrotem. Powoduje to ostrzeżenie:

Czy na pewno chcesz zmienić bazę?

Niektóre zatwierdzenia ze starej gałęzi podstawowej mogą zostać usunięte z osi czasu, a stare komentarze do recenzji mogą stać się nieaktualne.

I pozostawi dwa wpisy dziennika w PR:

wprowadź opis obrazu tutaj

Adam Millerchip
źródło
4
Tak, jakiś czas temu skontaktowałem się z obsługą i otrzymałem taką samą odpowiedź. Nie optymalizują się pod kątem tej sytuacji. To trochę frustrujące. Nasz sposób na obejście tego polega po prostu na zmianie bazy i wymuszeniu pchnięcia lub zamknięciu pociągnięcia i utworzeniu nowego.
lobati
5
Ta odpowiedź nie rozwiązuje problemu, ale po prostu pozwala użytkownikowi zobaczyć prawdziwą różnicę.
FearlessFuture
4
Pytanie brzmiało: „Dlaczego nadal pojawiają się w żądaniu ściągnięcia?”. Odpowiada na to pytanie.
Adam Millerchip
3
Sprawdź mój komentarz, aby uzyskać dobre obejście. Możesz po prostu użyć przycisku edycji PR, aby przełączyć się do innej gałęzi, a następnie z powrotem do oryginalnej gałęzi podstawowej i ponownie obliczy różnicę.
hexsprite
12
Czy istnieje prośba dear-github, aby to zmienić?
vossad01
102

Oto dobre obejście. Użyj Editprzycisku podczas przeglądania PR w GitHub, aby zmienić gałąź podstawową na coś innego niż master. Następnie przełącz go z powrotem na, mastera teraz poprawnie pokaże tylko zmiany z ostatnich zatwierdzeń.

hexsprite
źródło
4
Dziwię się, że więcej osób nie uznaje tego rozwiązania. Podejrzewam, że oryginalna nieaktualna prośba o ściągnięcie byłaby w porządku, ale nie podobało mi się, że GitHub pokazuje wszystkie nieaktualne pliki, więc użyłem tego i zarówno zachowuje komentarz, jak i pokazuje tylko rzeczywiste zmiany, które mają zostać scalone . Dzięki!
taranaki
Trzy lata później i nadal jest to świetne rozwiązanie. I spójrz, ktoś właśnie skomentował kilka godzin temu ^^^
Ricardo Saporta
5
Wydaje mi się, że to nie działa, po prostu dodaje informację, że zmieniłem gałąź podstawową na coś innego, a następnie z powrotem na master. cfr: github.com/europeana/search/pull/30
Calvin
40

Podsumowując, GitHub nie ponownie bazuje historii zatwierdzeń automatycznie w żądaniach ściągnięcia. Najprostsze rozwiązania to:

Rozwiązanie 1: Rebase

Załóżmy, że chcesz połączyć się masterz feature-01:

git fetch origin
git checkout feature-01
git rebase origin/master
git push --force

Jeśli pracujesz na widelcu, może być konieczne zastąpienie go originpowyżej upstream. Zobacz, jak zaktualizować repozytorium rozwidlone GitHub? aby dowiedzieć się więcej o śledzeniu zdalnych gałęzi oryginalnego repozytorium.

Rozwiązanie 2: Utwórz nowe żądanie ściągnięcia

Załóżmy, że chcesz scalić wprowadzenie masterz feature-01:

git checkout feature-01
git checkout -b feature-01-rebased
git push -u origin feature-01-rebased

Teraz otwórz żądanie ściągnięcia dla feature-01-rebasedi zamknij to dla feature-01.

Mateusz Piotrowski
źródło
4
Zmiana bazy zmienia skróty zatwierdzenia, więc czy w końcu spowoduje usunięcie istniejących komentarzy do recenzji?
haridsv
@haridsv Prawdopodobnie tak.
Mateusz Piotrowski
Na co należy uważać podczas wykonywania pchania - siły?
Paul Bendevis
1
@haridsv to nie moje doświadczenie. Często zmieniam ocenę w połowie recenzji, a komentarze nie są tracone. Chociaż tracę historię zmian w PR
joel
@JoelBerkeley W międzyczasie doświadczyłem kilku recenzji, w których autor zmienił swoją opinię i zauważył, że komentarze są taktowne. Jednak tracimy możliwość stopniowego recenzowania, a przy dużych recenzjach jest to ogromna kara dla recenzentów. Mamy teraz kilka wskazówek dla naszych PR, a jedną z nich jest to, aby nigdy nie zmieniać bazy po otwarciu recenzji (chyba że ktoś jest pewien, że nikt jeszcze nie zaczął recenzować). Scalanie jest w porządku, ale naszą wytyczną jest, aby nie mieszać zmiany scalającej z żadnymi innymi zmianami poza rozwiązaniami konfliktu.
haridsv
18

Musisz dodać do swojego ~/.gitconfigpliku:

[rebase]
    autosquash = true

To automatycznie osiągnie to samo, co pokazuje ta odpowiedź .

Mam to stąd .

Elena
źródło
2
cholera, przypadkowo kliknąłem opcję „odrzucenie”. ta odpowiedź pomogła mi. pozwól mi to zmienić, proszę.
Hector
@hosein Idź po to. Teraz powinieneś być w stanie to zrobić.
Mateusz Piotrowski
1
Myślę, że powinna to być albo zaakceptowana odpowiedź, albo uwzględniona w zaakceptowanej odpowiedzi. To daje rezultat, którego szukałem!
Ronald Rey
2
@RonaldRey git rebasing nie jest rozwiązaniem uniwersalnym, ponieważ wiąże się z edycją historii. Jeśli wszyscy pracują na prywatnych widelcach, które nigdy nie są klonowane przez innych, to jest w porządku, ale jak tylko ktoś sklonuje twoje repozytorium, a następnie edytujesz historię, otrzymasz różne historie.
Adam Millerchip
17

Dla każdego, kto napotka ten problem i jest zdezorientowany przez zachowanie GitHub Pull Request, główną przyczyną jest to, że PR jest różnicą końcówki gałęzi źródłowej względem wspólnego przodka gałęzi źródłowej i gałęzi docelowej. W związku z tym pokaże wszystkie zmiany w gałęzi źródłowej aż do wspólnego przodka i nie uwzględni żadnych zmian, które mogły wystąpić w gałęzi docelowej.

Więcej informacji można znaleźć tutaj: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

Różnice oparte na wspólnych przodkach wydają się niebezpieczne. Chciałbym, żeby GitHub miał opcję tworzenia bardziej standardowego PR opartego na 3-kierunkowym scalaniu.

David K. Hess
źródło
1
Powód, o którym wspomniałeś, wydaje się poprawny, ale jestem zdezorientowany, ponieważ generalnie za każdym razem, gdy master jest aktualizowany, z powrotem scalam zmiany w mojej gałęzi ... git checkout my-branch -> git merge master . Żądanie ściągnięcia zostanie natychmiast odświeżone. Czy wspólny przodek również jest aktualizowany?
G. 1
2
Wydaje się, że takie zachowanie występuje podczas wykonywania rebase zamiast scalania
G. 1
2
@ G Jedna, bardzo późna odpowiedź, ale tak - jeśli scalisz gałąź główną z gałęzią źródłową, z definicji zaktualizowałeś wspólnego przodka. To zatwierdzenie mastera, z którego się scaliłeś.
David K. Hess
13

Jednym ze sposobów rozwiązania tego problemu jest git rebase targetbranchten PR. Następnie git push --force targetbranchGithub pokaże odpowiednie zatwierdzenia i różnice. Uważaj na to, jeśli nie wiesz, co robisz. Może najpierw git diff targetbranchsprawdź gałąź testową, aby wykonać rebase, a następnie upewnić się, że nadal jest to, czego chcesz.

Elijah Lynn
źródło
11

Dzieje się tak z GitHubem, gdy squash commity scalone z gałęzi docelowej.

Używałem squasha i merge z Githubem jako domyślną strategią scalania, w tym scalania z gałęzi docelowej. Wprowadza to nowe zatwierdzenie, a GitHub nie rozpoznaje, że to zgniecione zatwierdzenie jest takie samo jak te, które są już w master (ale z różnymi hashami). Git obsługuje to poprawnie, ale wszystkie zmiany widzisz ponownie w GitHub, co utrudnia przeglądanie. Rozwiązaniem jest regularne scalanie tych wprowadzonych wcześniej zatwierdzeń zamiast operacji squash i merge. Gdy chcesz scalić inną gałąź ze swoją jako zależność git merge --squashi cofnąć to pojedyncze zatwierdzenie przed ściągnięciem z mastera, gdy ta inna gałąź faktycznie dotarła do mastera.

EDYCJA: innym rozwiązaniem jest zmiana bazy i wymuszenie wypychania. Czysta, ale przepisana historia

Achille
źródło
1
Dzięki @achille, to był naprawdę problem po mojej stronie. Po wyłączeniu scalania squasha problem został rozwiązany.
Ashvin777
Github Rebase Merge również spowoduje ten problem
numer5
0

Nie jestem do końca pewien co do teorii, która za tym stoi. Ale otrzymałem to kilka razy i mogłem to naprawić, wykonując następujące czynności.

git pull --rebase

Spowoduje to pobranie i scalenie zmian z oryginalnej gałęzi głównej repozytorium (jeśli masz na to uwagę)

Następnie wymuszasz wypychanie zmian do sklonowanego repozytorium na github (cel)

git push -f origin master

Dzięki temu twój klon github i repozytorium rodzica są na tym samym poziomie zatwierdzania github i nie zobaczysz żadnych niepotrzebnych zmian w gałęziach.

Chanaka udaya
źródło
0

Wypróbuj kolejno poniższe polecenia.

git pull "latest

git reset --hard master
Amit kumar
źródło
-1

Bezpieczne podejście, jeśli zbytnio martwisz się o zepsucie: przejdź do pliku i ręcznie usuń zmiany, a następnie zmiażdż z ostatnim zatwierdzeniem za pomocą

git add .  && git commit -a --allow-empty-message -m '' && git reset --soft HEAD~2 &&
git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"

Nie ma konfliktów, możesz iść!

Ishan Srivastava
źródło