Como migrar um repositório git sem perder o histórico?

Faz alguns anos que comecei a trabalhar com git e na época escolhi o Unfuddle como serviço para meus repositórios privados e de clientes. Atualmente estou usando o Bitbucket para repositórios privados e o Github para projetos open-source, mas ainda tem alguns repositórios “legados” no antigo serviço.

Ontem retomei um projeto de uns dois anos atrás que estava no unfuddle e resolvi migrar para o bitbucket, mas como fazer esta migração mantendo todo o histórico de commit e branches do repositório?

Como migrar um repositório git sem perder seu histórico?

O primeiro passo é fazer o clone do repositório original, para pegar todas as informações necessárias:

git clone url-do-repositorio.git

Agora você tem todos os arquivos e históricos do repositório no seu repositório git local. Vamos remover o repositório remoto (no meu caso, o unfuddle). Neste exemplo o nome do repositório remoto é “origin”, substitua se necessário.

git remote rm origin

Agora vamos adicionar o novo repositório remoto (no meu caso, o do bitbucket):

git remote add origin [email protected]:gserrano/meurepositorio.git

Para finalizar, vamos dar um push de todos os dados do seu repositório local (recuperados do seu antigo repositório remoto) para o novo repositório remoto:

git push -u origin --all
git push -u origin --tags

Pronto, assim você não perde o histórico do seus repositórios GIT e tem liberdade para migrar de serviço se necessário.

Você também pode gostar:

Como ignorar arquivos no Git

Faz algum tempo que estamos usando o Git para fazer deploy nos projetos da GS Solutions e um dos cuidados que isso exige é manter os arquivos de configuração do servidor de produção intactos.

Como ignorar arquivos no Git?

.gitignore

O modo mais fácil de ignorar arquivos no repositório é através do gitignore. O gitignore é uma lista que ignora qualquer arquivo que ainda não foi acompanhado pelo repositório através do git add. Veja a documentação (en).

Quando um arquivo já foi adicionado ao sistema de tracking muitas pessoas acham que o gitignore não está funcionando. Na verdade você precisa remover o arquivo do índice para que repositório pare de monitorar aquele arquivo.

Como fazer usar o .gitignore para um arquivo que já foi commitado?

Se um arquivo já foi adicionado e commitado não adianta somente adicionar ele no seu .gitignore, você precisa primeiro remover ele do sistema de tracking do git. Para isso utilize o comando abaixo:

git rm --cached config.json

No exemplo abaixo o git vai remover o cache/tracking do arquivo config.json e se ele estiver no .gitignore do repositório ele não será mais indexado nos commits.

Como ignorar um arquivo do repositório no git

Para arquivos de configuração eu prefiro que eles estejam no tracking do git, pois eles são parte do projeto e devem estar no repositório. Mas apesar de estarem no repositório, não quero enviar para o repositório minhas alterações locais. Para isso podemos pedir para que o git considere que determinados arquivos não foram alterados alterando o índice do git manualmente.

Mantendo o exemplo do arquivo config.json vamos supor que ele não está no seu gitignore e você fez alterações para o ambiente de desenvolvimento e não quer correr o risco de commitar estas mudanças.

Diga para o git considerar que aquele arquivo não foi alterado com o seguinte comando:

git update-index --assume-unchanged config.json

Agora seu repositório vai considerar que este arquivo não foi alterado mesmo que você atualize ele inúmeras vezes. Se você precisa dar commit em alguma alteração no arquivo é só remover o status de “não alterado” deste arquivo no índice do repositório com a seguinte linha de código:

git update-index --no-assume-unchanged config.json

Para arquivos de configuração eu prefiro utilizar o –assume-unchanged. Deixo o .gitignore para arquivos de uploads do projetos, cache e demais arquivos que não fazem parte do projeto.

Como vocês lidam com arquivos de configuração no repositório? Deixe dicas nos comentários!

Tutorial – deploy com git no Ubuntu Server (AWS EC2)

Semana passada configurei um servidor novo para um cliente (GS Solutions) e optamos por usar AWS para este projeto (leia meu comparativo entre Locaweb e Amazon) e fiquei encarregado de configurar o servidor.

O servidor será exclusivo para um projeto e optei por fazer todos os deploys com git para manter o controle do código que vai para o ar e automatizar o deploy. 

Já fiz isso para o And After e para o Eu Compraria e lembro que foi um pouco complicado permitir o git pull através do apache (usuário www-data no Ubuntu Server).

Mas uma vez feito, não tem erro. este é um tutorial de 4 passos simples para configurar seu servidor e permitir deploy utilizando o Git.

O tutorial foi testado em servidor Linux (Ubuntu Server) e pode precisar de ajustes simples para outros servidores.

1. Instale o git no servidor

Sem nenhum mistério:

sudo apt-get install git

2. Crie uma chave para o user www-data

Aqui está o segredo de permitir o deploy diretamente por comandos do Apache, que utiliza o usuário www-data.

No meu caso o deploy é feito através de um ambiente fechado do sistema, onde através do PHP o git pull é executado. O repositório em questão será onde está configurado o domínio do serviço, então quando o pull é executado na branch master acontece o deploy.

Para criar uma chave ssh para o user www-data você vai precisar executar o ssh-keygen com este usuário, para isso execute no servidor:

sudo -u www-data ssh-keygen

E gere uma chave para este usuário, com ou sem senha. Na home deste usuáriuo (no Ubuntu Server a home do usuário www-data normalmente é /var/www/) você terá uma pasta .ssh onde ficarão as chaves.

3. Libere as chaves no seu repositório

Agora é só cadastrar as chaves no seu repositório para que seu www-data do servidor tenha acesso ao repositório, no terminal do servidor digite:

vi ~/var/www/.ssh/id_rsa.pub

Cadastre a chave pública no seu repositório e pronto, você está pronto para acessar seu repositório diretamente do seu servidor.

4. Clone o repositório

Agora no seu servidor você pode executar os comandos do git com o usuário www-data, por exemplo:

sudo -u www-data git clone meurepositorio.git

Lembre-se que para automatizar o seu deploy o domínio configurado no Apache (sites available) deve ser o seu próprio repositório.

Para fazer o deploy você pode escolher a forma que achar melhor. Eu executo os comandos com a ajuda do PHP em um ambiente fechado: assim o php (www-data) executa o git pull no repositório do seridor.

Não sei se existe (e qual é) o risco do user www-data ter uma chave pública cadastrada no repositório, mas o ideal é que este usuário tenha acesso apenas de leitura no seu repositório.

Leia também mais algumas dicas e utilidades para seu servidor:

Git – enviando uma branch local para o repositório

Você está implementando uma feature nova no sistema e para não prejudicar nenhum deploy da branch master criou uma nova branch na sua máquina, vamos supor que o nome desta branch é nova-feature.

Acontece que chegou um ponto que seu colega também precisa acessar sua branch para fazer novas implementações, então você precisa enviar a nova-feature do seu repositório local para o repositório remoto, onde qualquer pessoa que trabalhe no projeto possa acessar. 

Dando push da branch para o repositório remoto

git push origin nova-feature

Agora sua branch estará disponível no repositório remoto, e para seu colega baixar ela é simples:

git checkout –track origin/nova-feature

Agora você e seus colegas podem trabalhar em uma branch separada para aquele nova feature sem prejudicar a menutenção do código master! 🙂