Dowiedz się, jak przeprowadzić migrację z Subversion (SVN) do Git, w tym także historię.

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Podczas przechodzenia do usługi Git z innego systemu kontroli wersji, takiego jak Subversion (SVN), zalecamy przeprowadzenie migracji "tip migration", która migruje tylko najnowszą wersję zawartości repozytorium bez uwzględniania historii. Jednak wiele osób chce przeprowadzić bardziej zaawansowaną migrację, obejmującą dane historyczne. Wskazówki przedstawione w tym artykule zawierają wprowadzenie do migracji wraz z historią.

Migracje SVN do Git mogą się różnić w zależności od wieku repozytorium, liczby gałęzi utworzonych i scalonych, oraz czy używasz zwykłego SVN czy blisko spokrewnionego, takiego jak SVK.

Może to być proste, jeśli:

• Masz nowe repozytorium
• Masz standardową konfigurację katalogu magistrali, gałęzi i tagów

Prawdopodobnie będzie to złożone, jeśli:

• Twój zespół wykonał wiele operacji rozgałęziania i scalania
• Twoje repozytorium używa niestandardowej struktury katalogów
• Konfiguracja katalogu zmieniła się wraz z upływem czasu

Istnieje kilka sposobów migracji z formatu SVN do usługi Git. Podejście opisane w tym artykule opiera się na użyciu git-svn, rozszerzenia Git, które może służyć do wyewidencjonowania repozytorium Subversion do lokalnego repozytorium Git, a następnie wypychania zmian z lokalnego repozytorium Git z powrotem do repozytorium Subversion. Te kroki umożliwiają szczegółowe omówienie procesu migracji z formatu SVN do usługi Git w środowisku systemu Windows bez synchronizowania z powrotem do oryginalnego repozytorium SVN. Wynikiem będzie bazowe repozytorium Git do udostępniania z resztą zespołu.

Wymagania wstępne

Kategoria	Wymagania
Dostęp do projektu	Członek projektu .
uprawnienia	— Wyświetlanie kodu w projektach prywatnych: co najmniej dostęp na poziomie Podstawowym. — Klonowanie lub współtworzenie kodu w prywatnych projektach: członkostwo w grupie zabezpieczeń Współautorzy lub odpowiednie uprawnienia w projekcie. — Ustaw uprawnienia gałęzi lub repozytorium: Zarządzanie uprawnieniami dla gałęzi lub repozytorium. - Zmień gałąź domyślną: Edytuj zasady uprawnienia dla repozytorium. — Zaimportuj repozytorium: członek grupy zabezpieczeń Administratorzy projektów lub uprawnienia na poziomie projektu Git Utwórz repozytorium ustawione na Dozwolone. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień repozytorium Git.
Usługi	Repozytoria włączone.
Narzędzia	Opcjonalny. Użyj poleceń az repos: Azure DevOps CLI.

Uwaga

W projektach publicznych użytkownicy z dostępem Stakeholder mają pełny dostęp do usługi Azure Repos, w tym wyświetlanie, klonowanie i współtworzenie kodu.

Uwaga

Przed podjęciem próby migracji kodu źródłowego ze scentralizowanego systemu kontroli wersji do usługi Git należy zapoznać się z różnicami między scentralizowanymi i rozproszonymi systemami kontroli wersji oraz zaplanować migrację zespołu. Po przygotowaniu możesz rozpocząć migrację.

Wysokopoziomowy przepływ pracy przy migracji z SVN do Git wygląda następująco:

• Przygotowywanie środowiska migracji
• Konwertowanie źródłowego repozytorium SVN na lokalne repozytorium Git
• (Opcjonalnie) Zsynchronizuj lokalne repozytorium Git z wszystkimi zmianami w repozytorium SVN, podczas gdy programiści nadal korzystają z SVN.
• Wypychanie lokalnego repozytorium Git do zdalnego repozytorium Git hostowanego w usłudze Azure Repos
• Zablokuj repozytorium SVN, zsynchronizuj wszelkie pozostałe zmiany z repozytorium SVN do lokalnego repozytorium Git i wypchnij ostateczne zmiany do zdalnego repozytorium Git w usłudze Azure Repos
• Deweloperzy przełączają się do usługi Git jako głównego systemu kontroli źródła

Przygotowywanie środowiska migracji

Skonfiguruj środowisko migracji na lokalnej stacji roboczej i zainstaluj następujące oprogramowanie:

• Usługa Git
• Subversion
• narzędzie git-svn (już część usługi Git)

Musisz również utworzyć repozytorium Git dla organizacji w celu hostowania przekonwertowanego repozytorium SVN. W projekcie możesz utworzyć nowe repozytorium Git.

Konwertowanie źródłowego repozytorium SVN na lokalne repozytorium Git

Celem tego kroku jest przekonwertowanie źródłowego repozytorium Subversion na lokalne, nagie repozytorium Git. Czyste repozytorium Git nie zawiera lokalnej kopii roboczej plików, które można zmieniać, zamiast tego zawiera tylko historię repozytorium oraz metadane dotyczące samego repozytorium. Jest to zalecany format udostępniania repozytorium Git za pośrednictwem repozytorium zdalnego hostowanego w usłudze, takiej jak Azure Repos.

Napiwek

Nagie repozytoria Git są inaczej skonstruowane, a fakt, że nie mają katalogu roboczego, uniemożliwia bezpośrednie zatwierdzanie do repozytorium.

Pobierz listę wszystkich autorów Subversion

Subversion używa tylko nazwy użytkownika dla każdego zatwierdzenia, podczas gdy usługa Git przechowuje zarówno rzeczywistą nazwę, jak i adres e-mail. Domyślnie narzędzie git-svn wyświetli nazwę użytkownika SVN w polach autora i wiadomości e-mail. Można jednak utworzyć plik mapowania dla użytkowników SVN wraz z odpowiednimi nazwami i adresami e-mail Git.

Użytkownicy Subversion

Użytkownicy usługi Git

Aby wyodrębnić listę wszystkich użytkowników SVN z katalogu głównego lokalnego katalogu roboczego Subversion, uruchom następujące polecenie programu PowerShell:

Aby uzyskać wyniki kodowania utf8NoBOM , uruchom następujące polecenie:

svn.exe log --quiet | ? { $_ -notlike '-*' } | % { "{0} = {0} " -f ($_ -split ' | ')[1] } | Select-Object -Unique | Sort-Object | Out-File 'authors-transform.txt' -Encoding utf8NoBOM

Aby uzyskać wyniki kodowania ASCII , uruchom następujące polecenie:

svn.exe log --quiet | ? { $_ -notlike '-*' } | % { "{0} = {0} " -f ($_ -split ' | ')[1] } | Select-Object -Unique | Sort-Object | Out-File 'authors-transform.txt' -Encoding ASCII

To polecenie spowoduje pobranie wszystkich komunikatów dziennika, wyodrębnienie nazw użytkowników, wyeliminowanie zduplikowanych nazw użytkowników, sortowanie nazw użytkowników i umieszczenie ich w pliku authors-transform.txt w formacie UTF-8 (lub w formacie ASCII, w zależności od określonego kodowania). Następnie można edytować każdy wiersz w pliku, aby utworzyć mapowanie użytkowników SVN na dobrze sformatowanych użytkowników usługi Git. Na przykład można mapować jamal = jamal <jamal> na jamal = Jamal Hartnett <jamal@fabrikam-fiber.com>.

Klonowanie repozytorium Subversion przy użyciu narzędzia git-svn

Następujące polecenie wykona standardową transformację git-svn przy użyciu pliku authors-transform.txt utworzonego we wcześniejszym kroku. Spowoduje to umieszczenie repozytorium Git w folderze c:\mytempdir na komputerze lokalnym.

git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --authors-file "authors-transform.txt" --stdlayout c:\mytempdir

Uwaga

Jest --prefix=svn/ to konieczne, ponieważ w przeciwnym razie narzędzia nie mogą rozróżniać poprawek SVN od importowanych. Zalecamy ustawienie prefiksu (z ukośnikiem końcowym), ponieważ odnośniki śledzenia SVN będą znajdować się w refs/remotes/$prefix/, co jest zgodne z własnym schematem gałęzi śledzenia zdalnego Git (refs/remotes/$remote/).

Ustawienie prefiksu jest również przydatne, jeśli chcesz śledzić wiele projektów współużytkujących wspólne repozytorium. Domyślnie prefiks jest ustawiony na origin/.

Jeśli używasz standardowego układu główny, gałęzie, tagi, wystarczy umieścić --stdlayout. Jeśli jednak masz coś innego, być może trzeba będzie przekazać --trunk, --branches i --tags, aby znaleźć, co jest czym. Na przykład, jeśli struktura repozytorium była trunk/companydir i gdy rozgałęzisz to zamiast głównej gałęzi, prawdopodobnie będziesz chciał/a użyć --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

Uwaga

To polecenie może potrwać od kilku minut do kilku godzin w zależności od rozmiaru repozytorium SVN. Po zakończeniu będziesz mieć kopię roboczą swojego repozytorium Git.

Konwertowanie konfiguracji specyficznych dla kontroli wersji

Jeśli repozytorium SVN używało właściwości svn:ignore, możesz przekonwertować na plik gitignore przy użyciu polecenia:

cd c:\mytempdir
git svn show-ignore --id=origin/trunk > .gitignore
git add .gitignore
git commit -m 'Convert svn:ignore properties to .gitignore.'

Napiwek

Przeczytaj więcej o .gitignore: Ignoruj zmiany plików za pomocą narzędzia Git

Wypchnij repozytorium do nagiego repozytorium Git

W tym kroku utworzysz puste repozytorium i ustawisz, aby jego domyślna gałąź miała taką samą nazwę jak gałąź trunk SVN.

1. Utwórz nagie repozytorium Git

   git init --bare c:\new-bare.git
   cd c:\new-bare.git
   git symbolic-ref HEAD refs/heads/svn/trunk
   

2. Wypchnij lokalne repozytorium Git do nowego nagiego repozytorium Git

   cd c:\mytempdir 
   git remote add bare c:\new-bare.git 
   git config remote.bare.push refs/remotes/*:refs/heads/* 
   git push bare 
   

3. Zmień nazwę gałęzi na trunkmain. Główna gałąź rozwoju będzie miała nazwę "trunk", która odpowiada nazwie w Subversion. Należy zmienić jego nazwę na standardowa main gałąź usługi Git przy użyciu:

   cd c:\new-bare.git
   git branch -m svn/trunk main
   

4. Czyszczenie gałęzi i tagów: git-svn przekształca wszystkie tagi Subversion na bardzo krótkie gałęzie w Git w formacie "tags/name". Należy przekonwertować wszystkie te gałęzie na rzeczywiste tagi Git lub je usunąć.

Migrowanie tagów SVN jako tagów usługi 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/$_" }

Migracje zaawansowane

Utwórz wszystkie gałęzie SVN jako odpowiednie gałęzie usługi Git

Chociaż można łatwo utworzyć wszystkie gałęzie SVN jako odpowiednie gałęzie usługi Git, zaleca się przeprowadzenie oceny następujących punktów przed kontynuowaniem:

• Jeśli istnieją funkcjonalne gałęzie, czy możesz poczekać, aż zintegrują się z główną gałęzią przed migracją?

• Jeśli istnieją gałęzie wydawnicze: czy warto zachować SVN do obsługi? Jeśli migrujesz gałęzie funkcjonalności, czy jesteś przygotowany do obsługiwania gałęzi poza Gitem?

Jeśli nadal chcesz migrować istniejące gałęzie, uruchom następujące polecenie programu PowerShell:

git for-each-ref --format='%(refname)' refs/remotes | % { $_.Replace('refs/remotes/','') } | % { git branch "$_" "refs/remotes/$_"; git branch -r -d "$_"; }

Uwaga

To polecenie może potrwać od kilku minut do kilku godzin w zależności od rozmiaru repozytorium SVN. Po zakończeniu będziesz mieć wyewidencjonowania repozytorium Git.

Migruj tylko określone wersje

Jeśli nie zostanie określony, git-svn clone zmigruje wszystkie poprawki z pierwszego zatwierdzenia (r1) do funkcji HEAD. Jeśli musisz przeprowadzić migrację tylko określonego zestawu poprawek, polecenie git-svn clone należy uzupełnić o opcję -r.

Jeśli na przykład musisz przeprowadzić migrację z rev 100 do HEAD, polecenie wygląda następująco:

git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --authors-file "authors-transform.txt" --stdlayout c:\mytempdir -r100:HEAD

Aktualizowanie przepływu pracy

Przejście ze scentralizowanego systemu kontroli wersji do usługi Git to nie tylko migracja kodu. Twój zespół musi trenować, aby zrozumieć, jak usługa Git różni się od istniejącego systemu kontroli wersji i jak te różnice wpływają na codzienną pracę. Dowiedz się więcej.

Informacje referencyjne

• Wybieranie właściwej kontroli wersji dla swojego projektu
• Dowiedz się więcej o usłudze Git
• Ignoruj zmiany plików za pomocą usługi Git
• Migrowanie z serwera TFVC do usługi Git

Autorzy: Hosam Kamel, William H. Salazar | Znajdź źródło tego artykułu i połącz się z ALM | DevOps Rangers - Wskazówki dotyczące rozgałęzień

c) 2017 Microsoft Corporation. Wszelkie prawa zastrzeżone. Ten dokument jest dostarczany "tak, jak jest". Informacje i opinie wyrażone w tym dokumencie, w tym adres URL i inne odwołania do stron internetowych, mogą ulec zmianie bez powiadomienia. Ryzyko korzystania z niniejszego dokumentu ponosi użytkownik.

Ten dokument nie zapewnia użytkownikowi żadnych praw do własności intelektualnej w żadnym produkcie firmy Microsoft. Dozwolone jest kopiowanie niniejszego dokumentu i korzystanie z niego do własnych celów pomocniczych.