Depende de como você tem sua estrutura de repositório e o que você está tentando realizar. Preferimos fazer revisões de "pré-confirmação", o que no mundo do DVCS realmente significa "pré-envio". Os DVCS são mais agradáveis nesse ambiente (quando comparados aos SCMs tradicionais) porque possuem funcionalidade incorporada para salvar as alterações locais e recuperar o espaço de trabalho para que você possa trabalhar em outra coisa.
Se você deseja fazer revisões pós-envio, o fluxo de trabalho ideal depende muito da sua estrutura de repositório. Por exemplo, vamos assumir uma estrutura de repositório semelhante à discutida neste artigo sobre layouts de repositório Git . Nesse caso, convém revisar as alterações que estão sendo mescladas develop
. As confirmações individuais nas ramificações dos recursos podem não fazer sentido revisar. Obviamente, todos hotfixes
também devem ser revisados juntamente com as fusões master
.
Se, em vez disso, você tiver um único ramo de integração no qual as pessoas estão fazendo check-in diretamente, convém revisar todos os pushs desse ramo. Provavelmente é um pouco menos eficiente, mas ainda pode funcionar. Nesse ambiente, você precisaria garantir que todas as alterações que foram enviadas foram revisadas antes de fazer um lançamento. Isso pode ser mais complicado.
Quanto a b), a única coisa que eu sugeriria é enviar um e-mail para o suporte SmartBear (support@smartbear.com) diretamente. Nós (sim, eu trabalho para o SmartBear) ficaremos felizes em ajudá-lo a resolver os problemas do seu caminho, mas não há informações suficientes nesta pergunta para corrigir seu problema. O processo normal é apenas executar o instalador e tudo funciona. Aparentemente, algo deu errado nesse processo.