Um revisor então deixa um comentário sobre algo relacionado às alterações feitas no primeiro commit. Se você modificar essa confirmação e forçar o envio, suas confirmações antigas desaparecerão da solicitação de recebimento e todas as confirmações, desde que as que foram refizidas aparecerão como novas confirmações após essa revisão
O que mudou desde a última vez em que um revisor analisou a solicitação de recebimento?
Quais confirmações foram modificadas e, portanto, requerem atenção, quais não foram e podem ser ignoradas?
A única maneira de saber é observar todos os commits que foram forçados a empurrar e tentar lembrar se o que você vê agora é diferente do que havia antes.
Se você tentar clicar no arquivo que foi comentado para ver se o comentário foi endereçado ou para obter mais contexto para o código na área em que o comentário foi feito, você será recebido com este encantador telescópio
Voltando à analogia da leitura de um romance – imagine fazê-lo no meio do caminho, deixe-o em paz por um dia ou dois e, quando o recolocar, você será informado de que peças importantes nas partes que você leu mudaram e a única maneira de saber exatamente o que mudou é ler tudo de novo. Não tem graça.
Como alternativa, é assim que as alterações seriam se você enviar novos commits separados:
Você ainda deve se recuperar do mestre, mas desde que os commits que já foram revisados não tenham mudado significativamente, seus revisores não precisarão examinar todos eles novamente. Considere adicionar um comentário após um push forçado com um link para o commit revisado mais recentemente, para que os revisores possam continuar de onde pararam.
Alterações aprovadas!
No momento em que seu PR foi aprovado, sua filial provavelmente já possui alguns commits que parecem um pouco confusos. Eu recomendo squash-fusão e não se preocupar com isso. O objetivo da clareza foi alcançado. As mensagens de confirmação dos PRs mesclados com squash conterão links de volta para as solicitações pull, nas quais as confirmações com squash podem ser encontradas novamente.
Não tenho certeza se a fusão de squash ainda é controversa em 2020, caso ainda seja – Reagir faz isso 🤷🏻♂️
No entanto, talvez você sinta que os commits em um PR são significativos e significativos o suficiente para garantir que sejam mesclados novamente no master como commits separados. Se for esse o caso, agora é quando você pode ir à cidade rebaseando até que todos os diffs sejam compactados nos commits perfeitos antes de mesclar sem esmagar.
tldr:
- cada confirmação em um PR deve contar uma história do que essa confirmação muda e, idealmente, também o que motivou a mudança
- rebase agressivamente antes de abrir a solicitação pull / mesclar e solicitar revisores
- após o início da revisão, pare de modificar os commits de sua filial e forme novos
- após a aprovação, mesclagem de squash (ou squash seletivamente confirma e mescla)
Tenha em mente
Como a segunda parte deste fluxo de trabalho é fortemente informada sobre como o Github lida com confirmações reformuladas, pode chegar um dia em que essas preocupações sejam tratadas pela plataforma e esse fluxo de trabalho não será mais necessário. Até lá, considere otimizar seus commits para seus revisores 🙂
Recursos relacionados:
Git empilhado é uma ferramenta para gerenciar históricos de confirmação que eu achei mais intuitivos do que o rebasing interativo via CLI. O tutorial pode parecer assustador, mas pode ser um problema de design colocar tudo (incluindo instruções de uso do Emacs) em uma página. Na verdade, é muito fácil aprender e usar um pouco de cada vez.
Por favor deixe-me saber (@CheapSteak) se você tiver objeções a essa abordagem ou sugestões sobre como ela pode ser melhorada.