O que fazer a seguir é: continuar contribuindo com novos recursos ou consertando outros bugs em seus próprios branches dedicados (enviados apenas para seu fork).
O que significa que o garfo fica, mas os galhos dentro do garfo podem ir e vir.
Você também pode remover a bifurcação se não estiver planejando contribuir mais, mas isso removerá a entrada correspondente em 'Repositórios para os quais você contribui' .
É mais fácil:
- exclua seu
fixbranch (na verdade, agora ele foi excluído para você ) em seu fork (e em seu repositório clonado local: consulte " Excluir um branch Git local e remotamente ")
git pull upstream master(se masterfoi o branch no qual sua correção foi integrada: a fusão será rápida): nenhum rebase necessário neste ponto.- recrie um branch de correção em cima de seu local atualizado
master(agora com o mais recente de upstream master).
No entanto, nunca se esqueça de uma etapa antes de enviar qualquer solicitação pull futura :
rebase primeiro seu branch atual ( fix) do branch de destino upstream
( upstreamsendo o repo original que você bifurcou: veja " Qual é a diferença entre origem e upstream no github ")
Antes de enviar qualquer coisa de volta para o repo original ("upstream"), você precisa se certificar de que seu trabalho é baseado no último do dito repo original (ou a solicitação de pull não resultará em uma mesclagem de avanço rápido uma vez aplicada de volta ao upstreamrepo).
Veja, por exemplo, " Fluxo de trabalho para gerenciar solicitações pull em repositórios compartilhados no github ".
Em outras palavras, upstreampode evoluir (ter novos commits enviados) enquanto você está ocupado consertando coisas. Você precisa repetir suas correções sobre o trabalho mais recente do upstream para ter certeza de que seus commits ainda são compatíveis com o mais recente de upstream.
O OP Santosh Kumar pergunta nos comentários :
Eu puxei e mesclei de upstreammestre, e agora?
Se você não fez nenhuma nova correção desde sua solicitação pull recente, veja acima (exclua e recrie um novo branch fixem cima do atualizado master).
Se você tiver feito mais algum trabalho desde sua solicitação de pull, eu não faria a mesclagem de upstreamse quiser fazer uma nova solicitação de pull: eu puxaria e rebasearia :
git pull --rebase upstream master
Dessa forma, todo o meu novo trabalho local é reproduzido em cima dos upstream mastercommits mais recentes (obtidos em meu repositório local), supondo que masterseja o branch de destino que integrará minha solicitação de pull futura.
Em seguida, posso enviar meu trabalho local para ' origin', que é minha bifurcação no GitHub do upstream.
E da minha bifurcação no GitHub, posso fazer uma solicitação de pull com segurança, sabendo que só adicionará novos commits upstreamsem a necessidade de qualquer resolução de mesclagem: mesclar esses novos commits no upstreamrepo significará uma mesclagem simples e rápida.
A git pull --rebasesem especificar o branch no topo do qual você deseja realocar seu fixbranch (atualmente em check-out) não funcionaria:
Isso ( git pull --rebase) diz:
You asked to pull from the remote '`upstream`', but did not specify a branch.
Devo anexar master finalmente? E o que isso vai fazer ?, vai deletar meu fixbranch?
Sim, você pode especificar o branch que será o alvo da solicitação de pull, por exemplo ' master'.
Isso não excluirá seu fixbranch, mas irá reproduzi-lo em cima do upstream masterobtido em seu repo.
:)