Ao fazer uma correção em uma consolidação anterior, devo refazer ou adicionar uma consolidação separada?

Um cenário comum no desenvolvimento de software é a revisão de código de outra pessoa. Uma ferramenta comum para fazer isso é abrir uma solicitação de recebimento.

Minha pergunta é: quando são encontrados problemas na revisão, as alterações devem

ser confirmado separadamente (novo commit)
ou o commit existente deve ser modificado (supondo que ninguém esteja se ramificando do commit anterior ... porque reescrever o histórico de um branch compartilhado é uma má notícia).

Para o primeiro cenário, é fácil rastrear alterações incrementais, embora adicione algum ruído ao histórico de confirmação. A segunda opção tem os prós e contras reversos.

git code-reviews repository

— loeschg
fonte

Você diz "ruído" ao commit, mas eu li que é um histórico preciso . Por que tentar mascarar o que realmente aconteceu no histórico de submissões? Uma revisão de código é uma revisão de código, não há necessidade de pintá-la como outra coisa. Meu voto seria ir para o commit separado, e não a rebase neste caso.

— Thomas Stringer

Normalmente eu faço as duas coisas. Poste cada confirmação separadamente e, depois que a revisão estiver completa, refaça e mescle. O GitHub mantém discussões sobre a solicitação de recebimento, mesmo após a remoção ou a substituição dessas confirmações, para que não haja perda substancial de histórico devido à reestruturação. Você obtém o melhor dos dois mundos.

— precisa saber é o seguinte

Tenho sentimentos confusos em relação a se cometi algo que, de alguma forma, que mais tarde determinei, trava o sistema. esses commits, se eu descobrir o defeito deles em breve, são aqueles que eu gostaria de reverter da história. mas são apenas pedaços, não custam muito, então provavelmente a coisa mais segura, econômica e consistente a fazer (como na doutrina) é sempre se comprometer separadamente e deixar o carro na vala para que todos possam veja agora e para sempre. .... e você pode marcar cada ramo defeituoso com uma mensagem inconfundível para não criar nele, portanto, nenhum ramo compartilhado.

— 224153 Robert Pattinson-Johnson

Você pode explicar o que é "rebasing" e quando eu gostaria?

— Kilian Foth

Você supõe que a correção não introduz novos problemas e corrige os antigos. Mas muitas correções valem uma revisão por conta própria - e isso é provavelmente muito mais fácil quando as alterações incrementais podem ser revisadas separadamente.

— Doc Brown
fonte