Meu ambiente Git

Há essas várias ferramentas para resolver o problema de versionamento de código-fonte. Lembro da época em que eu usava o svn, principal ferramenta do modelo centralizado, onde a ferramenta não me ajudava muito mais além do básico e eu usava o RabbitVCS para ter uma interface mais amigável, em contraste com meu uso atual da ferramenta git, onde eu exijo que meu ambiente não tenha nenhuma ferramenta que esconda a complexidade da Git, pois eu quero que todos os seus recursos estejam a minha disposição, sem risco de que qualquer um deles esteja ligeiramente menos poderoso. Após tanto tempo usando git, decidi que era hora de dedicar um post no meu blog sobre a ferramenta, descrevendo qual subconjunto do mesmo eu mais utilizo, algumas dicas, algumas explicações e mais um pouco.

Caso você ainda não saiba como utilizar a ferramenta git, sugiro que você utilize o minicurso interativo sem enrolação do Github, para aprender de forma acelerada e estar apto a se beneficiar dessa ferramenta o quanto antes.

Para reforçar os conceitos, é legal, além da perspectiva prática do treinamento, experimentar visualizações para reforçar os conceitos e talvez ter alguma epifania. Recomendo visitar o site http://www.wei-wang.com/ExplainGitWithD3/ e praticar nele os comandos que você acabou aprendendo para visualizar conceitos do git.

Um resumo muito bem sintetizado do fluxo de trabalho necessário para contribuir com um típico projeto hospedado no Github existe no blog do Dusty Phillips.

Meus jeitos

  • Desde que aprendi as principais ideias de como o bitcoin funciona, passei a usar o comentário “Genesis commit” no commit inicial de novos projetos, em referência ao bloco genesis.
  • git pull é aquele comando que fere o princípio KISS, por apenas uma tarefa a mais. O comando simplesmente adquire modificações que ocorreram no branch remoto e depois mescla ela com o branch atual. O problema é quando o branch remote diverge do seu branch local. Daí lembro de ter lido alguns comentários que git pull era ruim, mal projetado e você não devia usar. Advogavam que você devia usar git fetch, para depois decidir se iria querer fazer git merge ou git rebase.
  • E naqueles momentos em que você quer submeter as modificações feitas em cima do mesmo arquivo, porém usando commits diferentes, é que você vai apreciar o poder do comando git add -p. Eu descobri esse recurso através do post de humilde título “git add -p: The most powerful git feature you’re not using yet“.
  • Há também os momentos em que esqueceu de uma besteria no último commit e gostaria de modificar isso.
    git commit --amend

    é o caminho.

  • E caso você não saiba, git reconhece intervalos de commit, então caso você queira, por exemplo, verificar o log de todos os commits entre os commits 6d09f7ba08871d89ee5b43bf27d547a521155a2f e d2a3e06735ebf74bc88d355875e7d04ff8476eb6 (que no repositório do Tufão são os commits referenciados pelas tags 1.3.0 e 1.3.1, respectivamente), basta usar o comando:
    git log 6d09f7ba08871d89ee5b43bf27d547a521155a2f~...d2a3e06735ebf74bc88d355875e7d04ff8476eb6

    O tio (~) após a referência ao primeiro commit indica que eu quero referenciar o commit-pai daquele commit. Eu fiz isso, porque no git, o primeiro commit do intervalo é aberto (isto é, ele é excluído do intervalo), mas como eu também quero ver o log desse commit, especifico o commit-pai no intervalo.

  • E o item anterior me lembra que eu costumo assinar digitalmente minhas tags, usando o comando git tag -s, para me beneficiar das garantias de autenticidade (acho que é essa a garantia que eu consigo, qualquer coisa me corrijam aí).
  • Ah, e naqueles momentos em que você não trata seu repositório com carinho e acaba perdendo o poder de usar git merge entre dois branches que irão/iriam compartilhar vários commits, git cherry-pick é o comando que vai “salvar” seu(s) dia(s).
  • Não sabe como tratar seu repositório com carinho? Dê uma lida no post “A successful Git branching model” do Vincent Driessen.
  • Está trabalhando em um projeto que não suporta shadow build (aka out of source builds) e quer ter uma área de trabalho limpinha novamente? git clean -f -x -d resolve.
  • “Quais são as modificações que vão entrar quando eu fizer git commit?” é resolvido adicionando o argumento –staged ao comando git diff:
    git diff --staged
  • “véi, tem como você mesclar tal branch no teu repositório?” chega justamente quando você está trabalhando naquele commit por algumas horas já e não quer perder as modificações feitas na área de trabalho (staging area). git stash pode ajudar.
  • Ah, e que commit safado quebrou o sistema? Até nisso o git ajuda com o git bisect.
  • E essa linha suspeita nesse arquivo, quem colocou? git blame para revelar o sabotador.
  • Será que meu commit finalmente já foi lançado em uma versão estável?
    git tag --contains

    irá ajudar. E analogamente, também há o

    git branch --contains

    .

  • Também uso o git remote para administrar branches remotos e acho que não há muito mais que issogit remove -v para mostrar suas URLs sem a necessidade de qualquer atividade na rede.
  • E caso esteja procurando por alguma forma de trabalhar com git e bzr, talvez ache o projeto git-fc útil.
  • Agora, para aumentar minha produtividade, eu uso as fantásticas capacidades (como completadores automágicos e RPROMPT não-muito-intrusivo) do zsh, o shell mais fantástico de todos.
  • E caso queira compartilhar o link para alguma página do GitHub, lembre que essas páginas estão em constantes mudanças, então use o atalho de teclado “y” para pegar o link permanente.
  • E para quem estiver usando ArchLinux, tenho uma dica legal para trabalhar com PKGBUILDs.
  • E para procrastinar enquanto o projeto compila, também há a ferramenta gource para visualizar o histórico do projeto e o giggle para navegar na história sem a ajuda do GitHub.
  • E caso você ache que o git é muito patriarcal, você não está sozinho!

Segurança no Git

Antes das chaves assimétricas, não detínhamos o poder de verificar a identidade muito bem, mas ainda bem que elas foram descobertas. E felizmente a Git permite anexar assinaturas a tags/commits. Logo, você pode colocar seu repositório git até através de uma rede anônima como a Tor e as pessoas ainda poderão confiar na autenticidade da origem dos commits, e sem comprometer o autor, que não mais precisa da palavra de alguém para atestar sua identidade.

Como o sistema distribuído que é, o git não usa números de revisões para identificar os commits. O valor de uma função hash é utilizado como identificador. A entrada de tal função hash é derivado do conteúdo do próprio commit, como as modificações que o commit introduz, e o identificador do commit pai. Isso significa, que, caso você modifique o conteúdo de um commit, o identificador dos commits filhos também são modificados. Essa característica é uma grande proteção contra tentativas de forjar o histórico de um projeto, pois, mesmo que um sistema na rede seja invadido, os nós que usem seu repositório irão detectar (e rejeitar) tentativas de forjar o histórico pelo atacante.

Há essas várias pequenas decisões de projeto que foram feitas e que, diferente do que alguns pensam, não foram feitas com objetivos patriarcais.

Fim

Posso finalizar afirmando que a git conquistou espaço no meu conjunto de ferramentas.

EDIT (2015/06/22):

Encontrei um texto útil que ensina a espremer vários commits em um único commit. Eu teria usado isso há poucas semanas atrás quando estava trabalhando com o Travis, caso tivesse ciência de sua existência, mas acabei fazendo manualmente.

Tags:, , ,

Comentários (with MarkDown support)

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 )

Imagem do Twitter

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

Foto do Facebook

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

Foto do Google+

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

Conectando a %s

%d blogueiros gostam disto: