Tag Archive | subversion

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.

Meu ambiente de desenvolvimento em 7 itens

Mesmo sem terem me incluído na brincadeira, até porque sou blogger novato, resolvi participar, pois a ideia é interessante.

Regras:

  1. Escreva sobre 7 itens de seu ambiente de trabalho – fale sobre qualquer ponto que quiser
  2. Indique de 3 a 5 pessoas para que possivelmente façam um artigo sobre seu ambiente

Meu ambiente

Começando pelo ambiente então.

Archlinux

Para responder com qual sistema eu me sinto mais confortável eu não preciso pensar muito para responder que é o GNU/Linux. Mas dentre as várias distribuições que eu testei (openSUSE, Debian, Ubuntu, Dreamlinux e alguns derivados irrelevantes), a única distribuição com a qual eu não tenho problemas sérios é a Archlinux.

O principal problema que eu enfrentava nas outras distribuições sempre acabava se resumindo ao gerenciamento de pacotes. Com o Ubuntu, por exemplo, eu sempre acaba configurando vários PPAs para ter as últimas versões disponíveis do VLC, Firefox, OpenOffice.org, ou mesmo instalando o binário fornecido pelos desenvolvedores, no caso do SDK do Qt, por exemplo. Essa prática sempre acabava me causando problemas. Tudo isso sem contar com o meu orgulho de programador ao ver que o meu sistema em si já era uma gambiarra!

Afinal, qual o ponto em ter um gerenciador de pacotes se no final você acaba gerenciando os pacotes por si próprio? A situação só se agravava com o passar do tempo, devido ao perfil de usuário no qual eu me encaixo. Um certo dia então, encontrei o Archlinux.

O problema dos repositórios e pacotes desatualizados foram resolvidos quando comecei a usar o Archlinux. O problema básico de versões velhas foi resolvido com o rolling release. Não há versões da distribuição, há versões dos pacotes, e se quiser um sistema atualizado é suficiente atualizar os pacotes. Para essa ideia ser viável, o sistema precisa de um gerenciador de pacotes robusto, e certamente posso afirmar isso sobre o pacman, pois a distro foi criada em 2002 e o gerenciador ainda está fazendo o que foi feito para fazer sem grandes dificuldades.

Outra vantagem do Arch é que eu finalmente posso instalar o zsnes no meu sistema 64-bit, pois o sistema possui um repositório multilib, com o propósito de facilitar tarefas como essa.

Ainda em repositórios, o Archlinux possui um grande repositório oficial, e o AUR, que sob a minha visão é um projeto que resolve o problema que os PPAs, do Ubuntu, deveria resolver. Graças a grande abrangência desses dois repositórios, e as políticas de gerenciamento adotadas pela comunidade, eu não mais preciso utilizar técnicas obscuras para instalar algum aplicativo.

Como se todas essas facilidades ainda não fossem o bastante, o pacman também é flexível o suficiente para que eu possa configurá-lo para utilizar o Aria2, ou algum outro, para efetuar o download dos pacotes.

MPD

MPD é um Media Player para quem não conhece. Primeiramente, é o único modo decente que encontrei de controlar um media player através do terminal. Mas uma escolha minha geralmente envolve mais que um motivo, e alguns dos outros motivos para escolher esse media player são os incontáveis modos de controlá-lo.

Tenho uma interface gráfica completa tradicional, uma interface para o firefox, uma interface web, uma interface para meu symbian (controlar seu media player no conforto do sofá é essencial =p) e ainda posso combinar o cliente linha de comando com vários outros aplicativos (associando atalhos de teclado no gnome ou no e17, por exemplo).

Além de toda a flexibilidade fornecida para controlar o MPD, posso configurar também para onde irá o som. As opções vão desde o sistema ALSA/PulseAudio (direto para a caixa de som), até streaming web via HTTP simples ou passando pelo Icecast. Adicionando o sistema JACK a combinação, as possibilidades são tentadoras.

Firefox

Antes não-tão-essencial, eu alternava entre o Chromium e o Firefox, pois para mim não havia muita diferença entre os dois. Mas a versão 4 do Firefox veio com um recurso que mudou minha opinião, o grupo de abas. Usando desse novo recurso, eu finalmente consigo navegar na web sem me perder, mesmo tendo em torno de 25 abas abertas durante a maior parte do tempo. Há um grande conjunto de pequenas mudanças que fizeram a diferença também, mas para mim essa funcionalidade é única.

Gmail

E o que seria de minha vida sem a google e seus produtos com seus níveis de qualidade que constantemente aumentam? Usando alguns recursos do labs (como várias listas de email, por exemplo) eu finalmente consegui organizar minhas tasks. E integrado com o Google Agenda, não preciso mais me lembrar de compromissos. São tantas funcionalidades. Não há nenhum produto igual.

Pidgin

Durante a realização de suas tasks você está vulnerável a sofrer stress, ainda mais quando você está trabalhando com tecnologias muito novas ou chatas. Um IM é essencial para diminuir o nível de stress e manter seu nível de produtividade. Já testei vários IMs, e apesar de não gostar do Pidgin, ele é o único que suporto.

Emacs

Costumo trabalhar com projetos escritos em diferentes linguagens, e não vi ainda uma IDE que seja suficiente para mim e suporte bem todas as linguagens com as quais trabalho. Diante dessa situação, um editor de textos avançado como o Vim ou o Emacs, é o que pode me ajudar. O primeiro que usei foi o Emacs, e eu até tentei esquecer o Emacs e usar o vi, mas eu me adaptei bem ao paradigma Emacs, e é ele que eu sei usar (e muito mal, se levar em consideração o tempo de uso e meu conhecimento).

Subversion

O sistema de versionamento que mais uso é o subversion. A maioria dos projetos em que eu trabalho o adota e ele é muito fácil de usar, principalmente quando tem uma interface web poderosa em conjunto. Fiz até algumas apresentações sobre ele e convenci várias pessoas a utilizá-lo, e isso no primeiro semestre de UFAL.

Minhas vítimas

Repasso a tarefa para:

%d blogueiros gostam disto: