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.
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.
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.
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 commitgit 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 commitsgit 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 umgit push -f
apósgit 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 degit 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! :)
Top comments (0)