Melhores práticas

Uso do git

Ao iniciar uma nova funcionalidade/refatoração criar uma branch e uma MR para ela. Assim fica claro que tem coisa em andamento e para onde a branch deve ir ao final (onde deve ser o merge).

Ao iniciar uma nova funcionalidade/refatoração operacionalizar o que vai ser feito e anotar na MR em formato de TODO, para ficar fácil de codificar e acompanhar o andamento.

Ao dar merge de uma funcionalidade/refatoração deletar a branch do remote e dar squash sempre que possível. Assim a árvore de commits fica mais limpa e a quantidade de branchs reduzida.

Ao finalizar uma funcionalidade/refatoração, se for dar squash dos commits, verificar se tem outras que dependem da mesma e atualizar elas antes do squash. Isso evita que, ao tentar atualizar branchs dependentes usando pull, dê muitos conflitos, uma vez que os commits terão hash diferentes e iram mexer nos mesmo arquivos.

Ao dar merge de qualquer coisa avisar todo o time da operação.

Atualizar a branch em que está sendo feito a funcionalidade/refatoração sempre que a branch base mudar (aquela que você usou como ponto de inicio para criar a sua).

Se sua MR depende de outra MR ainda não aprovada, coloque sua MR como draft e indique que ela só estará pronta depois que a outra for aprovada. Isso auxilia o revisor a entender que parte do seu código na verdade veio de outra MR que ainda não foi dado merge. E auxilia você a saber que caso a outra branch sofra modificações você deve puxar elas para a sua branch e resolver os conflitos.

Se sua MR depende de outro projeto em outro repositório, como por exemplo uma API, é uma boa prática indicar com qual versão seu código deve se conectar para funcionar. Isso é indique na sua MR a banch/MR/tag desta dependência externa.

Se sua MR é uma API por exemplo, e a modificação foi feita exclusivamente para alguma funcionalidade atrelada ao front-end (e.x.: criado uma coleção nova para o front fazer o cadastro), faça o apontamento para qual MR do front-end essa modificação foi feita. Pois se o front for reprovado, não faz sentido dar merge de um trecho de código que só tem uso para um MR específica no front-end que não foi aprovado.