Richiesta pull GitHub che mostra commit già nel ramo di destinazione

Question

Sto provando a rivedere una richiesta pull su GitHub a un ramo che non è master. Il ramo obiettivo era dietro il master e la richiesta pull mostrava commit dal master, quindi ho unito il master e lo ho spinto a GitHub, ma i commit e diff per loro appaiono ancora nella richiesta pull dopo l'aggiornamento. Ho raddoppiato controllato che il ramo su GitHub ha il commit dal master. Perché appaiono ancora nella richiesta pull?

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

Answer 1

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

Tuttavia, si può ottenere per mostrare i cambiamenti aggiornati effettuando le seguenti operazioni:

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

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

O come hexsprite ha sottolineato nella sua risposta, è anche possibile forzare l'aggiornamento facendo clic su Modifica sul PR e la modifica temporaneamente la base per un ramo diverso e viceversa. Questo produce l'avviso:

Sei sicuro di voler cambiare la base?

Alcuni commit dal vecchio ramo di base possono essere rimossi dalla timeline ei vecchi commenti di revisione potrebbero non essere aggiornati.

e Will leave two log entries nel PR:

Answer 2

Per chiunque altro imbattersi in questo e confusi da GitHub Pull comportamento Richiesta, la causa principale è che un PR è un diff del ramo fonte punta contro l'antenato comune del ramo sorgente e del ramo bersaglio. Pertanto mostrerà tutte le modifiche sul ramo di origine fino all'antenato comune e non prenderà in considerazione eventuali modifiche che potrebbero essersi verificate sul ramo di destinazione.

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

diff basate antenato comune sembrano pericolosi. Vorrei che GitHub avesse un'opzione per creare un PR standard a merge più standard.

Answer 3

Un modo per risolvere questo problema è git rebase targetbranch in quello PR. Quindi git push --force targetbranch, quindi Github mostrerà i giusti commit e diff. Stai attento con questo se non sai cosa stai facendo. Forse prima controlla il ramo di prova per fare il rebase, quindi il git diff targetbranch per assicurarti che sia ancora quello che vuoi.

Answer 4

Non sono esattamente sicuro della teoria alla base di questo. Ma ho avuto questo più volte e in grado di risolvere questo problema facendo quanto segue.

git pull --rebase 

Verrà recuperato e unire le modifiche dal branch master repo originale (Se si dispone di punto a quello)

Poi si spingono le modifiche con forza al repository github clonato (target)

git push -f origin master 

Ciò assicurerà che il vostro clone di github e il repository padre siano allo stesso livello di commit di github e non vedrete cambiamenti non necessari tra i rami.

Answer 5

è necessario aggiungere il seguente al file ~/.gitconfig:

[rebase] 
    autosquash = true 

Questo raggiungerà automaticamente la stessa cosa che this answer spettacoli.

Ho ottenuto questo da here.

Answer 6

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

Soluzione 1: REBASE

Supponiamo che si desidera unire in master da feature-01:

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

Se si sta lavorando su una forchetta quindi potrebbe essere necessario sostituire origin sopra con upstream. Vedi How do I update a GitHub forked repository? per ulteriori informazioni sul monitoraggio dei rami remoti del repository originale.

Soluzione 2: Creare una nuova richiesta di pull

Supponiamo che si desidera unire intro master da feature-01:

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

Ora aprire una richiesta di pull per feature-01-rebased e chiudere quello per feature-01.

Answer 7

Ecco una buona soluzione. Utilizzare il pulsante Edit quando si visualizza il PR in GitHub per modificare il ramo di base su un valore diverso da master. Quindi riportalo su master e ora mostrerà correttamente solo le modifiche rispetto ai commit più recenti.