Para atualizar uma solicitação de recebimento
Para atualizar uma solicitação de recebimento (ponto 1), a única coisa que você precisa fazer é fazer check-out da mesma ramificação da qual o pedido de recebimento é e enviá-lo novamente:
cd /my/fork
git checkout master
...
git commit -va -m "Correcting for PR comments"
git push
Opcional - histórico de confirmação de limpeza
Você pode ser solicitado a juntar suas confirmações para que o histórico do repositório fique limpo ou você deseja remover as confirmações intermediárias que desviam a atenção da "mensagem" em sua solicitação de recebimento (ponto 2). Por exemplo, se o seu histórico de consolidação estiver assim:
$ git remote add parent git@github.com:other-user/project.git
$ git fetch parent
$ git log --oneline parent/master..master
e4e32b8 add test case as per PR comments
eccaa56 code standard fixes as per PR comments
fb30112 correct typos and fatal error
58ae094 fixing problem
É uma boa ideia juntar as coisas para que elas apareçam como um único commit:
$ git rebase -i parent/master
Isso solicitará que você escolha como reescrever o histórico de sua solicitação de recebimento; o seguinte estará em seu editor:
pick 58ae094 fixing actual problem
pick fb30112 correct typos
pick eccaa56 code standard fixes
pick e4e32b8 add test case as per PR comments
Para qualquer confirmação que você queira fazer parte da confirmação anterior - altere pick para squash:
pick 58ae094 fixing actual problem
squash fb30112 correct typos
squash eccaa56 code standard fixes
squash e4e32b8 add test case as per PR comments
E feche seu editor. O Git reescreverá o histórico e solicitará que você forneça uma mensagem de confirmação para a confirmação combinada. Altere de acordo e seu histórico de consolidação agora será conciso:
$ git log --oneline parent/master..master
9de3202 fixing actual problem
Empurre isso para o seu garfo:
$ git push -f
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 978 bytes, done.
Total 11 (delta 9), reused 7 (delta 6)
To git@github.com:me/my-fork.git
f1238d0..9de3202 HEAD -> master
e sua solicitação de recebimento conterá uma única confirmação, incorporando todas as alterações anteriormente divididas em várias confirmações.
Mudar a história em repositórios públicos é uma coisa ruim
Reescrever o histórico e usar git push -f
em um ramo que, potencialmente, alguém já tenha clonado é uma coisa ruim - faz com que o histórico do repositório e o do checkout divergam.
No entanto, alterar o histórico do seu fork para corrigir a alteração que você propõe integrar em um repositório - é uma coisa boa. Como tal, não há reservas esmagando o "ruído" dos seus pedidos de recepção.
Uma nota sobre ramos
No exemplo acima, mostro a solicitação pull como originária da master
ramificação do seu fork, não há nada de errado nisso, mas ela cria certas limitações, como, se essa é sua técnica padrão, apenas poder ter um PR aberto por repositório . É uma idéia melhor criar uma ramificação para cada alteração individual que você deseja propor:
$ git branch feature/new-widgets
$ git checkout feature/new-widgets
...
Hack hack hack
...
$ git push
# Now create PR from feature/new-widgets
master
é um ramo também, então tecnicamente não importa :)