Tag Archive | git

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.

Anúncios

Fixing Tufão (accidental) ethical mistakes

Today I’ve spent some minutes of my time to fix the metadata of the Tufão git repo. The issue makes difficult to gather who author owns which lines of the code, which can be a problem if you want give merit for the real coders (maybe this is related to ethics) and if you want to contact the authors later for actions that only can be done by the copyright owner (eg. change license). This incorrect info was introduced by misuse of the git tool.

First, I must admit that I was wrong and the issue was entirely caused by ignorance of my git’s knowledge at the time. The issue was not made on purpose. You can see an example here, where I mentioned the original author on the commit message to give the appropriate credit (my intent). But there are also cases where I failed to even make such mention.

Every commit you make using the git tool has an associated author and if you don’t specify the author explicitly, git will use the global config. This metadata is used by commands such as git shortlog -s and git blame. The solution is simply: Just set the author explicitly using the –author argument.

Now the git repo history mentions authors such as Paul Maseberg and Marco Molteni.

Lastly, but not least, I want to let you know that I believe the problem is solved. If you find something that I missed, just fill a bug on the github and I’ll fix it.

%d blogueiros gostam disto: