Fala, Danilo!

Então, o ideal é que **"*pushes*" direto para a *branch* principal sejam proíbidos** e que *commits* nela tenham vindo de algum *merge* e, as outras ***branches* para mesclagem devem ser testadas previamente** para **evitar problemas** na hora do *deploy*.

No seu caso, basta criar um workflow para quando ocorrer um [*push* na *branch*](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-filters-to-target-specific-branches-or-tags-for-push-events) principal, tenha como um [*job*](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobs) a execução dos testes e, outro *job* para o *deploy* que só seja executado caso [nenhum *job* anterior falhe](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error) (é o comportamento padrão).

---

> Tem como cancelar o commit caso os testes falhem ?

Não, não há como "cancelar" um commit, há apenas formas de reverte-lô e exclui-lô forçando um push (o que não é muito recomendado).

> [...] corrige faz o commit repete o fluxo, então ai asim faz pull request ?

Sim. Ao invés de criar outro *Pull Request*, você pode criar um *workflow* especialmente para elas em que rode os testes, dessa forma você não precisa mesclar para ver o resultado dos testes. E a cada novo commit na PR, os testes serão rodados novamente.

Obrigado, me ajudou muito, vou criar um repositório de teste e testar os diferentes cenários para fixar e pegar o fluxo.

Fala, Danilo! Então, o ideal é que "*pushes*" direto para a *branch* principal sejam proíbidos e que commits nela tenham vindo de algum merge e, as outras *branches* para mesclagem devem...