9.1 Git e Outros Sistemas - Git como Cliente

O comando base no Git para todos os comandos de ponte do Subversion é git svn. Ele recebe vários comandos, portanto, mostraremos o mais comum ao passar por alguns fluxos de trabalho simples.

É importante observar que, quando você usa o git svn, interage com o Subversion, um sistema que funciona de maneira muito diferente do Git. Embora você possa fazer uma ramificação e mesclagem local, geralmente é melhor manter seu histórico da forma mais linear possível ao refazer seu trabalho (rebase) e evitar interagir simultaneamente com um repositório remoto do Git.

Não reescreva o seu histórico e tente empurrá-lo novamente, e não o empurre para um repositório git paralelo para colaborar com outros desenvolvedores do Git ao mesmo tempo. O Subversion pode ter apenas um histórico linear, e confundi-lo é muito fácil. Se você estiver trabalhando com uma equipe, e alguns usarem SVN e outros usarem Git, certifique-se de que todos usem o servidor SVN para colaborar - fazer isso facilitará sua vida.

Para demonstrar essa funcionalidade, você precisa de um repositório SVN típico em que tem acesso de gravação. Se você deseja copiar esses exemplos, precisará fazer uma cópia gravável de um repositório de teste SVN. Para fazer isso facilmente, você pode usar uma ferramenta chamada svnsync que vem com o Subversion.

Para acompanhar, você deve primeiro criar um novo repositório local do Subversion:

Em seguida, ative todos os usuários a alterarem os revprops – a maneira mais fácil é adicionar um script pre-revprop-change que sempre sai (exit) de zero:

Agora você pode sincronizar este projeto com a sua máquina local chamando svnsync init a partir de repositórios e para eles.

Isso define as propriedades para executar a sincronização. Você pode clonar o código executando:

Embora essa operação possa levar apenas alguns minutos, se você tentar copiar o repositório original para outro repositório remoto em vez de um local, o processo levará quase uma hora, mesmo que haja menos de 100 commits. O Subversion deve clonar uma revisão por vez e depois inseri-lo em outro repositório - é ridiculamente ineficiente, mas é a única maneira fácil de fazer isso.

Agora que você tem um repositório Subversion ao qual tem acesso de gravação, pode passar por um fluxo de trabalho típico. Você começará com o comando git svn clone, que importa um repositório inteiro do Subversion para um repositório local do Git. Lembre-se de que, se você estiver importando de um repositório do Subversion hospedado de verdade, precisará substituir o arquivo file:///tmp/test-svn aqui pela URL do seu repositório do Subversion:

Isso executa o equivalente a dois comandos – git svn init seguido de git svn fetch – na URL fornecida. Isso pode demorar um pouco. Se, por exemplo, o projeto de teste tiver apenas cerca de 75 commits e a base de código não for tão grande, o Git ainda deve verificar cada versão, uma por vez, e comitá-las individualmente. Para um projeto com centenas ou milhares de commits, isso pode literalmente levar horas ou mesmo dias para terminar.

A parte -T trunk -b branches -t tags diz ao Git que esse repositório do Subversion segue as convenções básicas de ramificação e marcação. Se você nomear o seu tronco (trunk), ramificações (branches) ou etiquetas (tags) de maneira diferente, poderá alterar essas opções. Como isso é tão comum, você pode substituir toda a parte por -s, que significa layout padrão e implica todas essas opções. O seguinte comando é equivalente:

Neste ponto, você deve ter um repositório Git válido que importou suas ramificações (branches) e tags:

Observe como essa ferramenta gerencia as tags do Subversion como referências remotas (remote refs). Vamos dar uma olhada no comando de encanamento do Git show-ref:

O Git não faz isso quando é clonado de um servidor Git; aqui está a aparência de um repositório com tags após um clone novo:

O Git busca (fetch) as tags diretamente nas refs/tags, em vez de tratá-las como branches remotos.

Agora que você tem um diretório de trabalho, pode trabalhar um pouco no projeto e fazer com que os seus commits voltem a ser a montante (upstream), usando o Git efetivamente como um cliente SVN. Se você editar um dos arquivos e comitá-lo, terá um commit que existe no Git localmente que não existe no servidor Subversion:

Em seguida, você precisa efetuar o push de sua mudança para montante (upstream). Observe como isso muda a maneira como você trabalha com o Subversion – você pode fazer vários commits offline e, em seguida, fazer push em todos os servidores do Subversion de uma só vez. Para fazer um push em um servidor Subversion, execute o comando git svn dcommit:

Isso pega todos os commits que você fez no código do servidor do Subversion, faz um commit no Subversion para cada um e, em seguida, reescreve o commit do Git local para incluir um identificador exclusivo. Isso é importante porque significa que todas as somas de verificação (checksums) do SHA-1 de seus commits mudam. Em parte por esse motivo, não é uma boa ideia trabalhar com versões remotas de seus projetos com base no Git simultaneamente a um servidor Subversion. Se você observar o último commit, poderá ver o novo git-svn-id que foi adicionado:

Observe que a soma de verificação (checksum) SHA-1 que originalmente começava com 4af61fd quando você o comitou, agora começa com 95e0222. Se você deseja fazer push no servidor Git e em um servidor Subversion, você tem que dar o push (dcommit) no servidor Subversion primeiro, porque essa ação altera os dados de seu commit.

Se você estiver trabalhando com outros desenvolvedores, em algum momento um de vocês dará um push e, em seguida, o outro tentará enviar um conflito na mudança. Essa alteração será rejeitada até que você junte os trabalhos. Em git svn, isso se parece com isso:

Para resolver essa situação, você pode executar o git svn rebase, que extrai todas as alterações no servidor que você ainda não possui e recria o trabalho que você tem sobre o que está no servidor:

Agora, todo o seu trabalho está em cima do que há no servidor Subversion, para que você possa dcommit com êxito:

Observe que, ao contrário do Git, que exige a mesclagem de trabalho a montante que você ainda não possui localmente antes de poder realizar push, git svn faz isso apenas se as alterações entrarem em conflito (muito parecido com a forma como o Subversion funciona). Se outra pessoa der push de uma mudança num arquivo e, em seguida, você der push em uma mudança de um outro arquivo, seu dcommit funcionará perfeitamente:

Isso é importante de se lembrar, porque o resultado é um estado de projeto que não existia em nenhum de seus computadores quando você os empurrou (push). Se as alterações forem incompatíveis, mas não entrarem em conflito, você poderá ter problemas difíceis de diagnosticar. Isso é diferente de usar um servidor Git – no Git, você pode testar completamente o estado do sistema cliente antes de publicá-lo, enquanto no SVN você nunca pode ter certeza de que os estados imediatamente antes e depois do commit são idênticos.

Você também deve executar este comando para efetuar pull nas alterações do servidor Subversion, mesmo que não esteja pronto para se comprometer (comitar). Você pode executar git svn fetch para obter os novos dados, mas git svn rebase busca (fetch) e atualiza seus commits locais.

A execução de git svn rebase de vez em quando garante que seu código esteja sempre atualizado. Você deve ter certeza de que seu diretório de trabalho esteja limpo ao executar isso. Se você tiver alterações locais, deve fazer stash do trabalho ou criar um commit temporário antes de executar git svn rebase – caso contrário, o comando será interrompido se constatar que o rebase resultará em um conflito de merge.

Quando você se sentir confortável com um fluxo de trabalho do Git, provavelmente criará ramificações (branches) de tópicos, fará o trabalho e as mesclará (merge) nelas. Se você estiver empurrando (pushing) para um servidor Subversion via git svn, convém refazer (rebase) seu trabalho em uma única filial de cada vez, em vez de mesclar as ramificações (branches). O motivo para preferir o rebasing é que o Subversion tem um histórico linear e não lida com mesclagens como o Git, portanto o git svn segue apenas o primeiro pai ao converter os instantâneos (snapshots) em commits do Subversion.

Suponha que seu histórico seja o seguinte: você criou uma ramificação experiment, fez dois commits e depois mesclou-os no master. Quando você usar dcommit, você verá uma saída parecida com esta:

A execução do dcommit em um branch com histórico mesclado (merge history) funciona bem, exceto quando você analisa o histórico do projeto Git. Ele não reescreveu nenhum dos commits efetuados no branch experiment – em vez disso, todas essas alterações aparecem na versão SVN do commit de consolidação (merge commit) único.

Quando outra pessoa clona esse trabalho, ela vê apenas o commit de consolidação (merge commit) com todo o trabalho esmagado, como se você executasse git merge --squash; eles não veem os dados de confirmação sobre de onde eles vieram ou quando foram confirmados.

Branching no Subversion não é o mesmo que branching no Git; se você puder evitar o uso, provavelmente é o melhor. No entanto, você pode criar e comitar em branches no Subversion usando o git svn.

Para criar um novo branch no Subversion, você roda o git svn branch [new-branch]:

Isso faz o equivalente ao comando svn copy trunk branches/opera no Subversion e opera no servidor Subversion. É importante observar que não faz uma verificação nesse branch; se você comitar nesse ponto, esse commit irá para o trunk no servidor, não no opera.

O Git descobre em que ramificação as suas comissões ocorrem, procurando a ponta (tip) de qualquer uma de suas filiais (branches) do Subversion em seu histórico – você deve ter apenas um e deve ser o último com um git-svn-id no histórico da sua ramificação atual.

Se você deseja trabalhar em mais de um branch simultaneamente, pode configurar branches locais no dcommit para branches específicos do Subversion, iniciando-os no commit de Subversion importado para essa branch. Se você deseja uma filial (branch) opera na qual possa trabalhar separadamente, execute:

Agora, se você deseja mesclar (merge) o seu branch opera no trunk (seu branch master), é possível fazê-lo com um git merge normal. Mas você precisa fornecer uma mensagem descritiva de commit (via -m), ou a consolidação (merge) dirá “Merge branch opera” em vez de algo útil.

Lembre-se de que, embora você esteja usando o git merge para executar esta operação, o merge provavelmente será muito mais fácil do que no Subversion (porque o Git detectará automaticamente a base de consolidação (merge) apropriada para você), esse não é um normal commit do Git normal. Você tem que levar (push) esses dados de volta a um servidor Subversion que não consegue lidar com um commit que rastreia mais de um pai; logo, depois de enviá-lo (push up), parecerá um único commit no qual esmaga todo o trabalho de outro branch sob um único commit. Depois de mesclar (merge) um branch com outro, não é possível voltar com facilidade e continuar trabalhando nela, como é normalmente possível no Git. O comando dcommit que você executa apaga qualquer informação que diga qual branch foi mesclado (merged), para que os cálculos base subsequentes da base de consolidação fiquem errados – o dcommit faz o seu resultado do git merge parecer como se tivesse rodado o comando git merge --squash. Infelizmente, não há uma boa maneira de evitar essa situação – o Subversion não pode armazenar essas informações, portanto, você sempre será prejudicado por suas limitações enquanto o usar como servidor. Para evitar problemas, exclua o branch local (neste caso, opera) depois de mesclá-lo ao trunk.

O conjunto de ferramentas git svn fornece vários comandos para ajudar a facilitar a transição para o Git, fornecendo algumas funcionalidades semelhantes às do Subversion. Aqui estão alguns comandos que fornecem o que o Subversion costumava fazer.

As ferramentas git svn são úteis se você estiver preso a um servidor Subversion ou em um ambiente de desenvolvimento que exija a execução de um servidor Subversion. Você deve considerá-lo como um Git prejudicado, no entanto, ou você terá problemas na tradução que podem confundir você e seus colaboradores. Para evitar problemas, tente seguir estas diretrizes:

Se você seguir essas diretrizes, trabalhar com um servidor Subversion pode ser mais suportável. No entanto, se for possível mover para um servidor Git real, isso poderá ganhar muito mais para sua equipe.

Primeiro, você deve instalar o git-remote-hg. Isso implica basicamente soltar o arquivo em algum lugar no seu caminho (path), da seguinte forma:

Se você não tem o Python instalado, acesse https://www.python.org/ e faça a obtenção dele antes.

A última coisa que você precisará é do cliente Mercurial. Vá para https://www.mercurial-scm.org/ e o instale caso ainda não o tenha feito.

Agora você está pronto para agitar. Tudo que você precisa é de um repositório Mercurial no qual possa empurrar (fazer o push). Felizmente, todos os repositórios Mercurial podem agir dessa maneira, portanto, usaremos o repositório "hello world" que todo mundo usa para aprender o Mercurial:

Agora que temos um repositório "lado do servidor (server-side)" adequado, podemos seguir um fluxo de trabalho típico. Como você verá, esses dois sistemas são bastante semelhantes e não há muito atrito.

Como sempre no Git, primeiramente nós o clonamos:

Você notará que trabalhar com um repositório Mercurial usa o comando padrão git clone. Isso ocorre porque o git-remote-hg está trabalhando em um nível bastante baixo, usando um mecanismo semelhante a como o protocolo HTTP/S do Git é implementado (helpers remotos). Como o Git e o Mercurial são projetados para que todos os clientes tenham uma cópia completa do histórico do repositório, este comando faz um clone completo, incluindo todo o histórico do projeto, e o faz com bastante rapidez.

O comando log mostra dois commits, os mais recentes sendo apontados por um monte de referências. Acontece que alguns deles não estão realmente lá. Vamos dar uma olhada no que realmente está no diretório .git:

O Git-remote-hg está tentando tornar as coisas mais idiomaticamente no formato Git-esque, mas sob o capô está gerenciando o mapeamento conceitual entre dois sistemas ligeiramente diferentes. O diretório refs/hg é onde as referências remotas (remote refs) reais são armazenadas. Por exemplo, o arquivo refs/hg/origin/branches/default é um arquivo de ref do Git que contém o SHA-1 que começa com “ac7955c”, que é o commit no qual a master aponta. Portanto, o diretório refs/hg é como um falso refs/remotes/origin, mas tem a distinção adicional entre favoritos (bookmarks) e ramificações (branches).

O arquivo notes/hg é o ponto de partida de como o git-remote-hg mapeia hashes de commit do Git para IDs de conjunto de alterações do Mercurial. Vamos explorar um pouco:

Portanto, refs/notes/hg aponta para uma árvore, que no banco de dados de objetos do Git é uma lista de outros objetos com nomes. O git ls-tree produz o modo, tipo, hash do objeto e o nome de arquivo para os itens em uma árvore. Depois de cavar em um dos itens da árvore, descobrimos que, dentro dele, há um blob chamado “ac9117f” (o hash SHA-1 do commit apontado por master), com o conteúdo “0a04b98” (que é o ID do changeset do Mercurial na ponta (tip) do branch default).

A boa notícia é que não precisamos nos preocupar com tudo isso a maior parte do tempo. O fluxo de trabalho típico não será muito diferente do trabalho com um controle remoto no Git.

Há mais uma coisa que devemos atender antes de continuarmos: ignorações. O Mercurial e o Git usam um mecanismo muito semelhante para isso, mas é provável que você não queira confirmar (comitar) um arquivo .gitignore em um repositório Mercurial. Felizmente, o Git possui uma maneira de ignorar arquivos que são locais a um repositório no disco e o formato Mercurial é compatível com o Git; portanto, basta copiá-lo para:

O arquivo .git/info/exclude age como um .gitignore, mas não é incluído nos commits.

Vamos supor que fizemos algum trabalho e fizemos alguns commits no branch master e você está pronto para enviá-lo (push) ao repositório remoto. Aqui está a aparência do nosso repositório no momento:

Nosso branch master tem dois commits à frente da origin/master, mas esses dois commits existem apenas na nossa máquina local. Vamos ver se alguém fez um trabalho importante ao mesmo tempo:

Como usamos o sinalizador (flag) --all, vemos as refs de “notes” usadas internamente pelo git-remote-hg, mas podemos ignorá-las. O resto é o que esperávamos; origin/master avançou em um commit, e nosso histórico agora divergiu. Ao contrário dos outros sistemas com os quais trabalhamos neste capítulo, o Mercurial é capaz de lidar com merges, portanto não faremos nada de extraordinário.

Perfeito. Executamos os testes e tudo passa; portanto, estamos prontos para compartilhar o nosso trabalho com o restante da equipe:

Isso é tudo! Se você der uma olhada no repositório do Mercurial, verá que isso fez o que esperávamos:

O conjunto de alterações (changeset) numerado 2 foi criado por Mercurial, e os conjuntos de alterações numerados 3 e 4 foram feitos por git-remote-hg, promovendo os commits efetuados pelo Git (push).

O Git possui apenas um tipo de ramificação (branch): uma referência que se move quando são feitos commits. No Mercurial, esse tipo de referência é chamado de "favorito (bookmark)" e se comporta da mesma maneira que uma filial (branch) do Git.

O conceito do Mercurial de uma "ramificação (branch)" é mais pesado. A ramificação na qual um conjunto de alterações (changeset) é criado é gravada juntamente com o conjunto de alterações, o que significa que ele sempre estará no histórico do repositório. Aqui está um exemplo de uma comissão efetuada no branch develop:

Observe a linha que começa com “branch”. O Git não pode realmente replicar isso (e não é necessário; os dois tipos de ramificações (branch) podem ser representados como uma referência (ref) do Git), mas o git-remote-hg precisa entender a diferença, porque o Mercurial se importa.

Criar favoritos no Mercurial é tão fácil quanto criar ramificações (branches) do Git. Do lado do Git:

Isto é tudo que há nisto. Do lado do Mercurial, a aparência é a seguinte:

Observe a nova tag [featureA] na revisão 5. Eles agem exatamente como os branches do Git no lado do Git, com uma exceção: você não pode excluir um favorito (bookmark) do lado do Git (esta é uma limitação dos ajudantes remotos).

Você também pode trabalhar em um branch "pesado (heavyweight)" do Mercurial: basta colocar um branch no espaço de nome das branches:

Veja a aparência do lado do Mercurial:

O nome da ramificação (branch name) “permanent” foi gravada no conjunto de alterações (changeset) marcado 7.

Do ponto de vista do Git, trabalhar com qualquer um desses estilos de ramificação (branch styles) é a mesma coisa: basta fazer o checkout, comitar, fazer fetch, merge, puxar (pull) e dar push, como faria normalmente. Uma coisa que você deve saber é que o Mercurial não suporta a reescrita da história, apenas as acrescenta. Veja como é o nosso repositório Mercurial após um rebase interativo e um force-push:

Os conjuntos de alterações 8, 9 e 10 foram criados e pertencem à ramificação (branch) permanent, mas os antigos conjuntos de alterações ainda estão lá. Isso pode ser muito confuso para seus colegas de equipe que usam o Mercurial; tente evitá-lo.

O Git e o Mercurial são semelhantes o suficiente para que o trabalho além da fronteira seja indolor. Se você evita mudar o histórico ao ter saído da sua máquina (como geralmente é recomendado), talvez nem saiba que o outro lado é um Mercurial.

O Perforce fornece um produto chamado Git Fusion (disponível em https://www.perforce.com/manuals/git-fusion/), que sincroniza um servidor Perforce com repositórios Git no lado do servidor.

O Git-p4 é uma ponte de mão dupla entre Git e o Perforce. Ele é executado inteiramente no seu repositório Git, portanto você não precisará de nenhum tipo de acesso ao servidor Perforce (além das credenciais do usuário, é claro). O Git-p4 não é uma solução tão flexível ou completa quanto o Git Fusion, mas permite que você faça a maior parte do que deseja sem ser invasivo no ambiente do servidor.

O Git-p4 possibilita ao uso com o workflow do Git acompanhado de um servidor Perforce, e ele o faz muito bem. Porém, é importante recordar que o Perforce se responsabiliza da fonte de seus projetos, e que você apenas usa o Git de maneira local. Apenas tenha muito cuidado ao dividir as suas comissões (commits) no Git; caso você possua um acesso remoto ao qual as outras pessoas usam, não submeta (push) nenhum commit onde os mesmos não tenham sido enviados previamente a um servidor do Perforce.

Se você desejar que eles se unam (mix) de forma livre no controle das fontes (source control) de clientes (clients) entre o Perforce e o Git, e se for possível o convencimento do seu administrador de servidores à instalação dele, o Git Fusion faz do uso do Git num controle de versão clientelar da mais alta linha (first-class), em favor de um servidor de Perforce.