Sto cercando di rivedere una richiesta pull su GitHub a un ramo che non è master. Il ramo di destinazione era dietro il master e la richiesta pull mostrava i commit dal master, quindi ho unito master e l'ho spinto su GitHub, ma i commit e le differenze per loro appaiono ancora nella richiesta pull dopo l'aggiornamento. Ho raddoppiato verificato che il ramo su GitHub abbia i commit dal master. Perché vengono ancora visualizzati nella richiesta pull?

Ho anche verificato la richiesta pull localmente e mostra solo i commit non uniti.

Sembra che la richiesta pull non tenga traccia delle modifiche al ramo di destinazione (ho contattato il supporto di GitHub e ho ricevuto una risposta il 18 novembre 2014 affermando che questo è di progettazione).

Tuttavia, puoi ottenerlo per mostrarti le modifiche aggiornate procedendo come segue:

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

Sostituire githuburl, org, repo, targetbranch, e currentbranch, se necessario.

O come ha sottolineato hexsprite nella sua risposta, puoi anche forzarlo ad aggiornarlo facendo clic Editsul PR e cambiando temporaneamente la base in un altro ramo e viceversa. Questo produce l'avvertimento:

Sei sicuro di voler cambiare la base?

Alcuni commit dal vecchio ramo di base potrebbero essere rimossi dalla sequenza temporale e i vecchi commenti di revisione potrebbero diventare obsoleti.

E lascerà due voci di registro nel PR:

Ecco una buona soluzione. Utilizzare il Editpulsante quando si visualizza il PR in GitHub per modificare il ramo di base in qualcosa di diverso da master. Quindi ripristinalo mastere ora mostrerà correttamente solo le modifiche degli commit più recenti.

Per riassumere, GitHub non modifica automaticamente la cronologia di commit nelle richieste pull. Le soluzioni più semplici sono:

Soluzione 1: Rebase

Supponiamo che si desidera unire in masterda feature-01:

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

Se stai lavorando su una forcella, potrebbe essere necessario sostituirla origincon upstream. Vedi Come aggiorno un repository biforcato GitHub? per ulteriori informazioni sul tracciamento di rami remoti del repository originale.

Soluzione 2: creare una nuova richiesta pull

Supponiamo di voler unire intro masterda feature-01:

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

Ora apri una richiesta pull feature-01-rebasede chiudi quella per feature-01.

Devi aggiungere quanto segue al tuo ~/.gitconfigfile:

[rebase]
    autosquash = true

Ciò otterrà automaticamente lo stesso di quello che mostra questa risposta .

L'ho preso da qui .

Per chiunque si imbatta in questo e confuso dal comportamento della richiesta pull di GitHub, la causa principale è che un PR è un diff della punta del ramo di origine rispetto al progenitore comune del ramo di origine e del ramo di destinazione. Mostrerà quindi tutte le modifiche sul ramo di origine fino all'antenato comune e non terrà conto di eventuali modifiche che potrebbero essersi verificate sul ramo di destinazione.

Maggiori informazioni disponibili qui: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

I diff diffusi basati su antenati sembrano pericolosi. Vorrei che GitHub avesse un'opzione per creare un PR basato su unione a 3 vie più standard.

Un modo per risolvere questo problema è git rebase targetbranchin quel PR. Quindi git push --force targetbranch, quindi Github mostrerà i giusti commit e diff. Fai attenzione se non sai cosa stai facendo. Magari controlla prima un ramo di prova per fare il rebase poi git diff targetbranchper assicurarti che sia ancora quello che vuoi.

Questo succede con GitHub quando i commit di squash vengono uniti dal ramo di destinazione.

Avevo usato squash e merge con Github come strategia di unione predefinita, comprese le fusioni dal ramo di destinazione. Questo introduce un nuovo commit e GitHub non riconosce che questo commit schiacciato è lo stesso di quelli già presenti nel master (ma con hash diversi). Git lo gestisce correttamente, ma vedi di nuovo tutte le modifiche in GitHub, rendendolo fastidioso da rivedere. La soluzione è fare una fusione regolare di questi commit a monte invece di uno squash e unire. Quando vuoi unirti in un altro ramo nel tuo come dipendenza, git merge --squashe ripristinare quel singolo commit prima di estrarre dal master una volta che l'altro ramo è effettivamente arrivato al master.

EDIT: un'altra soluzione è rebase e forzare la spinta. Storia pulita ma riscritta

Non sono esattamente sicuro della teoria alla base di questo. Ma l'ho preso diverse volte e sono riuscito a risolvere il problema nel modo seguente.

git pull --rebase

In questo modo verranno recuperate e unite le modifiche dal ramo master repository originale (se si ha il punto)

Quindi invii forzatamente le modifiche al repository clonato di github (target)

git push -f origin master

Questo assicurerà che il tuo clone github e il tuo repository genitore siano allo stesso livello di commit github e non vedrai alcuna modifica non necessaria tra i rami.

Prova i comandi seguenti, uno per uno.

git pull "latest

git reset --hard master

Approccio sicuro se sei troppo preoccupato per rovinare le cose: vai al file e rimuovi manualmente le modifiche, quindi schiaccia con l'ultimo commit usando

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})"

Io non ci sono conflitti, sei a posto!