Git
git-svn

Android Bash C# Language Java Language GNU/Linux Node.js PHP Python Language Ruby Language Ruby on Rails
Szukaj…


Uwagi

Klonowanie naprawdę dużych repozytoriów SVN

Jeśli historia repozytorium SVN jest naprawdę duża, operacja może zająć wiele godzin, ponieważ git-svn musi odbudować pełną historię repozytorium SVN. Na szczęście wystarczy sklonować repozytorium SVN; podobnie jak w przypadku każdego innego repozytorium git, możesz po prostu skopiować folder repo do innych współpracowników. Kopiowanie folderu na wiele komputerów będzie szybsze niż klonowanie dużych repozytoriów SVN od zera.

Informacje o zatwierdzeniach i SHA1

Twoje lokalne polecenia git zostaną przepisane, gdy użyjesz polecenia git svn dcommit . To polecenie doda tekst do komunikatu git commit, odwołując się do wersji SVN utworzonej na serwerze SVN, co jest bardzo przydatne. Jednak dodanie nowego tekstu wymaga zmodyfikowania istniejącego komunikatu zatwierdzenia, czego w rzeczywistości nie można zrobić: git commits są niezmienne. Rozwiązaniem jest utworzenie nowego zatwierdzenia o tej samej treści i nowej wiadomości, ale technicznie i tak jest to nowe zatwierdzenie (tj. SHA1 git commit zmieni się)

Ponieważ polecenia git utworzone dla git-svn są lokalne, identyfikatory SHA1 dla poleceń git są różne dla każdego repozytorium git! Oznacza to, że nie można użyć SHA1 do odwołania do zatwierdzenia innej osoby, ponieważ to samo zatwierdzenie będzie miało inny SHA1 w każdym lokalnym repozytorium git. Jeśli chcesz odwoływać się do zatwierdzenia między różnymi kopiami repozytorium, musisz polegać na numerze wersji svn dołączonym do komunikatu zatwierdzenia podczas wypychania do serwera SVN.

Możesz jednak używać SHA1 do operacji lokalnych (pokaż / różnicuj konkretne zatwierdzenie, wybory wiśniowe i resety itp.)

Rozwiązywanie problemów

polecenie git svn rebase powoduje błąd niezgodności sumy kontrolnej

Polecenie git svn rebase generuje błąd podobny do następującego: 

  Checksum mismatch: <path_to_file> <some_kind_of_sha1>
  expected: <checksum_number_1>
    got: <checksum_number_2>

Rozwiązaniem tego problemu jest zresetowanie svn do wersji, gdy problematyczny plik został zmodyfikowany po raz ostatni, i wykonaj pobieranie git svn, aby przywrócić historię SVN. Polecenia wykonania resetu SVN to:

  • git log -1 - <path_to_file> (skopiuj numer wersji SVN, który pojawia się w komunikacie zatwierdzenia)
  • git svn reset <revision_number>
  • pobierz git svn

Powinieneś być w stanie ponownie wypychać / wyciągać dane z SVN

Plik nie został znaleziony w zatwierdzeniu Podczas próby pobrania lub pobrania z SVN pojawia się błąd podobny do tego 

<file_path> was not found in commit <hash>

Oznacza to, że wersja SVN próbuje zmodyfikować plik, który z jakiegoś powodu nie istnieje w lokalnej kopii. Najlepszym sposobem na pozbycie się tego błędu jest wymuszenie pobierania ignorującego ścieżkę tego pliku i zostanie on zaktualizowany do stanu w najnowszej wersji SVN:

  • git svn fetch --ignore-paths <file_path>

Klonowanie repozytorium SVN

Musisz utworzyć nową lokalną kopię repozytorium za pomocą polecenia

git svn clone SVN_REPO_ROOT_URL [DEST_FOLDER_PATH] -T TRUNK_REPO_PATH -t TAGS_REPO_PATH -b BRANCHES_REPO_PATH

Jeśli Twoje repozytorium SVN ma standardowy układ (pień, gałęzie, tagi foldery), możesz zapisać trochę pisania:

git svn clone -s SVN_REPO_ROOT_URL [DEST_FOLDER_PATH]

git svn clone sprawdza każdą wersję SVN, jeden po drugim, i wykonuje polecenie git w lokalnym repozytorium w celu odtworzenia historii. Jeśli repozytorium SVN ma wiele zatwierdzeń, zajmie to trochę czasu.

Po zakończeniu polecenia będziesz mieć pełnoprawne repozytorium git z lokalną gałęzią o nazwie master, która śledzi gałąź trunk w repozytorium SVN.

Pobieranie najnowszych zmian z SVN

Odpowiednikiem polecenia git pull jest polecenie 

git svn rebase

To pobiera wszystkie zmiany z repozytorium SVN i stosuje je w górnej części lokalnych zatwierdzeń w bieżącej gałęzi.

Możesz także użyć polecenia 

git svn fetch

aby pobrać zmiany z repozytorium SVN i przenieść je na komputer lokalny, ale bez zastosowania ich do lokalnego oddziału.

Przesunięcie lokalnych zmian do SVN

Komenda 

git svn dcommit

utworzy rewizję SVN dla każdego z lokalnych zatwierdzeń git. Podobnie jak w przypadku SVN, lokalna historia git musi być zsynchronizowana z najnowszymi zmianami w repozytorium SVN, więc jeśli polecenie się nie powiedzie, spróbuj najpierw wykonać git svn rebase .

Praca lokalna

Po prostu użyj lokalnego repozytorium git jako normalnego repozytorium git z normalnymi poleceniami git:

  • git add FILE i git checkout -- FILE Aby wprowadzić / wyrejestrować plik
  • git commit Aby zapisać zmiany. Te zatwierdzenia będą lokalne i nie będą „wypychane” do repozytorium SVN, tak jak w normalnym repozytorium git
  • git stash i git stash pop Zezwala na używanie skrytek
  • git reset HEAD --hard Cofnij wszystkie lokalne zmiany
  • git log Dostęp do całej historii w repozytorium
  • git rebase -i dzięki czemu możesz swobodnie przepisać swoją historię lokalną
  • git branch i git checkout aby utworzyć lokalne oddziały

Jak głosi dokumentacja git-svn „Subversion jest systemem, który jest znacznie mniej zaawansowany niż Git”, więc nie można wykorzystać całej mocy git bez zepsucia historii na serwerze Subversion. Na szczęście zasady są bardzo proste: Utrzymaj historię liniową

Oznacza to, że możesz wykonać prawie każdą operację git: tworzenie gałęzi, usuwanie / zmiana kolejności / zgniatanie zatwierdzeń, przenoszenie historii, usuwanie zatwierdzeń itp. Wszystko oprócz scalania . Jeśli chcesz ponownie zintegrować historię lokalnych oddziałów, użyj git rebase .

Podczas wykonywania scalania jest tworzone zatwierdzanie scalania. Szczególną cechą zatwierdzeń scalania jest to, że mają dwoje rodziców, co sprawia, że historia jest nieliniowa. Nieliniowa historia pomyli SVN w przypadku „wypchnięcia” zatwierdzenia scalania do repozytorium.

Jednak nie martw się: nic nie zepsujesz, jeśli „wypchniesz” zatwierdzenie scalania git do SVN . Jeśli to zrobisz, gdy polecenie git merge zostanie wysłane na serwer svn, będzie zawierać wszystkie zmiany wszystkich zatwierdzeń dla tego scalenia, więc stracisz historię tych zatwierdzeń, ale nie zmiany w kodzie.

Obsługa pustych folderów

git nie rozpoznaje pojęcia folderów, po prostu działa z plikami i ich ścieżkami plików. Oznacza to, że git nie śledzi pustych folderów. Jednak SVN tak. Użycie git-svn oznacza, że domyślnie wszelkie zmiany dotyczące pustych folderów za pomocą git nie będą propagowane do SVN .

Użycie flagi --rmdir podczas wydawania komentarza rozwiązuje ten problem i usuwa pusty folder w SVN, jeśli lokalnie usuniesz ostatni plik w nim:

git svn dcommit --rmdir

Niestety nie usuwa istniejących pustych folderów : musisz to zrobić ręcznie.

Aby uniknąć dodawania flagi za każdym razem, gdy wykonujesz polecenie, lub aby zagrać bezpiecznie, jeśli używasz narzędzia git GUI (takiego jak SourceTree), możesz ustawić to zachowanie jako domyślne za pomocą polecenia:

git config --global svn.rmdir true

To zmienia plik .gitconfig i dodaje następujące linie: 

[svn]
rmdir = true

Aby usunąć wszystkie nieśledzone pliki i foldery, które powinny być puste dla SVN, użyj polecenia git:

git clean -fd

Uwaga: poprzednie polecenie usunie wszystkie nieśledzone pliki i puste foldery, nawet te, które powinny być śledzone przez SVN! Jeśli chcesz wygenerować againg pustych folderów śledzonych przez SVN, użyj polecenia

git svn mkdirs

W praktyce oznacza to, że jeśli chcesz oczyścić swój obszar roboczy z nieśledzonych plików i folderów, zawsze powinieneś użyć obu poleceń do odtworzenia pustych folderów śledzonych przez SVN:

git clean -fd && git svn mkdirs



Modified text is an extract of the original Stack Overflow Documentation
Licencjonowany na podstawie CC BY-SA 3.0
Nie związany z Stack Overflow