Cosa fare dopo è: continuare a contribuire con nuove funzionalità o correggere altri bug nei loro rami dedicati (inviati solo al tuo fork).
Significa che la tua forcella rimane, ma i rami all'interno della tua forcella possono andare e venire.
Puoi anche rimuovere il fork se non hai intenzione di contribuire ulteriormente, ma rimuoverà la voce corrispondente in "Archivi a cui contribuisci" .
È più facile:
- elimina il tuo
fixramo (in realtà, ora è cancellato per te ) sul tuo fork (e nel tuo repository clonato locale: vedi " Eliminare un ramo Git sia in locale che in remoto ")
git pull upstream master(se masterera il ramo in cui è stata integrata la tua correzione: l'unione sarà di avanzamento veloce): nessun rebase necessario a questo punto.- ricreare un ramo di correzione sopra il locale aggiornato
master(ora con l'ultimo di upstream master).
Tuttavia, non dimenticare mai un passaggio prima di inviare qualsiasi futura richiesta pull:
rebase prima il ramo corrente ( fix) dal ramo di destinazione upstream
( upstreamessendo il repo originale che hai biforcato: vedi " Qual è la differenza tra origin e upstream in GitHub ")
Prima di inviare qualsiasi cosa al repository originale ("upstream"), devi assicurarti che il tuo lavoro sia basato sull'ultimo di detto repository originale (altrimenti la richiesta pull non si tradurrà in un'unione in avanti veloce una volta applicata di nuovo sul upstreamrepo).
Vedere, ad esempio, " Flusso di lavoro per la gestione delle richieste pull su repository condivisi in GitHub ".
In altre parole, upstreampuò evolversi (avere nuovi commit su di esso) mentre sei impegnato a sistemare le cose. È necessario riprodurre le correzioni in aggiunta a quest'ultimo lavoro dall'upstream per assicurarsi che i commit siano ancora compatibili con l'ultimo di upstream.
L' OP Santosh Kumar chiede nei commenti :
Ho tirato e unito da upstreama master, e adesso?
Se non hai apportato nuove correzioni dalla tua recente richiesta pull, vedi sopra (elimina e ricrea un nuovo ramo fixsopra quello aggiornato master).
Se hai fatto più lavoro dopo la tua richiesta pull, non mi unirei da upstreamse voglio fare una nuova richiesta pull: vorrei tirare e rebase :
git pull --rebase upstream master
In questo modo, tutto il mio nuovo lavoro locale viene riprodotto in aggiunta ai upstream mastercommit più recenti (recuperati nel mio repository locale), supponendo che mastersia il ramo di destinazione che integrerà la mia futura richiesta pull.
Quindi posso spingere il mio lavoro locale a ' origin', che è il mio fork su GitHub di upstream.
E dal mio fork su GitHub, posso tranquillamente fare una richiesta pull, sapendo che aggiungerà solo nuovi commit a upstreamsenza bisogno di alcuna risoluzione di unione: unire quei nuovi commit nel upstreamrepo significherà una semplice unione in avanti veloce.
A git pull --rebasesenza specificare il ramo in cima al quale vuoi rebase il tuo fixramo (attualmente estratto) non funzionerebbe:
Quello ( git pull --rebase) dice:
You asked to pull from the remote '`upstream`', but did not specify a branch.
Devo aggiungere finalmente il master? E cosa farà? Eliminerà il mio fixramo?
Sì, puoi specificare il ramo che sarà il target della richiesta pull, ad esempio ' master'.
Ciò non eliminerà il tuo fixramo, ma lo riprodurrà sopra l'upstream masterrecuperato nel tuo repository.
:)