Falha Nossa no Git (TOP 5)

  • Article

Fiz aqui um TOP 5 das coisas mais estranhas que notei no nosso repositório do ARDA.

Seguem os links dos repositórios:

Antigo: https://github.com/DXBrazil/Arda_old
Recente: https://github.com/DXBrazil/Arda

Bons desenvolvedores mantém o histórico do GIT linear e conciso usando um workflow definido (ex: gitflow) , squash commit, rebase, etc. Nosso time é bom, mas ignoramos essas práticas e mantivemos todos os commits intermediários. Felizmente como o histórico ficou intacto, hoje é possível entender a história do ARDA em todos os detalhes, principalmente com os nossos erros.

Falha #5: Trabalhar sem feature branches

Por um tempo, mantivemos branches individuais por usuários e isso gerou um histórico visualmente não-linear:

image

Em nosso projeto, não adotamos o rebase e sempre fizemos pontos de merge. Embora o rebase torne o histórico mais linear, a vantagem do merge é manter o histórico fiel aos commits realizados.

Apenas como brincadeira, peguei um screenshot do SourceTree e rotacionei a imagem, tornando o nosso histórico musicalmente mais interessante:

image

Que confusão! Hoje vejo que poderíamos ter feito um histórico mais limpo se tivéssemos adotado o workflow do Gitflow (ou semelhante) desde o princípio do projeto.

Falha #4: Guardar senhas dentro do repositório

O pior é que esse erro é muito comum nos projetos. No nosso caso, adicionamos o arquivo de secrets.json com informações de login no Redis, SQL Server e Azure Blob Storage.

image

Em seguida, tentamos remover as senhas com um commit “removido string de conexão do sql server”.

image

Esse commit também poderia ser renomeado para “hackers, aqui tem senha -- veja os detalhes do commit”. Embora as senhas sejam removidas dos arquivos, os commits são mantidos dentro do repositório do GIT e qualquer um que tenha acesso pode olhar o histórico do arquivo.

image

Lição: esse erro sempre vai acontecer e se repetir, então esteja preparado para definir um processo de reset de senhas nos ambientes de desenvolvimento, teste e produção.

Falha #3: Configurar incorretamente o GIT Client

Durante a instalação do cliente do Git, você configura um usuário e email para acessar o repositório. Se tiver máquinas diferentes, então deve repetir a configuração em todas as máquinas.

Falhamos nisso. Temos diversos emails registrados:

  • @microsoft
  • @hotmail
  • @live
  • [sem domínio]

Fabricio Sanchez, por exemplo, usou várias configurações de email diferente:

  • fabsanc@DESKTOP-GM6LNGT
  • fabriciosanchez@MacBook-Pro-de-Fabricio.local
  • fabriciosanchez@mbp-de-fabricio.guest.corp.microsoft.com

Configurar usuário e email errado tem um impacto muito baixo, mas gerou uma estatística interessante: a contribuição do Fabricio Sanchez foi apagar 165 mil linhas do projeto contra 135 mil adicionadas! Ele destruiu mais do que criou (merece um prêmio hehe).

image

Obrigado Fabricio Sanchez por todos os seus deletes no projeto!

image

Mas suspeito que, pelo fato de configurar o usuário/email errado, fez com que suas adições fossem ignoradas.

image

No final, isso não tira o mérito dele em ser um grande contribuidor do projeto ARDA.

Falha #2: Erro no arquivo Git Ignore

Outro erro comum é esquecer de configurar o arquivo do Git Ignore ( .gitignore) e incluir arquivos desnecessários no controle de versão. Entre os casos mais comuns estão os diretórios bin, out, obj, bower_components, node_modules.

O que há de errado em incluir as dependências do NodeJS (diretório node_modules)?

image

Simples: esse diretório tem 7302 arquivos que não precisam estar versionados no Git.

image

Mas por incrível que pareça, nosso time do ARDA não cometeu essa falha!!! O Visual Studio cria automaticamente o arquivo com as extensões a serem ignoradas e, por isso, o .gitignore estava correto desde o começo do projeto.

image

Entretanto, nós fizemos melhor: nosso estagiário (sempre ele!) adicionou o caminho do nosso projeto Arda.Main dentro do Git ignore.

image

Quando você faz isso, erros estranhos acontecem no projeto do Arda.Main:

  • Arquivo existentes: continuam “trackeados” pelo git e a atualização funciona
  • Arquivos novos: são ignorados pelo .gitignore e não são incluídos no projeto

Esse comportamento gerou erros aleatórios por um bom tempo. Determinadas modificações do Arda.Main funcionavam, outras não. Só fomos descobrir a causa do problema dias depois.

Falha #1: Falta de controle no master

Nossos repositórios (GitHub e VSTS) são protegidos por senha, mas qualquer um do time podia entrar no repositório e editar os arquivos. Pela descrição, dá para identificar algumas gambiarras. Por exemplo, commits correspondentes a Work in Progress (WIP) estão em vários lugares no histórico do Git.

image

Tem outros commits de “adjusting dockerfile again” ou “once again, trying to adjust the path” realizados direto na master.

image

Isso sem contar que usamos o repositório master para demonstrações no Tech Summit 2016.

image

A coisa fica feia quando aparece um root fazendo commit.

image

Até hoje não sei de onde veio esse commit, mas acho que foi alguém usando o VIM dentro de um Ubuntu para rodar os containers.

image

Entendo que diversas vezes usamos essa aplicação para demonstração em eventos. Entretanto, a nossa branch master ficou uma bagunça. Se esse projeto fosse crítico (mais crítico do que é atualmente), a gente deveria fazer Fork do repositório e trabalhar nele. Enfim, várias formas de organizar o acesso aos repositórios.

 

Conclusão

Seu time realmente sabe trabalhar com o Git?

No nosso caso, estamos (sempre) aprendendo…

E vocês? Compartilhem suas experiências ruins nos comentários - as boas experiências já conhecemos!

Comments

  • Anonymous
    July 25, 2017
    Gosto de utilizar uma abordagem por feature branchs e fazer um squash ao mergear na master.Com features muito grandes, pode fazer sentido separar em task menores, criando cada task como um commit separado.Sobre as senhas no repositório, costumo ter essas configurações separadas em um arquivo .env (não sei se existe suporte a ele no .net core) com alguns defaults definidos por padrão. Como em produção isso é gerenciado a partir de uma env var, esse .env contem só informações da maquina local.Em caso de commit com dados sensíveis, é bom tirar completamente do repositório. Uma forma pode ser utilizando https://help.github.com/articles/removing-sensitive-data-from-a-repository/
    • Anonymous
      July 26, 2017
      The comment has been removed