Posts com o tag ‘git’

Git – Dicas e truques

Terça-feira, 9 de março de 2010 por Mauricio de Amorim

No dia-a-dia utilizar recursos das ferramentas certas ajudam a agilizar nosso trabalho, tratando-se de controle de versões o Git tem diversos truques interessantes. Vou resumir de forma rápida alguns comandos que utilizo diariamente, a idéia é concentrar aqui novas dicas que forem aparecendo, então sugestões são bem vindas.

INSTAWEB

Um dos comandos mais úteis e interessantes que tenho utilizado ultimamente para fazer revisão de código ou para ter um histórico do projeto é o “instaweb” que inicia um servidor local onde podemos navegar (http://127.0.0.1:1234/?p=.git;a=shortlog) pelos commits e verificar as diferenças do repositório de uma forma bem simples e clara. É importante lembrar que ao subir o serviço o terminal fica liberado sendo necessário parar o servidor após o uso senão o processo continuará “rodando”.

git instaweb --httpd webrick
git instaweb --httpd webrick --stop

STASH

O comando “stash” é útil quando estamos trabalhando em algum código que ainda não está concluído e precisamos atualizar o projeto com as últmas atualizações, então colocamos nossas alterações em área isolada com git stash, atualizamos o projeto e aplicamos novamente nossas alterações com git stash apply. Exemplo:

git stash
git stash apply

AMEND

O comando “amend” é utilizado para corrirgir ou re-editar a mensagem do último commit desde que ele não tenha sido enviado para o repositório. Exemplo:

git commit -m "Alguma mensagem errada"
git commit --amend -m "Correção da mensagem"

GREP

Com “grep” encontramos palavras dentro dos arquivos do projeto, combinado com -n é possível saber em qual linha a palavra ou o conjunto delas foi encontrado.

git grep -n "palavra ou frase procurada"

RESET

Reset pode ser utilizado basicamente para duas situações, uma delas é desfazer um commit mantendo as alterações realizadas no código com “–soft” e para desfazer um commit completamente incluindo as alterações com “–hard”. Exemplo:

git reset --soft HEAD~1
git reset --hard HEAD~1

LOG

Temos diversas formas para verificar os logs de commits do projeto, abaixo alguns tipos de formatações para exibí-los. O último “shortlog” mostra a quantidade de commits do projeto.

git log --pretty=oneline --graph --all
git log --pretty=oneline --abbrev-commit
git whatchanged -n 1
git shortlog -s -n

Para complementar, uma dica para mostrar o branch atual no terminal. No arquivo ~/.bashrc no Ubuntu ou ~/.bash_profile no MacOS inclua as linhas abaixo, feche o terminal e abra novamente para que as alterações sejam aplicadas.

export PS1="\[\033[38m\]\u\[\033[32m\] \w \[\033[31m\]\`ruby -e
\"print (%x{git branch 2> /dev/null}.grep(/^\*/).first ||
'').gsub(/^\* (.+)$/, '(\1) ')\"\`\[\033[37m\]$\[\033[00m\] "

O terminal ficará assim:

user ~/projects/blog  (master) $

Referências:
http://gitready.com/
http://book.git-scm.com/
http://learn.github.com/p/intro.html


Post original:
http://mauriciodeamorim.com.br/2010/03/08/facilitando-o-trabalho-com-git/

.

RailsConf’09: painel do primeiro dia

Quarta-feira, 6 de maio de 2009 por Hisamoto

O RailsConf’09 começou de fato hoje, ontem foi o dia dos tutoriais, o Erich e eu assistimos as palestras, e agora tá rolando o Birds of Feathers, fizemos uma pequena pausa para escrever o post do dia de ontem que ficamos devendo e o painel do primeiro dia.

O keynote do evento foi do DHH, que falou sobre as mudanças que virão com o Rails 3 e sobre o segredo da produtividade dos desenvolvedores. O que achamos de mais importante, é que de fato o Rails aumenta a velocidade de desenvolvimento, mas se o desenvolvedor não for comprometido com a qualidade do código, renegociando e discutindo com o cliente as features que deverão ser entregues, os ganhos de produtividade com a tecnologia são perdidos.

Em seguida assistimos a excelente apresentação do David Chelimsk,Don’t mock yourself“. Ele mostrou o que são mocks e stubs, as diferenças entre eles, como usá-los de maneira apropriada e no final apresentou um novo projeto, ainda em desenvolvimento, o sttuble.

Ao mesmo tempo, ocorreu um painel com perguntas e respostas sobre o github. Na mesa estavam: Chris Wanstrath (GitHub), Tom Preston-Werner (GitHub), PJ Hyett (GitHub), Scott Chacon (GitHub) e Jon Maddox (Mustache, Inc). Eles responderam algumas questões sobre a estrutura de servidores do github, das features implementadas nos últimos meses e também sobre o novo plugin que integra o mercurial com o git.

A próxima apresentação foi de Ryan Singer da 37signals, que falou sobre os Fundamentos de UI para programadores:

  • Do ponto de vista do cliente, a interface é o programa inteiro
  • Comece pela interface, não pela implementação
  • A interface determina detalhes da implementação
  • Comece por um modelo que permita uma implementação e que faça sentido para os clientes
  • Domain Driven Design: os dois principais padrões são “model driven design” e “ubiquitous language“. A essência do livro está na forma como desenvolvedores e clientes podem colaborar para tornar o software melhor através de um modelo que faça sentido para todos.
  • Contraste: atrativo para os olhos, usar o contraste para determinar a importancia dos elementos da tela, pois isso impede que o leitor tenha que decidir o que é importante na interface que está sendo apresentada. A própria exibição já diz isso.
  • Ações: toda ação tem um princípio, um meio e um fim. Divida toda a ação nessas três partes e deixe isso claro na forma como a interface funciona.
  • Dividir as telas usando as convenções de REST.
  • Nomear os arquivos CSS e JavaScript usando as mesmas convenções dos templates (REST também).

Referência: “The Visual Display of Quantitative Information

De tarde, tivemos a apresentação do Ilya Grigorik (AideRSS Inc.), com o título: “Building a Mini-Google: High-Performance Computing in Ruby“, que falou sobre um algoritmo de classificação e sua implementação em Ruby, a apresentação foi baseada a partir de uma sequência de posts de Michel Nielsen.

Por último, vimos a apresentação do Scott Chacon (GitHub) sobre o git, “Smacking Git Around – Advanced Git Tricks“. A apresentação foi muito densa e apresentada rapidamente (o Scott Chacon fala numa velocidade impressionante!), e precisaremos revisar o material apresentado para escrever um post mais detalhado.

Referências:  apresentaçãoadvanced-git-cheat-sheet.

Evolução de Versionamento de Código: GIT

Segunda-feira, 27 de outubro de 2008 por AkitaOnRails

Criador do GitUma coisa que não é mais sequer discutível é: todo projeto de software, independente do tamanho, precisa de um sistema de versionamento de código. Isso é imperativo. Mesmo com apenas um desenvolvedor, controlar as revisões, versões e modificações no projeto não é algo que se possa considerar opcional.

O problema seguinte é: qual sistema de versionamento? A maioria dos desenvolvedores hoje está acostumado com CVS, Subversion ou mesmo Microsoft SourceSafe. Eles ajudam, com certeza, mas felizmente hoje sabemos que é possível fazer muito melhor, na realidade, ordens de grandeza melhor.

Linus Torvalds, o pai da kernel Linux, tinha esse problema: como controlar as colaborações de código vindas de centenas de programadores ao redor do mundo? No começo o controle era essencialmente manual, com pedaços de código sendo inseridos e testados manualmente. É um sistema altamente trabalhoso e que com o tempo tende a ser impossível. Logo no começo ele decidiu que não usaria nem CVS, nem Subversion. Resolveu optar por BitKeeper, um sistema essencialmente diferente por ser DISTRIBUÍDO. Essa é a palavra-chave. Mas nem ele era perfeito (além de ser comercial, o que irritou muitos da comunidade). Por isso, Linus olhou novamente o mercado e, na opinião dele, não havia nenhuma opção aceitável, portanto ele mesmo resolveu desenvolver seu próprio sistema de versionamento distribuído, de onde nasceu o GIT.

Não perca nosso WebCast no dia 7 de novembro, onde pretendo dar um resumo sobre as funcionalidades do GIT.

(mais…)

Futuro do Gerenciamento de Software: DVCS

Sexta-feira, 5 de setembro de 2008 por AkitaOnRails

Qualquer um que se entitule um profissional em desenvolvimento de software utiliza algum repositório de versionamento de código. É inevitável, mesmo quando se trabalha sozinho, para não se sentir inseguro sem um repositório onde seu trabalho é gerenciado.

Existem dezenas de produtos que fazem esse trabalho, incluindo o antigo CVS, seu sucessor Subversion (SVN), Rational ClearCase, Microsoft Visual Source Safe e outros. Esses sistemas tem uma coisa em comum: sua natureza centralizada. Existe um servidor, vários desenvolvedores necessariamente sincronizados com esse servidor, alguns com permissão apenas de leitura e um controle rígido no fluxo de código. 

Trocar um pelo outro não é uma mudança tão grande assim no fluxo de trabalho em geral. Esse tipo de sistema possui um grande calcanhar de aquiles: sua natureza centralizada. O servidor central é o mestre do seu código. Os desenvolvedores tem apenas as últimas versões atualizadas do código em sua máquina e nenhuma memória do histórico completo do projeto.

Perca o servidor e você perde todo seu histórico. Pior: você só consegue trabalhar se estiver online, se estiver offline se tornará muito improdutivo pela impossibilidade de realizar um ‘commit’ ao servidor. Pior ainda: se mudar de idéia no meio do desenvolvimento é um jogo de tudo ou nada: ou você retorna ao último commit (commit = escrita no repositório) que baixou do servidor ou manualmente reedita seus arquivos até o meio do caminho onde queria. Pior do pior ainda: comece a usar branches (galhos de desenvolvimento paralelo no mesmo código) no seu servidor e terá uma dor de cabeça sem tamanho para conseguir mesclar mudanças com seu tronco principal de desenvolvimento. Por isso mesmo pouca gente usa branches em sistemas centralizados e os que usam dependem de pessoas especializadas em cuidar dos problemas que ele apresenta.

Isso inibe completamente o trabalho de um programador. Um bom programador precisa testar, precisa experimentar, precisa fazer provas de conceito. Assim como qualquer bom artista, ele precisa ser capaz de rabiscar suas idéias, e até mesmo mudar de idéia no meio do caminho sem problemas. Com sistemas centralizados e restritivos você é praticamente obrigado a uma cultura de acertar da primeira vez, porque erros custam caro. E em consequência, o programador experimenta cada vez menos, tornando-se menos e menos produtivo e desmotivado. É quando programar se torna ‘apenas mais um emprego’ e não é mais divertido como antes, sem repositório algum.

Existe solução aos sistemas centralizados de versionamento de código? Com certeza sim. Continue lendo este artigo.

(mais…)


Switch to our mobile site