AprenderEmRede/Repositório
Conteúdo[ocultar] |
Criação e manutenção dos Repositórios para o projeto “Aprender em Rede”
Será necessário criar, em cada servidor, quatro repositórios git, um para cada software. Por exemplo, no cepadev, deveremos ter um repo para o Stoa, um para o Moodle, um para o Drupal e outro para o MediaWiki. Isso será necessário para que possamos puxar código diretamente do upstream de cada um desses projetos, mantendo assim a nossa plataforma Aprendem em Rede sempre atualizada (pelo menos no servidor de desenvolvimento).
No servidor de produção, os softwares rodarão a partir do repositório, por esta razão, devemos evitar mudar de branches lá, visto que essa operação muda os arquivos do diretório. Idealmente, no cepa, só puxaremos código do cepadev, sempre dos branches master.
Criando um repositório git a partir do repositório svn original do STOA
Clonando
Primeiro precisando clonar o repositório original svn para um repositório git. Para podermos fazer commit para o repositório svn a partir do nosso novo repositório git devemos ter acesso ao servidor onde está hospedado o repositório svn via ssh, usando o comando abaixo, substituindo <usuario> pelo seu nome de usuário com acesso ssh no servidor.
Clonar em modo de escrita:
$ git svn clone --stdlayout --username=<usuario> svn+ssh://<usuario>@cepadev.if.usp.br/var/svn/stoa stoa
Se não tiver acesso ssh, ainda é possível clonar o repositório em modo “somente leitura”, no entanto não será possível enviar para o repositório original svn as modificações feitas no novo repositório git.
Clonar em modo somente leitura:
$ git svn clone --stdlayout http://cepadev.if.usp.br/svn/stoa stoa
Esta etapa pode ser um pouco demorada dependendo do tamanho do projeto e do histórico de mudanças. No caso do STOA em uma conexão banda larga levará poucos minutos.
Garantindo que o “master” do git esteja apontando para o “trunk” do svn
Quando clonamos o repositório, como descrito acima, o branch “master” do novo repositório git apontara para o branch do svn que possuir a alteração mais recente. No STOA atualmente utilizamos apenas o “trunk”, mas para garantia devemos verificar se tudo está certo usando o comando a baixo.
$ git svn info
Na saída do comando devemos observar se o campo URL aponta para http://cepadev.if.usp.br/svn/stoa/trunk. Caso contrário devemos usar o seguinte comando para modificar para o “trunk”.
$ git reset --hard remotes/trunk
Agora já podemos trabalhar no código do STOA, porém é melhor criarmos um método para garantir que não teremos problemas na comunicação entre o nosso novo repositório git e o repositório svn original.
Criando um branch “limpo”
O melhor modo para trabalharmos com essa comunicação entre o git e o svn é criarmos um branch no repositório git no qual só serão incluídas as alterações que queremos enviar para o svn. Nestas alterações incluiremos apenas as que corrigem bugs e melhoram o STOA de maneira genérica, e não mudanças específicas para o projeto que estaremos desenvolvendo.
Para criarmos este novo branch, utilizamos o comando abaixo, substituindo <nome do branch> por um nome a ser escolhido.
$ git branch <nome do branch>
Agora, mantendo este branch sempre limpo e sincronizado com o svn, está tudo pronto para começarmos a alterar o código do STOA.
Este repositório recém criado é um repositório git normal como outro qualquer e pode ser clonado, ter novos branchs criados, fazer merge entre branchs, etc.
Selecionando quais alterações serão enviadas para o svn
Algo importante e que facilitará muito ao enviarmos alterações para o svn é fazer commit das alterações especificas e das alterações globais (aquelas que interessam para o STOA como um todo) separadamente.
O melhor modo de separarmos as alterações que serão enviadas para o svn é quando percebermos que uma alteração é de interesse para o STOA como um todo criarmos um novo branch temporário, fazermos a alteração neste branch e darmos merge desta para o nosso branch do projeto e para o branch “limpo”.
Outro modo é irmos fazendo vários pequenos commits enquanto trabalhamos no código, um para cada pequena alteração, deste modo há uma probabilidade alta de as alterações globais e as específicas estarem separadas em commits diferentes e poderemos, depois, escolher quais serão enviados para o svn. Atenção, neste caso usaremos o comando cherry-pick para “copiarmos” as alterações globais para o branch “limpo” e não o merge.
Porém se na hora que estivermos programando nos desligamos do mundo e esquecemos de fazer commits separados ou de mudarmos para um novo branch para as alterações globais e só lembrarmos na hora em que vamos adicionar aquele monte de alterações que ainda poderemos separá-las em commits diferentes usando “interactive adding”[1]. Este último é o modo mais trabalhoso e também utiliza o cherry-pick para escolher os commits que queremos enviar para o svn.
Enviar alterações do git para o svn
Criando um repositório git a partir do repositório svn do DRUPAL ACQUIA
Referência
- How to track multiple svn branches in git - http://www.jukie.net/~bart/blog/svn-branches-in-git
- Connecting Git to Subversion - http://shotgunsandpenguins.blogspot.com/2009/08/part-viii-connecting-git-to-subversion.html
- Communicating from Git to Subversion - http://shotgunsandpenguins.blogspot.com/2009/08/part-ix-communicating-from-git-to.html
- Git Community Book: Interactive Adding - http://book.git-scm.com/4_interactive_adding.html
- Git Manpages
- ↑ Aprenda sobre “interactive adding” e veja um videocast no endereço http://book.git-scm.com/4_interactive_adding.html