Nada como saber usar bem as ferramentas que você tem à sua mão, não é mesmo?

Como disse Kent Becks:

não precisamos ser programadores excepcionais, mas bons programadores com excelentes hábitos.

Tá, não deve ter sido exatamente isso que ele disse, mas você entendeu.

1. escolha um padrão que você e seu time sigam. Pelo menos inicie de um e adapte de acordo com seu time e projeto. Dois bem conhecidos são o Git Flow e o Trunk Based Development. O primeiro é mais simples mas tem problemas ao escalar (filas de PRs). O segundo exige maturidade técnica e de qualidade, pois os commits são na master.

2. A partir de um padrão, recomendo colocar um sistema para rodar validações a cada commit ou push. Existe o husky para projetos baseados em NodeJS. Isso pois por mais que tenha carinho e atenção, a maior segurança vem dessas validações.

3. Outra coisa é: Leia o terminal! Olha o que a ferramenta ta te dizendo sobre como está seu repositório...ela vai te dar dicas valiosas. Vai te indicar a usar um comando ou outro dependendo do cenário. Leia o terminal!

Abaixo os comandos que mais uso no meu dia a dia:

• git status -> pra ver o estado do seu repo local em comparação com o remoto (esse vcs já devem usar diariamente)

• git add -p -> pra ir vendo em pequenos pedaços (chunks) de código o diff do que foi mexido, e ir incluindo ou não. É uma forma interativa de criar o package do commit

• git commit -m "mensagem padronizada" -> cria o pacote a ser enviado ao repo remoto, recomendo padrão commit lint, é possível utilizar ferramentas pra analisar os commits

• git stash/git stash pop -> esse comando armazena as suas alterações em uma fila, e restaura o estado que estava na sua branch. Uso quando quero guardar o que estava fazendo rapidamente e ir pra outra branch, por exemplo. Mas também é viável e até mais recomendável commitar e depois usar ammend pra rescrever o commit WIP (Work in progress).

• git commit --amend --no-edit -> uso quando quero adicionar algo ao commit anterior sem editar a mensagem. Use com cuidado, exige um git push -f após

• git rebase <BRANCH_NAME> -> atualiza sua branch com outra, mas diferente do merge, pull ou fetch, que trazem as alterações acima da sua, o rebase reescreve a história da sua branch, removendo sua alteração, colocando a história da branch indicada no comando, e aí sim colocando seus commits novamente. Por isso quando você for resolver conflitos após este método você verá suas alterações como novas, e o código "antigo" na verdade já terá atualização do rebase. Também obriga o uso de git push -f após seu uso! Use com carinho.

• git push -> envia todas suas alterações para o repo remoto.

• git revert -> esse comando remove certo commit do histórico. Muito útil quando um commit acabou quebrando algo, gerando um comportamento inexperado que os testes não pegaram, e você quer remover pra depois voltar corrigido.

Para resolver conflitos de Merge, recomendo uma interface como o VS Code. Facilita muito a vida!

Algumas dicas gerais seriam: Commits pequenos e constantes. Rebases constantes. Comunicação constante entre o time. O versionamento vai refletir o entrosamento (ou falta de) do time, assim como a organização das tarefas e sua granularidade.

Não adianta usar os melhores comandos mas ficar 2 semanas sem abrir a PR, gerando um distanciamento enorme entre as versões!

É isso! Valeu! :)