Gerencio vários repositórios Git, com frequência preciso inspecionar as alterações feitas pelos desenvolvedores num período de 30 dias ou mais para fazer integração das novas funcionalidades desenvolvidas. Nestas situações é normal eu encontrar alterações em arquivos que não fazem sentido: alterações em partes do sistema não relacionada com a funcionalidade que chegam a quebrar algo que antes funcionava. Obs.: Não vou entrar no mérito de testes unitários ou outros testes automatizados que podem evitar isto.
Geralmente essas alterações não são intencionais e ocorrem com desenvolvedores novos ou com menos experiência com Git.
Isso pode ser evitado (além de outros treinamentos e boas práticas) com alguns hábitos e boas práticas no dia a dia do desenvolvimento e trabalho com controle de versão. Os desenvolvedores devem observar os arquivos alterados e o código que está sendo enviado (alterado) em cada commit.
Para isso deve-se usar e abusar de alguns comandos Git:
- guarda todos arquivos alterados:
$ git stash
- guarda todos arquivos alterados incluindo não versionados:
$ git stash --include-untracked
- recupera últimos arquivos guardados:
$ git stash pop
- apaga últimos arquivos guardados:
$ git stash drop
- verifica alterações nos arquivos (não adicionados ao index):
$ git diff
- verifica alterações nos arquivos adicionados ao index:
$ git diff --cached
Dica de ouro: Sempre antes de enviar seu código (commit) use o git diff (conforme acima) ou revise o código que você vai enviar para o repositório com sua ferramenta favorita, de modo a evitar enviar lixos, comentários ou alterações não intencionais para o repositório remoto compartilhado.
Mais algumas sugestões de Boas práticas:
- Nunca usar git commit -a ou git commit --all a menos q vc tenha certeza absoluta do que está fazendo
- Evitar usar --no-ff
- Ao invés de usar `git pull`, use `git pull --rebase` (saiba mais aqui)
Deixe um comentário