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.

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:

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ń.

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.

Musisz dodać do swojego ~/.gitconfigpliku:

[rebase]
    autosquash = true

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

Mam to stąd .

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.

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.

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

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.

Wypróbuj kolejno poniższe polecenia.

git pull "latest

git reset --hard master

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ść!