Dicas e truques do Git-svn: use o Git mesmo que sua equipe não use

Nicola Paolucci
Nicola Paolucci
Voltar para a lista

Antes de entrar na Atlassian, eu estava trabalhando em vários projetos que ainda usavam o Subversion (SVN) como seu sistema de controle de versão. Eu já havia mudado para o Git anos antes e queria continuar usando esse sistema o máximo possível.

Felizmente, eu poderia usar o git-svn: uma solução muito completa para interagir com repositórios Subversion sem sair do conforto do conjunto de ferramentas potentes do Git. Mas existem pegadinhas. Esta publicação presume que você já conheça um pouco o git-svn e saiba como interagir com um repositório SVN que usa essa solução.

A lista abaixo contém todos os truques e dicas que tive que pesquisar e integrar no meu fluxo de trabalho para continuar feliz usando o Git em conjunto com o SVN. Divirta-se!

Configuração dos arquivos para ignorar

Você deve verificar se o Git ignora os mesmos arquivos que o SVN. O truque mais simples é anexar a lista de arquivos svn:ignore ao arquivo Git exclude padrão:

git svn show-ignore >> .git/info/exclude

Um método alternativo é o mágico update-index:

git update-index --assume-unchanged files to ignore

Este é um bom truque, que eu usei bastante no ano passado. Se precisar de mais informações, dê uma olhada nesta publicação no Stack Overflow. Se você usar o último método, como descobrir mais tarde que um arquivo foi ignorado no Git? Você pode usar essa opção:

git ls-files -v | grep ^[a-z] | sed -e 's/^h\ //'

OBSERVAÇÃO: update-index é um comando avançado que manipula o índice direto, use-o com cuidado!

Repositórios grandes de clone superficial

Eu trabalhei com bases de código SVN acima de 1,5 Gb para um checkout completo. Em cenários semelhantes, fazer o checkout de todo o histórico de commits por commit — do jeito que o git-svn faz — pode ser demorado, já que o repositório é simplesmente muito grande. A maneira de contornar esse problema é criar um clone superficial do repositório; em vez de copiar todo o histórico do projeto, basta copiar os últimos n commits e prosseguir a partir daí. Por exemplo:

git svn clone -s -r604:HEAD http://nick@svn.xxxxxx.com/repos/ -T trunk -b branches -t tags

Onde "604" deve ser substituído pela revisão anterior que você quer manter. Referência obrigatória do Stack Overflow.

Se você adicionou as pastas .svn por engano no Git

Mais cedo ou mais tarde, você vai encontrar alguns obstáculos. Por exemplo, uma vez que não usei o git-svn, fiz o checkout de um projeto do SVN, mas queria fazer meu próprio rastreamento usando o Git. Naquela época, adicionei por engano as pastas de .svn no índice (área de staging) do git. Como manter esses arquivos importantes, mas removê-los do índice? Complicado! Veja como cancelar o rastreamento de arquivos sem realmente excluí-los do git:

git status -s | grep .svn | awk {'print $3'} | xargs git rm --cached

A palavra-chave aqui é --cached, que opera no índice e não no diretório de trabalho. Há uma explicação muito clara neste capítulo sobre progit.

O que fazer quando um repositório SVN é movido

Quando um repositório SVN é movido (ou quando você precisa fazer o acesso via VPN e fazer algum tunelamento inteligente que vai mudar o endereço), você deve seguir o procedimento correto para evitar um novo checkout completo. O primeiro método listado na wiki do Git é aquele com o qual eu tive sucesso consistente. Direto do wiki, aqui está a parte importante:

  • Edite a URL svn-remote em .git/config para apontar para o novo nome de domínio ou endereço IP.
  • Execute git svn fetché preciso o fetch de pelo menos uma nova revisão do svn!
  • Mude a URL svn-remote de volta para a URL original.
  • Execute git svn rebase -l para fazer um rebase local (com as alterações que vieram com a última operação de fetch).
  • Mude a URL svn-remote de volta para a nova URL.
  • Execute git-svn rebase. Agora deve funcionar normalmente de novo!

Essa ação só vai funcionar se a etapa de git-svn fetch realmente fizer o fetch de alguma coisa!

Conclusão

Trabalhar com o Git é uma alegria para mim. Você tem liberdade e controle totais, você pode fazer commits infinitamente, reformatar os commits, realizar o squash de commits limpos e criar ramificações como louco. Você pode trazer a mesma alegria com você, mesmo que tenha que interagir com o SVN. Foi o que eu fiz por dois anos seguidos e funciona muito bem.

Quando toda a sua equipe estiver pronta para migrar para o Git, é bom ter um guia passo a passo abrangente. Então a gente escreveu um:

o guia de migração fácil do SVN para o Git!

Pronto(a) para aprender Git?

Tente este tutorial interativo.

Comece agora mesmo