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!

O que marcenaria me ensinou de front-end

Fazia tempo que eu queria aprender e praticar algumas coisas a fim de mudar um pouco meu modo de pensar, escolhi meditação, marcenaria e bonsai. Arrumei tempo para estudar e praticar os três. Tentar aprender um pouco mais sobre marcenaria/construção foi um dos fatores que me levou a voluntariar no TETO.

Acho que foi no ZOFE sobre carreira em front-end que o Zeno e o Daniel (recomendo que você ouça todos os podcasts destes caras) fizeram uma comparação entre o trabalho de artesãos e dos desenvolvedores front-end: desenvolver um trabalho único e dedicar-se a entregar o melhor de si em uma “peça”, ou no nosso caso, a uma interface. 

Eu e a marcenaria

Apesar de ainda não saber praticamente nada de marcenaria ela já me ensinou bastante. Sei pregar, sei serrar, sei lixar. Tudo isso mais ou menos, e bem mais para menos.

Comecei a praticar faz pouco tempo e para começar resolvi reciclar, restaurar e pintar um caixote de feira para a Bia transformar em um criado mudo ou em um caixote para guardar coisas. Ela (ou o pai dela) já haviam arrumado o caixote e em um final de semana comprei lixas e resolvi começar.

Caixote de madeira

Quem sabe um dia?

Lixei uma vez e o caixote ficou bem mais bonito do que estava antes. Foi uma hora de calma, café e o cheiro de madeira. E neste ponto comecei a refletir sobre minha ansiedade (este era um dos motivos de eu procurar atividades offline) e fazer comparação com o desenvolvimento web e a marcenaria.

Depois de pouco mais de quase três horas de trabalho e muita lixa gasta, eu poderia considerar o caixote pronto. As partes internas lisas como nunca estiveram, os cantos arredondados (não é piada com front-end) e minhas mãos secas da lixa e pó. O resultado depois disso foi que o caixote ganhou outra cor, quase sem nenhuma “sujeira” externa visível e pronto para receber uma camada de verniz e se tornar parte da decoração de casa.

Já estava tarde, eu estava cansado, fui dormir e retomei o trabalho no dia seguinte.

Não comecei pela pintura, peguei novamente a lixa e vi detalhes que passaram despercebidos no dia anterior. Não hesitei em recomeçar a lixar, a melhorar o acabamento de algumas pontas e deixar tudo mais simétrico. Mais lixa, mais pó e o resultado melhor do que o anterior, repeti o ciclo algumas vezes, desta vez de forma mais rápida. 

Pintura e ferramentas

Satisfeito com o estado do caixote, fui verificar o que precisava para fazer a pintura. Desisti de passar apenas verniz e resolvi pintar a caixa.

Como eu não tinha a base correta para madeira usei uma outra base que, em teoria, deveria funcionar pois era bem parecida com a base para madeira (dizem…). 

Ficou horrível. Estraguei o caixote. 

A madeira “chupou” toda a tinta que eu passava, a cada passada o rolo secava e a madeira adquiria um esbranquiçado apático, bem pior do que quando estava apenas lixada.

O caixote esta lá, esperando para receber a finalização.

O que marcenaria me ensinou sobre front-end

Desde que comecei a trabalhar com o caixote fiquei pensando em escrever este texto e pensando em como paciência é uma virtude importante para um desenvolvedor, seja front-end ou back-end. 

Eu sei que posso entregar um projeto em cinco horas ou este mesmo projeto em quinze horas, e apesar dos resultados aparentarem ser “bem parecidos”, não é bem assim. 

Em meus projetos eu costumo sofrer de uma síndrome chamada “ansiedade de colocar no ar”, principalmente se tratando do And After. Por razões de negócio sou muito mais cuidadoso com o Eu Compraria, mas mesmo assim a ansiedade é uma complicada de lidar e acaba atrapalhando na qualidade e produtividade enquanto estou programando.

Se algo está “quase pronto” era comum três coisas acontecerem por aqui:

  1. Trabalhar mais que 10 horas diárias
  2. Não conseguir focar em outra coisa senão o projeto que quero lançar
  3. Preciso lançar hoje

Identificar o problema é o primeiro passo para lidar com ele, e lixar, lixar e lixar me ajudou a controlar um pouco a ansiedade (provavelmente meditação e estar cultivando bonsais também ajudaram).

Aprendi a ser um desenvolvedor com uma qualidade de entrega melhor do que a que eu estava acostumado, controlo um pouco melhor a ansiedade que sinto em publicar um projeto (text, código, etc.).

Em uma construção de moradia emergencial no TETO
A construção é de um final de semana. 

Que tal participar do TETO?

Quando o objetivo é fazer bem feito não devemos ter pressa, hoje eu foco em fazer o melhor possível no tempo que eu acho necessário, e não no tempo que eu acho mínimo para uma entrega. 

No TETO o primeiro dia é basicamente dedicado a fundação da casa, e temos apenas 2 dias para construir. Antes de começar a codar seu projeto pense em cada detalhe, estruture ele na sua cabeça ou no papel. Trabalhar em um projeto com uma estrutura sólida é muito mais tranquilo e rápido.

Buscar atividades fora do digital podem ajudar bastante a melhorar nossa qualidade de vida e qualidade de trabalho quando tentamos fazer uma relação e aprender sobre a vida, não sobre uma profissão ou atividade específica.

E você, tem alguma experiência parecida com atividades que refletiram na melhora do seu trabalho? Compartilhe nos comentários ou me escreva. 🙂

Como estender os Controllers do Code Igniter

Estender um controller do Code Igniter é uma boa forma de carregar um controller com algumas pré-definições, como validação de usuário, carregamento de bibliotecas ou definições de idioma.

Como estender um controller?

Para estender um controller (ou qualquer outra parte do Code Igniter) o primeiro passo é criar um arquivo que será carregado automaticamente e terá a classe que iremos utilizar.

No meu caso, para estender um controller vou criar um arquivo chamado MY_Controller.php no diretório:

application/core/MY_Controller.php

Dentro este arquivo crio uma classe para estender meu controller, por exemplo:

class MY_AdminController extends CI_Controller {}

E dentro desta classe eu adiciono o que for necessário para o meu controller extendido.

class MY_AdminController extends CI_Controller {
	function __construct(){
		parent::__construct();
		header('Content-type: text/html; charset=utf-8');
		$user = new User();
		if(!$user->getLogged()){
			die('There is only one god and his name is Death, and there is only one thing we say to Death: "Not today"');
		}
	}
}

E no arquivo do seu controller, ao invés de estender o controller você extende o MY_AdminController ou qualquer outro nome que você tenha utilizado.

Você pode ter mais do que uma extensão de controller, no mesmo arquivo de extensão (MY_Controller.php) é só criar uma outra classe e estender o mesmo Controller.

class MY_AdminController extends CI_Controller {}
class MY_App extends CI_Controller {}

Uma outra forma de estender é utilizar os hooks, que permitem um controle mais sensível de onde e o que carregar.

E você, como faz isso nas suas aplicações?

Google Analytics apenas em produção

O Google Analytics é uma ferramenta espetacular para trabalhar com métricas de navegação e e-commerce, implementei o "tracking" de diversos eventos no Eu Compraria que estão nos auxiliando a melhorar a interface e identificar os produtos mais procurados, pontos de desistência de compra, etc.

Mas como executamos diversos testes isso estava influenciando um pouco nossas métricas, então fui pesquisar como executar os códigos do Analytics apenas em produção (sem gambiarras) e descobri na documentação que tem uma variável do próprio GA que cuida disso.

Bloqueando o Google Analytics

O Analytics permite que você bloqueie a execução de determinada conta ativa na página através da criação de uma variável.

window['ga-disable-UA-XXXXXX-Y'] = true;

Substitua o UA-XXXXXX-Y pelo código identificador da sua conta no Google Acalytics e todas as páginas que tiverem esta variável (javascript) como true não irão armazenar cookies ou enviar dados para os servidores do Analaytics.

Com o Code Igniter adicionei no header das minhas views uma verificação do ENVIRONMENT da aplicação, sempre que for diferente de produção esta variável do Analytics é criada. Assim nem ambiente de homologação e nem ambiente de desenvolvimento afetam as métricas dos meus projetos. 🙂