Chcę mieć pliki, które śledzę w moim lokalnym gitrepozytorium, które nie jest rejestrowane w centralnym repozytorium svn, gdy uruchamiam git-svn dcommit. Często mam długoterminowe, lokalne zmiany tylko plików śledzonych w repozytorium. Czasami służy do debugowania kodu. Mam też pliki IDE projektu, które chciałbym śledzić. W zwykłym starym svn po prostu umieściłbym te pliki na liście zmian z etykietą „XYZ: NIE ZAREJESTRUJ SIĘ”, a następnie po prostu ręcznie poradziłbym sobie z problemem, kiedy faktycznie mam zmiany, które muszę zatwierdzić.
Idealnie chciałbym sprawdzić moje zmiany w moichgałąź master, ale ustaw coś, co uniemożliwi propagację tych konkretnych zmian do repozytorium svn. Używałbym git i git-svn w konwencjonalny sposób, ale niektóre zmiany nigdy się nie zwiększają. Oczywiście mogę to zrobić ręcznie za każdym razem, gdy dokonuję zatwierdzenia, ale to jest ból.
Rozważyłem i odrzuciłem kilka rzeczy. Nie chcę wykluczać tych plików, ponieważ czasami muszę wprowadzić zmiany, które NIE zostaną zatwierdzone. Chciałbym też, 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 w jednym oddziale, ponieważ będę chciał ich w każdej gałęzi, tak jak w przypadku plików IDE. Wygląda na to, że coś takiego jak wina lub stgit może zrobić, co chcę, ale nie jest to oczywiste, ponieważ dodają własną warstwę złożoności do git, której wciąż się uczę.
Odpowiedzi:
2 dla odpowiedzi № 1Jestem trochę nowy w Git, ale polecam użycie osobnego oddziału głównego i działającego w twoim lokalnym repozytorium git.
Dodaj pliki „inne niż SVN” do działającej gałęzitylko. Zasadniczo dokonuj wszystkich zmian kodu w działającej gałęzi. Kiedy zmieniają się pliki „inne niż SVN”, dodaj je przy użyciu unikalnego zatwierdzenia i ustaw prefiks komunikatu zatwierdzenia (tj. „Local:” lub „private:”). Gdy będziesz gotowy do zatwierdzenia w SVN:
Pokaż dziennik zatwierdzeń do dodania do SVN:
git co working git cherry masterDodaj wszystkie zatwierdzenia poprzedzające do gałęzi master, ignorując zatwierdzenia „prywatne”. Powtarzaj ten krok, aż wszystkie zatwierdzenia nadrzędne będą w master.
git co master git cherry-pick <SHA1>Push zatwierdza do repozytorium SVN:
git svn rebase git svn dcommit
2 dla odpowiedzi nr 2
Moje obecne rozwiązanie tego problemu polega na użyciu skumulowanego git (stg) i utrzymaniu tych lokalnych zmian jako osobnych łatek. Kiedy muszę polecić 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
Fajną rzeczą w utrzymaniu ich jakoOddzielne łaty polegają na tym, że mogę łatwo wprowadzać łaty, które modyfikują moje testy jednostkowe w celu testowania różnych backendów bazy danych. Zwykle testuję przeciwko Oracle, ale jeśli chcę porównać z Derby, robię to
stg push local-mods-derby
ant tests
stg pop
lub jeśli chcę przetestować na PostgreSQL, uruchamiam
stg push local-mods-test-postgresql
ant tests
stg pop
Tutaj „local-mods-derby” i „local-mods-test-postgresql” to nazwy łatek.
Tak więc utrzymanie oddzielnych łatek pracy jest bardzo łatwe dzięki stg.
1 dla odpowiedzi nr 3
Czy zastanawiałeś się, czy nie pracować w oddziale głównym?
Jeśli zachowasz zmiany w lokalnym oddziale gitmożesz okresowo scalać lub wybierać tylko pożądane zmiany w gałęzi śledzenia svn. Przełącz się na gałąź śledzenia, uruchom dcommit. Następnie wróć do lokalnego oddziału i dokonaj zmiany podstawy.
Jeśli chcesz zmiany w wielu gałęziach,oprzyj je wszystkie na tym samym punkcie rozgałęzienia. Zachowaj tę gałąź jako zmiany główne + poprzez zmianę bazy. Następnie dla wszystkich innych gałęzi, po prostu wypuść bazową gałąź.
0 dla odpowiedzi nr 4
Możesz rozważyć użycie do tego skrytki.
git-stash - Stash the changes in a dirty working directory away
Może być jednak niewystarczający w stosunku do tego, co opisujesz.
0 dla odpowiedzi № 5
Zrobiłem kilka badań i wymyśliłem ataka możliwość: 2 repozytoria git wskazujące na ten sam katalog. Zmienna środowiskowa GIT_DIR przechowuje nazwę lokalnego katalogu repozytorium. Jeśli nie jest ustawiony, git przyjmuje domyślnie .git, ale może to być wszystko.
To, co mógłbym wtedy zrobić, to mieć jedno repozytorium w.git, który mapuje do mojego repozytorium Subversion. To typowy 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 z! do zaprzeczania wzorcom.
Kiedy zmieniam pliki tylko lokalne,chcesz się zarejestrować, zmieniam zmienną środowiskową GIT_DIR lub używam argumentu wiersza poleceń --git-dir. Jeśli mam prawidłowo skonfigurowane wykluczenia / ignorowania, nie będę musiał martwić się o kolizje. Oczywiście jest trochę narzutów, aby aktualizować te informacje, ale mogę napisać skrypt opakowujący, który dodaje plik do wykluczenia jednego repozytorium, gdy plik jest dodawany do drugiego. Ponadto ten narzut występuje tylko raz na plik, a nie przy każdym zatwierdzeniu, jak w przypadku sugestii wielu gałęzi.
Gdybym chciał to uprościć, mógłbym użyćkonwencji nazewnictwa, ale mogę to również zrobić z każdym pojedynczym plikiem, ponieważ liczba plików tylko lokalnych jest prawie na pewno jednocyfrowa (w przeciwnym razie zrobię coś źle).
Jedyną wadą tego podejścia jestże nie byłbym w stanie rozgałęziać, przechowywać i resetować plików tylko lokalnych w taki sam sposób, jak pliki w repozytorium SVN. Moje modyfikacje prawdopodobnie będą asynchroniczne w stosunku do moich głównych zmian, więc nie robię tego ” Myślę, że w praktyce byłby to poważny problem. Mógłbym również napisać otoki dla tych funkcji, które były świadome wielu repozytoriów. Ponadto będę musiał być bardziej precyzyjny podczas zarządzania plikami tylko lokalnymi, ale prawie każda sytuacja musiałaby sobie z tym poradzić, z wyjątkiem wielu repozytoriów wbudowanych w sam git.