Close

Migracja SVN do Git — przygotowanie do migracji

W artykule Po co Twojej organizacji Git? omówiliśmy wiele przykładów tego, jak Git może pomóc Twojemu zespołowi stać się bardziej zwinnym. Gdy już podejmiesz decyzję o migracji, musisz zastanowić się, jak przenieść dotychczasowy przepływ prac programistycznych do Git.

W tym artykule objaśniono największe zmiany, które napotkasz podczas przenoszenia swojego zespołu ze środowiska SVN do Git. Najważniejszą rzeczą, o jakiej należy pamiętać w trakcie migracji, jest fakt, że Git to nie SVN. Aby w pełni wykorzystać potencjał Git, postaraj się w jak największym stopniu otworzyć na nowe sposoby myślenia o kontroli wersji.


Dla administratorów


W zależności od wielkości zespołu wdrożenie Git może trwać od kilku dni do kilku miesięcy. W tej części omówiono najważniejsze kwestie związane ze szkoleniem pracowników w zakresie Git oraz migracją repozytoriów z SVN do Git, które muszą wziąć pod uwagę menedżerowie ds. inżynierii.

Podstawowe polecenia Git


Dawniej panowała obiegowa opinia, jakoby Git był trudny do opanowania. Jednak osoby zajmujące się tym systemem stale wydają nowe ulepszenia, takie jak intuicyjne ustawienia domyślne i komunikaty pomocy kontekstowej, które znacznie uprzyjemniają proces onboardingu.

Atlassian oferuje kompleksową serię samouczków Git, które można przerabiać we własnym tempie, a także webinaria oraz sesje szkoleniowe na żywo. Razem tworzą one wyczerpujący zbiór opcji szkoleniowych, które wystarczą zespołowi do rozpoczęcia pracy z Git. Na początek zamieszczamy poniżej wykaz podstawowych poleceń systemu Git, które pomogą rozpocząć korzystanie z niego:

Bazy danych
materiały pokrewne

Jak przenieść pełne repozytorium Git

Logo Bitbucket
POZNAJ ROZWIĄZANIE

Poznaj środowisko Git z rozwiązaniem Bitbucket Cloud

Zadanie w Git

Notatki

Polecenia Git

Dodanie w Git swoich danych

Notatki

Skonfiguruj imię i nazwisko oraz adres e-mail autora. Będą one używane w Twoich commitach. Pamiętaj, że Git usuwa niektóre znaki (np. kropki na końcu) ze zmiennej user.name.

Polecenia Git

git config --global user.name "Jan Nowak"git config --global user.email jan@example.com

Utworzenie nowego repozytorium lokalnego

Notes

 

Polecenia Git

git init

Wyewidencjonowanie repozytorium

Notatki

Utwórz kopię roboczą repozytorium lokalnego:

Polecenia Git

git clone /ścieżka/do/repozytorium

 

Notatki

W przypadku serwera zdalnego użyj polecenia:

Polecenia Git

git clone nazwaużytkownika@host:/ścieżka/do/repozytorium

Dodanie plików

Notatki

Dodaj co najmniej jeden plik do przechowalni (indeksu):

Polecenia Git

git add *

Commit

Notatki

Zatwierdź zmiany w gałęzi określanej przez wskaźnik HEAD (ale jeszcze nie w zdalnym repozytorium):

Polecenia Git

git commit -m "Komunikat dotyczący commita"

 

Notatki

Zatwierdź wszystkie pliki dodane za pomocą polecenia git add, a także wszystkie pliki zmodyfikowane od tamtego czasu:

Polecenia Git

git commit -a

Naciśnij

Notatki

Wyślij zmiany do gałęzi main repozytorium zdalnego:

Polecenia Git

git push origin main

Status

Notatki

Wyświetl listę plików zmodyfikowanych oraz tych, które trzeba dodać lub zatwierdzić:

Polecenia Git

git status

Łączenie ze zdalnym repozytorium

Notatki

Jeśli repozytorium lokalne nie jest połączone ze zdalnym serwerem, dodaj serwer, aby móc wypychać do niego:

Polecenia Git

git remote add origin

 

Notatki

Wyświetl listę wszystkich aktualnie skonfigurowanych repozytoriów zdalnych:

Polecenia Git

git remote -v

Gałąź

Notatki

Utwórz nową gałąź i przełącz się na nią:

Polecenia Git

git checkout -b

 

Notatki

Przełącz się z jednej gałęzi na drugą:

Polecenia Git

git checkout

 

Notatki

Wyświetl listę wszystkich gałęzi w repozytorium wraz ze wskazaniem gałęzi, w której się aktualnie znajdujesz:

Polecenia Git

git branch

 

Notatki

Usuń gałąź funkcji:

Polecenia Git

git branch -d

 

Notatki

Wypchnij gałąź do repozytorium zdalnego, aby inni mogli z niej skorzystać:

Polecenia Git

git push origin

 

Notatki

Wypchnij wszystkie gałęzie do repozytorium zdalnego:

Polecenia Git

git push --all origin

 

Notatki

Usuń gałęzie z repozytorium zdalnego:

Polecenia Git

git push origin :

Aktualizowanie z repozytorium zdalnego

Notatki

Pobierz i scal zmiany z serwera zdalnego ze swoim katalogiem roboczym:

Polecenia Git

git pull

 

Notatki

Scal inną gałąź z aktywną gałęzią:

Polecenia Git

git merge

 

Notatki

Wyświetl wszystkie konflikty scalania: Wyświetl konflikty z plikiem bazowym: Wyświetl podgląd zmian przed scaleniem:

Polecenia Git

git diff
git diff --base
git diff

 

Notatki

Po ręcznym rozwiązaniu wszelkich konfliktów oznacz zmodyfikowany plik:

Polecenia Git

git add

Tagi

Notatki

Za pomocą tagów możesz oznaczyć ważny zestaw zmian, na przykład wydanie:

Polecenia Git

git tag 1.0.0

 

Notatki

Identyfikator commita to początkowe znaki (maksymalnie 10) identyfikatora zestawu zmian. Musi on być unikatowy. Pobierz identyfikator:

Polecenia Git

git log

 

Notatki

Wypchnij wszystkie tagi do repozytorium zdalnego:

Polecenia Git

git push --tags origin

Cofanie zmian lokalnych

Notatki

Jeśli popełnisz błąd, możesz zastąpić zmiany wprowadzone w drzewie roboczym ostatnią zawartością z gałęzi określanej przez wskaźnik HEAD: Zmiany już dodane do indeksu oraz nowe pliki zostaną zachowane.

Polecenia Git

git checkout --

 

Notatki

Możesz również odrzucić wszystkie zmiany lokalne i commity, pobrać najnowszą historię z serwera i ustawić na nią wskaźnik lokalnej gałęzi main:

Polecenia Git

git fetch origin git reset --hard origin/main

Wyszukiwanie

Notatki

Wyszukaj katalog roboczy dla foo():

Polecenia Git

git grep "foo()"

Narzędzia do migracji Git


Dostępnych jest wiele narzędzi ułatwiających migrację istniejących projektów z SVN do Git, jednak zanim zdecydujesz się na wybór konkretnych narzędzi, musisz ustalić sposób migracji kodu. Dostępne są następujące opcje:

  • Migracja całej bazy kodu do Git i całkowite zaprzestanie korzystania ze środowiska SVN.
  • Zaniechanie migracji dotychczasowych projektów do systemu Git, ale tworzenie w nim wszystkich nowych projektów.
  • Migracja niektórych projektów do Git, ale kontynuowanie korzystania z SVN do obsługi pozostałych projektów.
  • Równoczesne korzystanie z SVN i Git w tych samych projektach.

Całkowite przejście na Git pozwala ograniczyć złożoność przepływu prac programistycznych, w związku z tym jest to opcja preferowana. Jednak nie zawsze jest to możliwe w większych firmach z dziesiątkami zespołów programistycznych i potencjalnie setkami projektów. W takich sytuacjach bezpieczniejszą opcją jest podejście hybrydowe.

Dobór narzędzi migracji zależy w dużej mierze od tego, którą z powyższych strategii wybierzesz. Poniżej przedstawiono niektóre z najpopularniejszych narzędzi do migracji z SVN do Git.

Skrypty migracji firmy Atlassian

Jeśli chcesz dokonać błyskawicznego przejścia na Git, skrypty migracji firmy Atlassian będą dobrym rozwiązaniem. Uwzględniają one wszystkie narzędzia potrzebne do niezawodnej konwersji istniejących repozytoriów SVN na repozytoria Git. Uzyskana w efekcie ich użycia natywna dla Git historia pozwoli uniknąć problemów ze współdziałaniem SVN i Git po przeprowadzeniu konwersji.

Udostępniliśmy kompletny przewodnik techniczny dotyczący korzystania z tych skryptów do konwersji całej bazy kodu na kolekcję repozytoriów Git. Objaśniono w nim wszystkie zagadnienia — od wyodrębniania danych autora z SVN po reorganizację niestandardowych struktur repozytoriów SVN.

Wtyczka SVN Mirror for Stash (teraz Bitbucket)

SVN Mirror for StashSVN Mirror for Stash jest wtyczką Bitbucket, która w prosty sposób umożliwia prowadzenie hybrydowej bazy kodu współpracującej zarówno ze środowiskiem SVN, jak i Git. W odróżnieniu od skryptów migracji firmy Atlassian wtyczka SVN Mirror for Stash umożliwia równoczesne korzystanie z Git i SVN w tym samym projekcie przez dowolny czas.

To kompromisowe rozwiązanie to świetna opcja dla większych firm. Umożliwia stopniowe wdrażanie Git, pozwalając różnym zespołom na migrację przepływów pracy w dogodnym dla nich czasie.

Czym jest Git-SVN?

Narzędzie git-svn jest interfejsem między lokalnym repozytorium Git a zdalnym repozytorium SVN. Umożliwia programistom pisanie kodu i tworzenie commitów lokalnie w Git, a następnie wypychanie ich do centralnego repozytorium SVN w sposób właściwy dla commitów SVN. Takie rozwiązanie powinno mieć charakter tymczasowy, jednak przydaje się przy rozważaniu przejścia z SVN na Git.

Narzędzie git-svn jest dobrą opcją, gdy organizacja nie jest jeszcze zdecydowana na przejście na Git i chce dać programistom możliwość zapoznania się z Git bez przeprowadzania pełnej migracji. Idealnie nadaje się również do użycia podczas fazy szkoleniowej. Zamiast nagłego przejścia Twój zespół może najpierw zapoznać się z lokalnymi poleceniami Git, zanim zacznie się martwić o przepływy pracy bazujące na współpracy.

Należy pamiętać, że stosowanie narzędzia git-svn powinno być jedynie tymczasową fazą procesu migracji. W kwestii backendu bazuje ono wciąż na systemie SVN, dlatego nie daje możliwości skorzystania z bardziej złożonych funkcji Git, takich jak tworzenie gałęzi czy zaawansowane przepływy pracy oparte na współpracy.

Strategie wprowadzenia

Migracja bazy kodu jest tylko jednym z aspektów wdrażania Git. Trzeba również zastanowić się na sposobem wprowadzenia Git wśród osób stojących za tą bazą kodu. Trzy główne strategie migracji zespołu programistycznego do Git zakładają wykorzystanie konsultantów zewnętrznych, wewnętrznych specjalistów ds. Git oraz zespołów pilotażowych.

Zewnętrzni konsultanci Git

Konsultanci zajmujący się Git są w stanie w zasadniczej części przeprowadzić za Ciebie proces migracji za symboliczną opłatą. Zaletą takiego rozwiązania jest utworzenie przepływu pracy Git doskonale dopasowanego do potrzeb Twojego zespołu bez konieczności poświęcania czasu na jego samodzielne opracowywanie. Ponadto w trakcie nauki Git Twój zespół zyskuje dostęp do zasobów szkoleniowych eksperta. Partnerzy Atlassian są specjalistami w dziedzinie migracji z SVN do Git i warto od nich zacząć, szukając konsultanta Git.

Z drugiej strony samodzielne zaprojektowanie i wdrożenie przepływu pracy opartego na Git będzie dla Twojego zespołu świetnym sposobem zrozumienia meandrów własnego procesu programistycznego. Pozwoli to uniknąć pozostawienia zespołu samego sobie po zakończeniu pracy przez konsultanta.

Wewnętrzni specjaliści ds. Git

Specjalistą ds. Git będzie programista w Twojej firmie entuzjastycznie nastawiony do używania Git. Skorzystanie z pomocy takiej osoby jest dobrym rozwiązaniem dla firm, w której kultura programistyczna jest mocno rozwinięta, a programiści czują się komfortowo, stosując nowe rozwiązania. Zamysł polega na zapewnieniu jednemu z inżynierów możliwości uzyskania statusu eksperta w dziedzinie Git, aby mógł on zaprojektować oparty na Git przepływ pracy dostosowany do potrzeb firmy oraz pełnić funkcję wewnętrznego konsultanta, gdy nadejdzie czas przejścia reszty zespołu na Git.

Zaletą takiego rozwiązania w porównaniu z zaangażowaniem konsultanta zewnętrznego jest zatrzymanie specjalistycznej wiedzy dotyczącej Git w firmie. Wymaga ono jednak poświęcenia większej ilości czasu na wyszkolenie specjalisty ds. Git, a także stwarza ryzyko wybrania nieprawidłowego przepływu pracy Git lub jego niewłaściwego wdrożenia.

Zespoły pilotażowe

Trzecią opcją przejścia na Git jest przetestowanie go w zespole pilotażowym. Rozwiązanie to sprawdzi się najlepiej, gdy masz niewielki zespół, który pracuje nad względnie odizolowanym projektem. Ta opcja zadziała jeszcze lepiej, jeśli w zespole pilotażowym połączy się zewnętrznych konsultantów z wewnętrznymi specjalistami ds. Git.

Zaletą jest w tym przypadku konieczność uzyskania aprobaty całego zespołu, a także ograniczenie ryzyka wyboru niewłaściwego przepływu pracy, ponieważ przy projektowaniu nowego procesu programistycznego uwzględnia się opinie całego zespołu. Innymi słowy, brakujące elementy wychwytuje się szybciej niż w przypadku samodzielnego projektowania nowego przepływu pracy przez konsultanta lub specjalistę.

Z drugiej strony skorzystanie z zespołu pilotażowego oznacza więcej szkolenia na początku oraz dłuższy czas konfiguracji: zamiast jednego programisty pracującego nad nowym przepływem pracy mamy do czynienia z potencjalnym tymczasowym obniżeniem produktywności całego zespołu związanym z zapoznawaniem się z nowym przepływem pracy. Jednak długofalowe korzyści zdecydowanie przewyższają te krótkotrwałe trudności.

Bezpieczeństwo i uprawnienia

Kontrola dostępu jest tym aspektem Git, który wymaga fundamentalnego przemyślenia sposobu zarządzania bazą kodu.

W SVN cała baza kodu jest zazwyczaj przechowywana w jednym centralnym repozytorium, natomiast dostęp dla różnych zespołów i osób ogranicza się na poziomie poszczególnych folderów. W Git nie ma takiej możliwości: programiści muszą pobrać całe repozytorium, aby na nim pracować. Zazwyczaj nie można pobrać podzbioru repozytorium, jak w środowisku SVN. Uprawnienia można przyznawać tylko do całych repozytoriów Git.

Oznacza to, że musisz podzielić swoje duże, monolityczne repozytorium SVN na kilka małych repozytoriów Git. W Atlassian doświadczyliśmy tego na własnej skórze, gdy nasz zespół programistyczny pracujący nad systemem Jira przeprowadził migrację do Git. Wszystkie nasze wtyczki Jira były przechowywane w jednym repozytorium SVN, ale po migracji każda trafiła do własnego repozytorium.

Należy pamiętać, że Git został zaprojektowany z myślą o bezpiecznej integracji fragmentów kodu tworzonych przez tysiące niezależnych programistów systemu Linux, dlatego zdecydowanie oferuje jakąś możliwość skonfigurowania dowolnego rodzaju kontroli dostępu, której potrzebuje Twój zespół. Może to jednak wymagać świeżego spojrzenia na cykl kompilowania.

Jeśli obawiasz się o utrzymanie zależności między nową kolekcją repozytoriów Git, przydatne może okazać się zastosowanie dodatkowej warstwy zarządzania zależnościami ponad systemem Git. Warstwa zarządzania zależnościami pomoże skrócić czasy kompilowania, ponieważ w miarę rozrastania się projektu do przyspieszenia kompilowania konieczne będzie „buforowanie”. Wykaz zalecanych narzędzi do tworzenia warstwy zarządzania zależnościami dla każdego zestawu rozwiązań technologicznych można znaleźć w przydatnym artykule: „Git i zależności projektu”.

Dla programistów


Repozytorium dla każdego programisty

Największą zmianą, do której musi przyzwyczaić się programista, jest rozproszony charakter środowiska Git. Zamiast jednego centralnego repozytorium, każdy programista ma własną kopię całego repozytorium. To radykalnie zmienia sposób współpracy z innymi programistami.

Zamiast wyewidencjonowywania repozytorium SVN za pomocą polecenia svn checkout i pobrania kopii roboczej, klonuje się całe repozytorium Git na własny komputer lokalny za pomocą polecenia git clone.

Współpraca odbywa się poprzez przenoszenie gałęzi między repozytoriami za pomocą poleceń git push, git fetch lub git pull. Udostępnianie odbywa się zwykle na poziomie gałęzi w Git, jednak może mieć miejsce także na poziomie commita, jak w SVN. Jednak w Git commit odzwierciedla całościowy stan całego projektu, a nie modyfikacje poszczególnych plików. Z uwagi na możliwość korzystania z gałęzi zarówno w Git, jak i w SVN, tym, co wyróżnia system Git, jest możliwość zatwierdzania lokalnego, bez udostępniania pracy. Zapewnia to większą swobodę eksperymentowania, pozwala skuteczniej pracować w trybie offline i przyspiesza niemal wszystkie polecenia związane z kontrolą wersji.

Trzeba jednak pamiętać, że zdalne repozytorium nie jest bezpośrednim łączem do repozytorium innego użytkownika. To po prostu zakładka, która eliminuje konieczność ponownego wprowadzania całego adresu URL za każdym razem, gdy wchodzisz w interakcję ze zdalnym repozytorium. Dopóki nie ściągniesz gałęzi ze zdalnego repozytorium lub jej do niego nie wypchniesz, pracujesz w odizolowanym środowisku.

Inną dużą zmianą dla użytkowników SVN jest podział na repozytoria „lokalne” i „zdalne”. Repozytoria lokalne znajdują się na komputerze lokalnym, natomiast wszystkie inne repozytoria nazywane są repozytoriami zdalnymi. Zdalne repozytorium służy głównie do udostępniania kodu pozostałym członkom zespołu, dlatego w tych repozytoriach nie prowadzi się aktywnie prac programistycznych. Repozytoria lokalne znajdują się na komputerze lokalnym i właśnie w nich prowadzone są wszystkie prace programistyczne.

Nie obawiaj się tworzenia gałęzi ani scalania

W SVN zatwierdzasz kod, edytując pliki w kopii roboczej, a następnie wykonując polecenie svn commit, aby wysłać kod do centralnego repozytorium. Wszyscy inni mogą następnie pobrać te zmiany do własnych kopii roboczych za pomocą polecenia svn update. Gałęzie SVN są zazwyczaj zarezerwowane dla dużych, długofalowych fragmentów projektu, ponieważ scalanie bywa niebezpieczne i może doprowadzić do uszkodzenia projektu.

W Git podstawowy przepływ prac programistycznych jest zupełnie inny. Zamiast powiązania z jedną linią prac programistycznych (np. trunk/) wszystko kręci się wokół tworzenia i scalania gałęzi.

Aby rozpocząć pracę nad czymkolwiek w Git, musisz utworzyć i wyewidencjonować nową gałąź za pomocą polecenia git checkout -b . W ten sposób tworzysz specjalną linię prac programistycznych, w której możesz pisać kod bez obawy, że będzie to miało wpływ na kogokolwiek innego w Twoim zespole. Jeśli zepsujesz coś do tego stopnia, że naprawa będzie niemożliwa, wystarczy, że odrzucisz gałąź za pomocą polecenia git branch -d . Gdy z kolei opracujesz coś przydatnego, tworzysz pull request z prośbą o scalenie tego z gałęzią main.

Potencjalne przepływy pracy Git

Przy wyborze przepływu pracy Git ważne jest, aby wziąć pod uwagę potrzeby swojego zespołu. Prosty przepływ pracy może zmaksymalizować tempo i elastyczność prac programistycznych, a bardziej złożony przepływ pracy może zapewnić większą spójność i kontrolę nad pracami w toku. Możesz wdrożyć i połączyć wymienione poniżej ogólne podejścia, dostosowując je do różnych potrzeb i ról w zespole. Główny programista może korzystać z gałęzi funkcji, podczas gdy wykonawca będzie na przykład pracował na podziale.

  • Scentralizowany przepływ pracy jest najbardziej zbliżony do powszechnie stosowanych procesów SVN, dlatego stanowi on dobrą opcję na początek.
  • Kontynuując tę myśl, korzystanie z przepływu pracy gałęzi funkcji pozwala programistom odizolować prace w toku i chronić ważne gałęzie współdzielone. Gałęzie funkcji dają również podstawę do zarządzania zmianami przy użyciu pull requestów.
  • Przepływ pracy Gitflow jest bardziej formalnym, ustrukturyzowanym rozszerzeniem podejścia opartego na gałęziach funkcji, co czyni go świetną opcją dla większych zespołów mających dobrze zdefiniowane cykle wydawania.
  • Warto również rozważyć przepływ pracy z podziałem, jeśli potrzebujesz maksymalnej izolacji i kontroli nad zmianami, gdy na jednym repozytorium pracuje wielu programistów.

Jeśli jednak, jako zespół profesjonalistów, chcecie w pełni wykorzystać potencjał Git, warto rozważyć przepływ pracy oparty na gałęziach funkcji. Jest to autentycznie rozproszony przepływ pracy, który zapewnia wysoki poziom bezpieczeństwa, duże możliwości skalowania i stanowi kwintesencję podejścia Agile.

Wnioski


Przeniesienie zespołu do Git może, ale wcale nie musi być trudne. W tym artykule omówiono kilka często spotykanych opcji migracji istniejącej bazy kodu, wprowadzania Git w zespołach programistycznych oraz radzenia sobie z kwestią bezpieczeństwa i uprawnień. Przedstawiliśmy również największe wyzwania, na które programiści powinni się przygotować w trakcie migracji.

Mamy nadzieję, że masz teraz solidne podstawy do wdrożenia rozproszonego procesu programistycznego w swojej firmie, niezależnie od jej rozmiaru i stosowanych dotychczas praktyk.


Udostępnij ten artykuł
Następny temat

Zalecane lektury

Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.

Ludzie współpracujący przy ścianie pełnej narzędzi

Blog Bitbucket

Ilustracja DevOps

Ścieżka szkoleniowa DevOps

Demonstracje funkcji z ekspertami Atlassian

Zobacz, jak Bitbucket Cloud współpracuje z Atlassian Open DevOps

Zapisz się do newslettera DevOps

Thank you for signing up