Usando GIT
Diferente de Subversion ou CVS, não é necessário instalar servidores à parte ou configurar nada extra, sequer um ambiente web. Tudo pode ser resolvido via SSH.
Para começar, vou assumir que você está usando Linux, Mac ou um ambiente Unix. Vamos criar uma chave SSH e exportá-la para sua conta. Se estiver no Windows, siga estas instruções.
Na sua máquina local rode o seguinte comando:
ssh-keygen -t rsa
Esse comando perguntará sobre senha, passphrase, apenas dê Enter para deixar tudo vazio. Isso criará os arquivos ~/.ssh/id_rsa e ~/.ssh/id_rsa.pub
Agora precisamos transferir esse arquivo ao servidor:
scp ~/.ssh/id_rsa.pub seu_login@seu_servidor:~/.ssh/authorized_keys
Pronto, com isso você não precisa mais digitar a senha para fazer login na sua conta via SSH. Toda vez que estiver na sua máquina, o SSH usará o par de chaves criado para fazer a autenticação. Proteja bem sua chave privada em ~/.ssh/id_rsa.
Para criar um novo repositório GIT, de dentro do servidor da sua hospedagem, via SSH, faça o seguinte:
ssh seu_login@seu_servidor mkdir -p repo/meu_projeto.git cd repo/meu_projeto.git git --bare init
Digite ‘exit’ para voltar à sua *máquina local*. Agora crie um repositório local de GIT. Para isso escolha o projeto que quer versionar ou apenas crie um novo projeto, como no exemplo:
rails meu_projeto cd meu_projeto git init git add . git commit -a -m "Initial Commit"
Agora é só ligar as duas pontas. A partir do diretório do seu projeto, na máquina local, faça o seguinte:
git remote add origin ssh://seu_login@seu_servidor:repo/meu_projeto.git git push origin master
Pronto. Agora seu servidor está com todo o seu código. Você pode usar “git push” toda vez que quiser atualizar o servidor.
Se quiser que outro usuário, em outra máquina, use seu repositório. Crie um novo par de chaves SSH como mostrado acima. Daí faça o seguinte:
scp ~/.ssh/id_rsa.pub seu_login@seu_servidor:~/.ssh ssh seu_login@seu_servidor cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
Pronto, isso adicionará uma nova chave à sua conta e permitirá o outro usuário de acessar seu repositório. Para que ele possa começar a colaborar, ele pode fazer, da máquina dele:
git clone ssh://seu_login@seu_servidor:repo/meu_projeto.git
Isso criará um clone na máquina local dele. Como expliquei, será um clone completo, com todo o histórico desde o primeiro commit feito por você. Ele pode contribuir usando “git push” e ambos podem pegar as atualizações que o outro fez no servidor usando o comando “git pull”.
Usando Branches
O modelo que expliquei acima é apenas uma das formas de colaboração. Novamente, veja este link, para mais detalhes.
A partir do seu projeto, na máquina local, você pode usar o comando “git branch”. Ele mostrará algo assim:
>> git branch * master
Ou seja, por padrão, o GIT sempre usa Branches e o primeiro branch criado automaticamente é o master. Inclusive é onde as atualizações vindas do seu repositório remoto vão residir. É uma boa prática sempre fazer seu desenvolvimento em outra branch separada, desta forma:
git checkout -b novo_branch
Feito isso você pode desenvolver normalmente no “novo_branch”. Toda vez que quiser puxar atualizações do servidor faça isto:
git checkout master git pull git checkout novo_branch git rebase master
Isso fará o seguinte:
- voltará o branch “master”
- puxará as modificações que foram feitas no repositório remoto para dentro de “master”
- muda de volta ao branch “novo_branch”
- mescla as mudanças vindas do servidor no “novo_branch”
É possível que, de tempos em tempos, você tenha conflitos (dois desenvolvedores mexeram no mesmo arquivo, exatamente na mesma linha). Nesse caso o comando “git rebase master” acima vai falhar e dizer qual arquivo é o ofensor. Nesse caso você deve abrir esse arquivo e resolver o conflito manualmente, e feito isso faça o seguinte:
git add arquivo_corrigido git rebase –continue
Daí o Git continuará o resto das mesclagens. Se ainda assim aparecer outra mensagem de erro sobre o mesmo arquivo, apenas faça “git rebase –skip”. O Git não faz mesclagens usando apenas as últimas revisões dos códigos: ele sabe usar a genealogia do conteúdo do arquivo. Por isso sua heurística de mesclagem é muito mais inteligente.
Toda vez que quiser gravar no seu repositório local alguma modificação para que não se perca, faça commit:
git commit -a -m "descricao deste commit"
Ao contrário do Subversion ou CVS, “commit” não manda nada ao servidor remoto, isso é tarefa do comando “git push”. O commit apenas empacota e grava as últimas modificações de código. É recomendado que se faça isso com bastante frequência para que você nunca perca nada e ainda possa mudar de idéia e voltar commits. Por exemplo, se quiser apagar os últimos 2 commits, por exemplo, faça assim:
git reset –soft HEAD^2
Isso irá desfazer os últimos 2 commits e suas modificações ainda estarão no lugar, daí você pode alterar o que precisar e fazer um novo commit.
Daí, digamos que você terminou o que estava desenvolvendo no “novo_branch”, e quer enviar tudo para o servidor. Sempre faça o processo de rebase como mostrado acima, para garantir que seu “novo_branch” está sincronizado com as últimas atualizações do servidor. Daí faça:
git checkout master git merge master git push git branch -d novo_branch
Esses comandos farão o seguinte:
- Volta ao branch “master”
- Mescla todas as mudanças do branch “novo_branch” para o master
- Envia os commits mesclados ao servidor
- Apaga o branch “novo_branch”
Na realidade existe um processo ainda melhor:
git checkout master git merge novo_branch –squash git commit -a -m "descricao da nova funcionalidade" git push git branch -d novo_branch
A diferença é a opção “–squash”. Digamos que no “novo_branch” você tinha 50 commits. Mas você não quer que apareça 50 commits no servidor. Faz mais sentido que o que você fez no “novo_branch” suba como um único commit que engloba uma nova funcionalidade, uma correção de bug ou uma nova documentação, por exemplo, então você pode “esmagar” os 50 commits em apenas 1 para manter tudo limpo e organizado no repositório remoto central.
Feito isso, os outros desenvolvedores com acesso ao repositório central podem fazer “git pull” e receberão suas modificações.
Como podem ver, o Git oferece muitas ferramentas e opções. Aqui acabei de mostrar o topo do iceberg, muito mais pode ser feito. O repositório do Git é muito robusto (ainda nunca ouvi falar de repositórios git corrompidos), muito rápido (roda local e as ferramentas de linha de comando são feitas em C, pelo próprio Linus) e garante a produtividade que você precisa num ambiente ágil.
Instale o Git na sua máquina local (usuários Windows, instalem o msysGit). Outro detalhe: não, o Git ainda não tem nenhuma ferramenta visual competente. Por outro lado, o poder do Git só é liberado se o desenvolvedor tiver o conhecimento dos processos explicados acima. Escondê-los não ajudará em nada. Se seu desenvolvedor não conseguir aprender como usar o Git, o problema talvez seja reavaliar as capacidades desse desenvolvedor.
O uso do Git cresceu exponencialmente nos últimos meses. O website GitHub concentra a maioria dos projetos open source em repositórios Git. Ele nasceu há 1 ano e, começando do zero, hoje tem mais de 19 mil projetos em Git. O próprio Ruby on Rails, fora a kernel do Linux, estão em repositórios Git. Mais do que isso, graças à ferramenta git-svn é possível sincronizar (tanto leitura quanto escrita) com repositórios em Subversion, o que permite migração praticamente trivial de Subversion para Git.
Experimente e aprenda esta nova ferramenta. Alguns dos melhores desenvolvedores do mundo e projetos open source já estão migrando para Git. Aumente a produtividade na sua empresa adotando Git.
Caso tenha problemas ao efetuar git push origin master faça o seguinte processo :
1) git remote rm origin (para apagar o que você já fez)
2) git remote add origin ssh://usuario@servidor/~/diretorio/projeto
(não use o “:” e sim “/”)
E no servidor, no diretorio “diretorio/projeto”
execute o comando git init –bare para criar o repositorio.