Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Ao mover para o Git de outro sistema de controle de versão, como o Subversion (SVN), geralmente recomendamos que você execute uma "migração tip", que migra apenas a versão mais recente do conteúdo do repositório, sem incluir o histórico. No entanto, muitas pessoas desejam realizar uma migração mais avançada, incluindo o histórico. As diretrizes fornecidas neste artigo introduzem uma migração com histórico.
As migrações de SVN para o Git podem variar em complexidade, dependendo da idade do repositório e quantos branches foram criados e mesclados, e se você está usando SVN regular ou um parente próximo, como o SVK.
Poderia ser simples se:
- Você tem um novo repositório
- Você tem uma configuração padrão de um diretório de tronco, branches e marcas
Provavelmente será complexo se:
- Sua equipe executou várias operações de ramificação e mesclagem
- Seu repositório segue uma configuração de diretório não padrão
- A configuração do diretório foi alterada ao longo do tempo
Há várias maneiras de migrar do SVN para o Git. A abordagem descrita neste artigo baseia-se no uso do git-svn, uma extensão git, que pode ser usada para fazer check-out de um repositório Subversion para um Repositório do Git local e, em seguida, enviar por push as alterações do Repositório do Git local de volta para o repositório Subversion. Essas etapas fornecem uma visão geral detalhada do processo de migração do SVN para o Git em um ambiente do Windows, sem sincronizar novamente com o repositório SVN original. O resultado será um Repositório do Git nu para compartilhar com o restante da sua equipe.
Observação
Antes de tentar migrar o código-fonte de um sistema de controle de versão centralizado para o Git, familiarize-se com as diferenças entre sistemas de controle de versão centralizados e distribuídos e planeje a migração da sua equipe. Depois de se preparar, você pode iniciar a migração.
O fluxo de trabalho de alto nível para migrar do SVN para o Git é o seguinte:
- Preparar um ambiente de migração
- Converter o repositório SVN de origem em um Repositório do Git local
- (Opcional) Sincronizar o Repositório do Git local com quaisquer alterações do repositório SVN enquanto os desenvolvedores continuam usando SVN
- Enviar por push o Repositório do Git local para um Repositório do Git remoto hospedado no Azure Repos
- Bloquear repositório SVN, sincronizar as alterações restantes do repositório SVN para o Repositório do Git local e enviar por push as alterações finais para o Repositório do Git remoto no Azure Repos
- Desenvolvedores alternam para o Git como principal sistema de controle do código-fonte
Preparar um ambiente de migração
Configure um ambiente de migração em uma estação de trabalho local e instale o seguinte software:
- Git
- Subversion
- Utilitário git-svn (já parte do Git)
Você também precisará criar um repositório Git para sua organização hospedar o repositório SVN convertido, você pode seguir Criar um novo repositório Git em seu projeto
Converter o repositório SVN de origem em um Repositório do Git local
O objetivo desta etapa é converter o repositório Subversion de origem em um repositório Bare Git local . Um repositório Git vazio não tem um check-out de trabalho local de arquivos que podem ser alterados, em vez disso, contém apenas o histórico do repositório e os metadados sobre o próprio repositório. Esse é o formato recomendado para compartilhar um Repositório do Git por meio de um repositório remoto hospedado em um serviço como o Azure Repos.
Dica
Os repositórios Git Bare são estruturados de forma diferente e dado o fato de que ele não tem um diretório de trabalho impede a confirmação direta para o repositório.
Recuperar uma lista de todos os autores de Subversion
O Subversion usa apenas o nome de usuário para cada confirmação, enquanto o Git armazena um nome real e um endereço de email. Por padrão, a ferramenta git-svn listará o nome de usuário SVN nos campos de autor e email. No entanto, você pode criar um arquivo de mapeamento para usuários SVN, juntamente com seus nomes e emails do Git correspondentes.
Usuários de subversão
Usuários Git
Para extrair uma lista de todos os usuários do SVN da raiz do check-out do Subversion local, execute este comando do PowerShell:
Para obter resultados na utf8NoBOM
codificação, execute o seguinte comando:
svn.exe log --quiet | ? { $_ -notlike '-*' } | % { "{0} = {0} " -f ($_ -split ' | ')[1] } | Select-Object -Unique | Sort-Object | Out-File 'authors-transform.txt' -Encoding utf8NoBOM
Para obter resultados na ASCII
codificação, execute o seguinte comando:
svn.exe log --quiet | ? { $_ -notlike '-*' } | % { "{0} = {0} " -f ($_ -split ' | ')[1] } | Select-Object -Unique | Sort-Object | Out-File 'authors-transform.txt' -Encoding ASCII
Este comando irá recuperar todas as mensagens de log, extrair os nomes de usuário, eliminar quaisquer nomes de usuário duplicados, classificar os nomes de usuário e colocá-los em um arquivo authors-transform.txt no formato UTF-8 (ou formato ASCII, dependendo de qual codificação você especificou). Em seguida, você pode editar cada linha no arquivo para criar um mapeamento de usuários SVN para usuários Git bem formatados. Por exemplo, você pode mapear jamal = jamal <jamal>
para jamal = Jamal Hartnett <jamal@fabrikam-fiber.com>
.
Clonar o repositório Subversion usando git-svn
O comando a seguir fará a transformação git-svn padrão usando o arquivo authors-transform.txt criado na etapa anterior. Ele colocará o Repositório do Git na c:\mytempdir
pasta em seu computador local.
git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --authors-file "authors-transform.txt" --stdlayout c:\mytempdir
Observação
O --prefix=svn/
é necessário porque, caso contrário, as ferramentas não podem informar revisões de SVN das importadas. É recomendável definir um prefixo (com uma barra à direita), pois os refs de rastreamento de SVN estarão localizados em refs/remotes/$prefix/
, que é compatível com o layout do branch de rastreamento remoto (refs/remotes/$remote/
) do Git.
Definir um prefixo também será útil se você quiser acompanhar vários projetos que compartilham um repositório comum. Por padrão, o prefixo é definido como origin/
.
Se você estiver usando o layout padrão de tronco, ramificações e tags, basta colocar --stdlayout
. No entanto, se você tiver algo diferente, talvez seja necessário passar o --trunk
, --branches
e --tags
para encontrar o que é o quê. Por exemplo, se sua estrutura de repositório fosse trunk/companydir
e você ramificasse isso em vez de tronco, provavelmente desejaria --trunk=trunk/companydir --branches=branches
.
git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --trunk=/trunk --branches=/branches --tags=/tags --authors-file "authors-transform.txt" c:\mytempdir
Observação
Esse comando pode levar alguns minutos a várias horas, dependendo do tamanho do repositório SVN. Após a conclusão, você terá um check-out do Git do seu repositório.
Converter configurações específicas do controle de versão
Se o repositório SVN estava usando propriedades svn:ignore, você pode converter em um arquivo .gitignore usando:
cd c:\mytempdir
git svn show-ignore --id=origin/trunk > .gitignore
git add .gitignore
git commit -m 'Convert svn:ignore properties to .gitignore.'
Dica
Leia mais sobre .gitignore: Ignorar alterações de arquivo com o Git
Enviar por push o repositório para um Repositório do Git nu
Nesta etapa, você criará um repositório vazio e fará com que sua ramificação padrão corresponda ao nome da ramificação de tronco do SVN.
Criar um Repositório do Git nu
git init --bare c:\new-bare.git cd c:\new-bare.git git symbolic-ref HEAD refs/heads/svn/trunk
Enviar por push o Repositório do Git local para o novo Repositório do Git nu
cd c:\mytempdir git remote add bare c:\new-bare.git git config remote.bare.push refs/remotes/*:refs/heads/* git push bare
Renomeie o
trunk
branch paramain
. Seu branch de desenvolvimento principal será chamado de "tronco", que corresponde ao nome que estava em Subversion. Você desejará renomeá-lo para o branch padrãomain
do Git usando:cd c:\new-bare.git git branch -m svn/trunk main
Limpar branches e marcas git-svn transforma todas as marcas de Subversões em branches muito curtos no Git do formato "tags/name". Você desejará converter todas essas ramificações em marcas Git reais ou excluí-las.
Migrar marcas SVN para serem marcas Git
cd c:\new-bare.git
git for-each-ref --format='%(refname)' refs/heads/svn/tags | % { $_.Replace('refs/heads/svn/tags/','') } | % { git tag $_ "refs/heads/svn/tags/$_"; git branch -D "svn/tags/$_" }
Migrações avançadas
Criar todos os branches do SVN como branches Git adequados
Embora seja fácil criar todos os branches SVN como branches Git adequados, é recomendável que você avalie os seguintes pontos antes de continuar:
Se houver branches de recursos: você pode aguardar até que eles se integrem ao tronco antes de migrar?
Se houver branches de versão: faz sentido manter o SVN por perto para manutenção? Se você migrar branches de recursos, estará preparado para enviar branches de serviço para fora do Git?
Se você ainda quiser migrar branches existentes, execute o seguinte comando do PowerShell:
git for-each-ref --format='%(refname)' refs/remotes | % { $_.Replace('refs/remotes/','') } | % { git branch "$_" "refs/remotes/$_"; git branch -r -d "$_"; }
Observação
Esse comando pode levar alguns minutos a várias horas, dependendo do tamanho do repositório SVN. Após a conclusão, você terá um check-out do Git do seu repositório.
Migrar somente revisões específicas
Quando não for especificado, git-svn clone
migrará todas as revisões da primeira confirmação (r1) para HEAD. Se você precisar migrar apenas um conjunto específico de revisões, o comando git-svn clone
deve ser acrescentado com uma opção de -r
.
Por exemplo, se você precisar migrar do rev 100 para o HEAD, o comando terá esta aparência:
git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --authors-file "authors-transform.txt" --stdlayout c:\mytempdir -r100:HEAD
Atualizar seu fluxo de trabalho
Mover de um sistema de controle de versão centralizado para o Git é mais do que apenas migrar código. Sua equipe precisa de treinamento para entender como o Git é diferente do sistema de controle de versão existente e como essas diferenças afetam o trabalho diário. Saiba mais.
Informações de referência
- Como escolher o controle de versão certo para seu projeto
- Aprender sobre o Git
- Ignorar alterações de arquivo com o Git
- Migrar do TFVC para o Git
Autores: Hosam Kamel, William H. Salazar | Localize a origem deste artigo e conecte-se com o ALM | Diretrizes de Branching do DevOps Rangers
(c) 2017 Microsoft Corporation. Todos os direitos reservados. Este documento é fornecido como foi escrito. As informações e opiniões apresentadas neste documento, incluindo URLs e outras referências a sites da Web, podem ser alteradas sem aviso prévio. Você assume o risco de usá-las.
Este documento não dá a você direitos legais a nenhuma propriedade intelectual em qualquer produto Microsoft. Você pode copiar e usar este documento para fins de referência interna.