Tag Archive | github

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.

Por que eu migrei o projeto Tufão para o github?

Há um projeto de software livre que eu iniciei chamado Tufão. O objetivo do projeto era tornar a linguagem C++ amigável para desenvolvimento web. A diferença é que por muito tempo desenvolvimento web fazia o contrário de me atrair e isso só mudou depois que conheci o Node.js, que acabou influenciando na arquitetura do Tufão. Há muitos e muitos meses atrás, o Tufão era hospedado no Google Code, mas devido a alguns motivos eu acabei migrando para o github.

Motivos da mudança

Eu migrei o Tufão para o github pelo simples motivo de que a linguagem de marcação usada para customizar a página inicial do projeto no Google Code não suporta listas aninhadas muito bem.

  • Listas
    • Profundamente
      • Aninhadas

O motivo da migração pode parecer decepcionante, então eu vou dizer que outro motivo da migração é que eu finalmente pude deixar a documentação do projeto online, pois o Github gera um site online para você a partir do branch especial gh-pages e uma documentação online é algo que eu queria muito. A tentativa de converter a documentação gerada pelo Doxygen para a wiki do Google Code foi um resultado bem ruim. E na época que eu usava o Google Code acabava oferecendo a documentação gerada como uma opção download, uma tarefa bem inconveniente. E essa gambiarra nem funcionaria hoje em dia, pois “devido a mal uso da funcionalidade”, a Google desativou a funcionalidade.

Experiência pós-github

O primeiro impacto que o github trouxe para o projeto, é que antigamente você não tinha um jeito fácil de oferecer o download dos binários do projeto, então eu parei de oferecer binários para a plataforma Windows (que a partir de agora você tem que gerar por sua conta), assim como os usuários pararam de encher meu saco com essa tarefa que pode ter uma explosão combinatória, pois o ambiente de desenvolvimento pode variar muito entre sistemas diferentes.

O segundo impacto que o github trouxe, é que ele mapeia muito bem a natureza distribuída do git e tornou-se muito fácil contribuir para o projeto. Você pode conferir no próprio github que há pessoas modificando cópias próprias do projeto, assim como houveram outros contribuidores além de mim.

O terceiro impacto que o GitHub trouxe foi me deixar viciado em MarkDown. É o requisito #1 para caixas de textos de qualquer serviço na web. Eu uso gists secretos para manter minhas listas de tarefas, pois há suporte a MarkDown, eu escrevo minhas propostas usando MarkDown, eu faço slides para apresentações usando MarkDown, eu uso e abuso do MarkDown…

Uma característica que eu notei é que o bug tracker do Google Code aparentava ser mais completo, mas para um projeto do tamanho do Tufão, isso ainda não impactou negativamente o projeto. Só para citar como exemplo, eu podia anexar arquivos arbitrários a comentários que eu fizesse aos bugs registrados, no Google Code. No GitHub eu só aprendi a anexar imagens. Acho que até o bugtracker do serviço launchpad é mais completo e acho que o github não vai mudar, pois essa simplicidade torna o serviço dele mais “user-friendly”, que é a mesma desculpa para eles ignorarem as reclamações do Linus Torvalds.

%d blogueiros gostam disto: