Estrutura interna do Git – Parte 2

Não exatamente uma sequencia, porém ainda ficaram alguns pontos que eu acho muito interessante do Git que levarei em conta quando precisar desenvolver algo.

Além dos comandos normalmente utilizados, que para quem utiliza o bash completion possui autocompletamento, existem vários comandos “ocultos”, porém documentados. O comando git cat-file do texto anterior é um exemplo. Isso ocorre pela forma que os comandos do Git foram feitos, existe um conjunto de comandos básicos para executar pequenas tarefas, assim como a filosofia UNIX (uma única coisa, porém bem feita). Ou seja, comandos para adicionar arquivos na estrutura do Git, recuperá-los, calcular diferenças, aplicá-las, lidar com braches e outros.

No capítulo 9 do Pro Git temos um exemplo melhor desses comandos, e até como fazer um commit sem utilizar o git commit. Isso mostra que até mesmos comandos internos são implementados utilizando outros comandos, dividindo o problema em partes menores.

Agora imagina que você está desenvolvendo um sistema que utiliza alguma parte do Git, como o GitHub para visualizar o código, ou o OpenShift para receber o código e fazer deploy da aplicação. Como existem várias operações você não precisa desenvolver algo para ler a estrutura do Git, pode simplesmente reutilizar esses comandos, ou seja, a API já está pronta, basta adaptá-la para a sua linguagem.

Porém não precisamos ir muito longe para tirarmos proveito disso. No meu texto Verificador de estilo de código no VIM, comentei sobre os verificadores de estilo e podemos utilizá-las em conjunto com o Git. Imagine que seu projeto tem um estilo que todo o código deve ser seguido, porém as vezes alguém acaba deixando passar um espaço a mais, troca espaço por tab. No Git podemos fazer a validação do código é permitir o commit apenas caso ele esteja de acordo com o estilo.

Para fazer essa verificação precisamos utilizar outro recurso chamado de Hook, que são scripts executados em determinados momentos (consulte o capítulo 7.3 do Pro Git). Inicialmente fiz a verificação apenas local para lembrar caso tenha alguma coisa fora do padrão, mas ainda possível forçar o commit se assim for desejado. Como os projetos tinham vários arquivos fora do estilo, queria verificar apenas os alertas referentes as minhas mudanças, até por questão de performance, se eu não alterei o arquivo não preciso ser lembrado que ele tem algum erro, deixando a saída até menos poluída e posso verificar todos os arquivos caso esteja atrás de erros.

Primeira coisa, preciso saber quais os arquivos que foram alterados no commit, para tanto utilizei o comando git diff –raw –cached, uma informação um pouco mais bruta dos arquivos selecionados com git add. Porém eu posso ter executado o git add e alterar o arquivo novamente antes de fazer o commit, então não posso simplesmente fazer a validação do código do arquivo no diretório, para isso utilizei a hash do git diff para pegar o arquivo que será commitado com git show e fazer a validação em cima dele.

Quem quiser ver como tudo ficou, tenho esse código no meu GitHub (https://github.com/eduardoklosowski/codelint), está escrito em Python, porém tenho que trabalhar melhor a documentação e ter decidido fazer tudo em inglês não ajudou, porém assim que estudar melhor as formas de documentação e opções que tenho para compartilhá-la irei fazer isso, mas se alguém for usar e tiver alguma dúvida deixe nos comentários, até ficarei feliz em saber que alguém está utilizando (testando). Report de bugs, melhorias no código ou funcionalidades novas são bem vindas. Pode ser utilizado com outras ferramentas de controle de versão, só não tenho conhecimento e necessidade para isso agora, mas pode ser facilmente desenvolvido já que o Git foi feito a parte também.

Depois de criar os arquivos de configuração em ~/.config/codelint, preparo tudo para o commit e executo git codelint, isso iniciará os validadores. Um detalhe que todos os comandos no PATH que começam com git-, exemplo git-codelint podem ser executados como comandos do git dessa forma e com autocompletamento.

Agora só falta colocar no Hook executado antes do commit, o pre-commit, seu conteúdo é simples.

#!/usr/bin/env bash
git-codelint

Caso queira verificar os arquivos antes de commitar posso executar git codelint e quando der o git commit será verificado, se tiver algum erro o commit será interrompido para correção, ou posso forçar com git commit -n.

Anúncios

Comente

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s