AprenderEmRede/Repositório

De Stoa
Ir para: navegação, pesquisa

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



  1. Aprenda sobre “interactive adding” e veja um videocast no endereço http://book.git-scm.com/4_interactive_adding.html
Ferramentas pessoais
Espaços nominais

Variantes
Ações
Navegação
Imprimir/exportar
Ferramentas