Come aggiornare una richiesta pull dal repository biforcato?

592

Quindi ho prima biforcato un repo e poi ho fatto un commit a quel repository biforcato. Ho quindi aperto una richiesta pull. La richiesta pull elencava tutte le modifiche che desideravo.

Dopo aver esaminato la mia richiesta pull, ci sono state alcune modifiche che il proprietario del repository voleva che facessi prima di accettarlo. Ho apportato tali modifiche nel mio fork, ora come posso aggiornare la richiesta pull con tali modifiche (o non è come dovrei gestirlo)?

git version-control github

— SteveBot
fonte

7

possibile duplicato del flusso di lavoro di Github preferito per l'aggiornamento di una richiesta pull dopo la revisione del codice

— Paul Draper

7

@PaulDraper Non sono d'accordo, l'utente già conosce e presenta vari metodi per l'aggiornamento di una richiesta pull e chiede quale sia la migliore. D'altra parte, non conoscevo alcun metodo e chiedevo della loro esistenza. Come dimostra la popolarità di questa domanda, questo è il caso di molti altri utenti.

— stevebot,

6

Penso che la popolarità sia dovuta al fatto che (1) questa è una domanda davvero buona e comune e (2) alcuni utenti sono finiti qui invece che lì. Se fosse stato originariamente identificato come duplicato, avrebbero trovato l'altra domanda uguale e avrebbero risposto alla loro domanda.

— Paul Draper,

586

L'hai fatto correttamente. La richiesta pull si aggiornerà automaticamente. Il processo è:

Apri richiesta pull
Commettere le modifiche in base al feedback nel repository locale
Spingere verso il ramo pertinente della forcella

La richiesta pull aggiungerà automaticamente i nuovi commit nella parte inferiore della discussione sulla richiesta pull (ovvero, è già lì, scorri verso il basso! )

— shelhamer
fonte

73

simpatico! Stavo controllando dappertutto, ma l'effettiva richiesta di pull. è magia nera, non la metterò in discussione.

— stevebot,

57

Questa è una buona ragione per lavorare nei rami. Se, ad esempio, hai sempre spinto al master, potresti aggiungere involontariamente alla tua precedente richiesta pull.

— Brian Pan,

3

Questo non sembra più essere il caso, anche se in passato. Ecco un esempio di una richiesta pull che ho fatto ( github.com/toopay/bootstrap-markdown/pull/167 ) rispetto al ramo stesso ( github.com/mhuggins/bootstrap-markdown/commits/… ). Curioso come farlo più poiché il processo sembra essere cambiato.

— Matt Huggins,

1

GitHub in realtà ti dice: "Aggiungi altri commit spingendo al ramo SolveWorldHunger su ChangeTheWorldProject."

— flow2k

1

Lo stesso qui - Non vedo cambiamenti dal repository biforcato nel repository principale. Sembra un bug di GitHub

— andrfas,

78

Aggiornare una richiesta pull in GitHub è facile come eseguire il commit delle modifiche desiderate nel ramo esistente (utilizzato con la richiesta pull), ma spesso si desidera anche comprimere le modifiche in un unico commit:

git checkout yourbranch
git rebase -i origin/master

# Edit command names accordingly
  pick   1fc6c95 My pull request
  squash 6b2481b Hack hack - will be discarded
  squash dd1475d Also discarded

git push -f origin yourbranch

... e ora la richiesta pull contiene solo un commit.

Link correlati sul rebasing:

— JMU
fonte

2

Voto per menzionare rebase. Aiuta a eliminare il rumore nella cronologia delle revisioni.

— stevebot,

+11 (sì, ho inteso che la chiave è ripetuta. Usare git rebase / pick / squash sta funzionando alla grande.

— javadba,

11

L'aspetto negativo di questo approccio è che stai rimuovendo il tuo commit precedente. Ciò significa che se nella richiesta pull vengono fatti commenti, questi andranno persi e scompariranno insieme al commit originale.

— Blowekamp,

In Bitbucket puoi vedere i commenti su "versioni precedenti" di un file in una richiesta pull. Anche se sarebbe bello vedere qualcosa come Gerrit in cui la patch si impegna e può vedere l'intera storia con commenti. Crea una cronologia git chiara e tracciabilità quando puoi tornare indietro e vedere la discussione completa su qualsiasi commit.

— Amore

36

Basta spingere sul ramo a cui fa riferimento la richiesta pull. Finché la richiesta pull è ancora aperta, dovrebbe essere aggiornata automaticamente con ogni commit aggiunto.

— igorw
fonte

14

L'ho fatto usando i seguenti passaggi:

git reset --hard <commit key of the pull request>
Ho fatto le mie modifiche al codice che volevo fare
git add
git commit --amend
git push -f origin <name of the remote branch of pull request>

— Vikasdeep Singh
fonte

1

Molto bene, preferisco questo approccio! GitHub nasconde anche (ma mantiene) sezioni di codice obsolete e commenti associati. È bene ricordare che se la richiesta pull contiene diversi commit e quello che richiede di essere riparato non è in punta al ramo, "git reset --hard" scarterà tutte le modifiche confermate dopo l'ID specificato. Ho avuto un backup che ho applicato manualmente. Non molto conveniente se c'è più di un commit in più però ...

— Nagev

3

Se si utilizza GitHub su Windows :

Apporta modifiche a livello locale.
Apri GitHub, passa ai repository locali, fai doppio clic sul repository.
Passa il ramo (nella parte superiore della finestra) al ramo da cui hai creato la richiesta pull (ovvero il ramo sul lato della forcella del confronto)
Dovrebbe vedere l'opzione per inserire il commento di commit a destra e applicare le modifiche al repository locale.
Fai clic su Sincronizza in alto, che tra l'altro spinge il commit dal locale al fork remoto su GitHub.
La richiesta pull verrà aggiornata automaticamente con gli commit aggiuntivi. Questo perché la richiesta pull rappresenta un diff con il ramo del fork. Se vai alla pagina della richiesta pull (quella in cui tu e gli altri potete commentare la vostra richiesta pull) la scheda Commit dovrebbe avere i vostri commit aggiuntivi.

Questo è il motivo per cui, prima di iniziare a apportare modifiche, è necessario creare una diramazione per ogni serie di modifiche che si prevede di inserire in una richiesta pull. In questo modo, una volta effettuata la richiesta pull, è quindi possibile creare un altro ramo e continuare a lavorare su qualche altra attività / funzione / correzione bug senza influire sulla precedente richiesta pull.

— AaronLS
fonte