Jak śledzić lokalne/zmiany zestawów zmian za pomocą git-svn?

Question

Chcę mieć pliki, które śledzę w moim lokalnym repozytorium git, które nie są rejestrowane w centralnym repozytorium svn, gdy uruchamiam git-svn dcommit. Często mam długotrwałe zmiany tylko lokalne w plikach śledzonych w repozytorium. Czasami służy do debugowania kodu. Mam również pliki IDE projektu, które chciałbym śledzić. Z prostym starym svn, po prostu umieściłbym te pliki w liście zmian o nazwie "XYZ: DO NOT CHECK IN", a następnie po prostu ręcznie poradzę sobie z problemem, gdy faktycznie mam zmiany, które muszę zatwierdzić.

Idealnie, chciałbym sprawdzić moje zmiany w moim głównym oddziale, ale ustawić coś, co uniemożliwia propagowanie tych konkretnych zmian do repozytorium svn. Używałbym git i git-svn w konwencjonalny sposób, ale niektóre poprawki nigdy się nie popychają. Oczywiście, mogę to zrobić ręcznie za każdym razem, gdy robię commit, ale to jest ból.

Rozważałem i odrzuciłem kilka rzeczy. Nie chcę wykluczać tych plików, ponieważ czasami muszę wprowadzić zmiany, które ZOSTANĄ dodane do dcommitted. Poza tym chciałbym, aby te pliki pojawiały się w dowolnych gałęziach lokalnych, które tworzę, tak jak w przypadku plików IDE. Nie mogę jednak wyizolować tych zmian do pojedynczego oddziału, ponieważ będę je chciał w każdym oddziale, tak jak w przypadku plików IDE. Wygląda na to, że coś w rodzaju winy lub stgitu może robić, co chcę, ale to nie jest oczywiste, ponieważ dodają własną warstwę złożoności na gitarze, której wciąż się uczę.

Answer 1

Możesz rozważyć użycie tej skrytki.

git-stash - Stash the changes in a dirty working directory away 

Dla tego, co opisujesz, może to jednak nie być wystarczające.

Answer 2

Jestem trochę nowy, ale polecam używanie oddzielnej głównej i roboczej gałęzi w lokalnym repozytorium git.

Dodaj pliki "non-SVN" tylko do gałęzi roboczej. Zasadniczo wprowadź wszystkie zmiany kodu w gałęzi roboczej. Gdy pliki "non-SVN" się zmienią, dodaj te, używając unikalnego zatwierdzenia, i ustaw prefiks wiadomości zatwierdzenia (np. "Local:" lub "private:"). Gdy jesteś gotowy, aby zobowiązać się do SVN następnie:

1. Pokaż dziennik zobowiązuje się dodać do SVN:

   git co working 
   git cherry master 
   

2. Dodaj wszystkie upstream zobowiązuje się do oddziału głównego, ignorując „prywatny” zobowiązuje. Powtarzaj ten krok, dopóki wszystkie zatwierdzenia upstream nie będą w trybie master.

   git co master 
   git cherry-pick <SHA1> 
   

3. push zobowiązuje się do SVN repo:

   git svn rebase 
   git svn dcommit 
   

Answer 3

Zrobiłem rozeznanie i podszedł z możliwością, że może to zrobić: 2 repozytoria git wskazując w tym samym katalogu. Zmienna środowiskowa GIT_DIR przechowuje nazwę katalogu lokalnego repozytorium. Jeśli nie jest ustawiony, git domyślnie przyjmuje .git, ale może to być cokolwiek.

Co mogę zrobić, to mieć jedno repozytorium w .git, które mapuje do mojego repozytorium Subversion. To powszechny przypadek. Wtedy mógłbym mieć inne repozytorium w .localgit. Każde repozytorium musiałoby być skonfigurowane tak, aby ignorowało pliki zarządzane przez drugie. To proste dzięki! do negowania wzorców.

Po dokonaniu zmiany w plikach lokalnych, które chcę sprawdzić, albo zmienię moją zmienną środowiskową GIT_DIR, albo użyję argumentu --git-dir. Jeśli mam moje wykluczenia/ignoruje skonfigurowane poprawnie, nie będę musiał się martwić o kolizje. Jest oczywiście trochę narzutów, aby zachować to na czasie, ale mogę napisać skrypt otoki, który dodaje plik do wykluczenia jednego repo, gdy plik zostanie dodany do drugiego. Ponadto, narzut ma miejsce tylko raz na plik, a nie na każdym zatwierdzeniu, jak w przypadku sugestii wielu gałęzi.

Gdybym chciał, aby było prostsze, mógłbym użyć konwencji nazewnictwa, ale mogę to zrobić również dla każdego pliku, ponieważ liczba plików lokalnych jest prawie pewna, że ​​są w jednej cyfrze (inaczej m robi coś nie tak).

Jedną wadą, którą widzę przy takim podejściu jest to, że nie będę w stanie rozgałęziać i ukrywać oraz resetować plików lokalnych tylko w taki sam sposób jak pliki w repozytorium SVN. Moje modyfikacje prawdopodobnie będą asynchroniczne w odniesieniu do moich głównych edycji, więc nie sądzę, aby był to poważny problem w praktyce. Mógłbym również napisać wrappery dla tych funkcji, które były świadome wielu repozytoriów. Ponadto będę musiał bardziej jawnie zarządzać plikami lokalnymi, ale prawie każda sytuacja musiałaby sobie z tym poradzić, gdyby nie wiele repozytoriów wbudowanych w git.

Answer 4

Moje obecne rozwiązanie tego problemu polega na użyciu skumulowanego git (stg) i utrzymania tych lokalnych zmian jako oddzielnych poprawek. Kiedy muszę dcommit do Subversion, robię

stg pop # naming the patches that should not be commited 
stg commit # the rest of the patches to commit 
git svn dcommit 
stg push # naming the patches that are used locally 

Zaletą utrzymanie ich jako oddzielnych plastrów jest to, że mogę łatwo mieć łatki, które modyfikują moich testów jednostkowych do testowania różnych bazami danych. Tak normalnie przetestować przeciwko Oracle, ale jeśli chcę sprawdzić przeciwko Derby, robię

stg push local-mods-derby 
ant tests 
stg pop 

lub jeśli chcę przetestować przeciwko PostgreSQL, biegnę

stg push local-mods-test-postgresql 
ant tests 
stg pop 

Tutaj „local-mods- derby "i" local-mods-test-postgresql "to nazwy łatek.

Utrzymywanie oddzielnych łatek pracy jest bardzo proste dzięki stg.

Answer 5

Czy uważasz, że nie pracujesz w oddziale głównym?

Jeśli zachowasz swoje zmiany w lokalnym oddziale git, możesz okresowo scalać lub wybierać tylko żądane zmiany w gałęzi śledzenia svn. Przejdź do gałęzi śledzenia, uruchom polecenie dcommit. Następnie wróć do lokalnego oddziału i przekaż go ponownie.

Jeśli chcesz zmiany w wielu oddziałach, należy je wszystkie oprzeć z tego samego punktu rozgałęzienia. Zachowaj tę gałąź jako wzorcową + zmieniaj poprzez zmianę bazy. Następnie dla wszystkich innych gałęzi, po prostu odeprzyj gałąź podstawową.