Zdalna gałąź z git-svn jest prawie taka sama jak zwykły Git remote. Więc w lokalnym repozytorium możesz mieć swój klon git-svn i wypychać zmiany na GitHub. Git ma to gdzieś. Jeśli utworzysz swój klon git-svn i wypchniesz te same zmiany na GitHub, będziesz miał nieoficjalne lustro repozytorium kodu Google. Reszta to waniliowy Git.

git svn clone http://example.googlecode.com/svn -s
git remote add origin [email protected]:example/example.git
git push origin master

Teraz, gdy masz to, od czasu do czasu będziesz musiał zsynchronizować repozytorium Subversion z Gitem. Będzie wygląda jak:

git svn rebase
git push

W gitku czy jakoś tak to by wyglądało mniej więcej tak:

o [master][remotes/trunk][remotes/origin/master]
|
o
|
o

A kiedy biegniesz git svn rebase, będziesz miał to:

o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o

Więc teraz uruchomiony git push wypchnie te commity do Githuba, gałęzi [remotes/origin/master] . I wróciłbyś do scenariusza na pierwszym diagramie sztuki ASCII.

Problem polega na tym, jak pracujesz nad zmianami w miksie? Chodzi o to, że nigdy nie angażujesz się w tę samą gałąź że jesteś git-svn-rebase-ing i GIT-pushing. Potrzebujesz oddzielnej gałęzi dla swoich zmian. W przeciwnym razie zmienisz swoje zmiany na Subversion, co może zdenerwować każdego, kto sklonuje Twoje repozytorium Git. Za mną? OK, więc tworzysz gałąź, nazwijmy ją "features". Tworzysz commit i wypychasz go na GitHub do gałęzi features. Twój gitk wyglądałby mniej więcej tak:

o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o

Tutaj masz swoje funkcje gałąź kilka commitów przed oddział Google Code, tak? Co się dzieje, gdy chcesz włączyć nowe rzeczy z Google Code? Najpierw biegniesz git svn rebase i dostaniesz to:

                           o [features][remotes/origin/features]
[master][remotes/trunk] o  |
                        |  o
                        o /
                        |/
                        o[remotes/origin/master]
                        |
                        o

Jeśli git push opanujesz, możesz sobie wyobrazić, że [piloty/origin/master] jest w tym samym punkcie co master. Ale twoja gałąź funkcji nie ma zmian. Teraz możesz połączyć master Z FUNKCJAMI lub rebase. Połączenie wyglądałoby tak:

git checkout features
git merge master 

            o [features]
           /|
          / o [remotes/origin/features]
[master] o  |
         |  o
         o /
         |/
         o
         |
         o

Następnie wypychasz funkcje na GitHub. Skończyłem. piloty dla master aby zaoszczędzić miejsce, byłyby w tym samym punkcie co [master] .

Podejście rebase jest nieco bardziej złe - musiałbyś naciskać z --force, ponieważ twoje naciśnięcie nie byłoby fast-forward merge (wyciągniesz gałąź funkcji spod kogoś, kto ją sklonował). To nie jest naprawdę uważane za OK, aby to zrobić, ale nikt nie może cię powstrzymać, jeśli jesteś zdeterminowany. Ułatwia to również pewne rzeczy, na przykład, gdy łaty są akceptowane w nieco przerobionej formie. On oszczędź sobie bałaganu z konfliktami, możesz po prostu rebase-pominąć upstreamed patches. W każdym razie rebase byłby taki:

git rebase master features

         o [features]
         |
         o
         |  o [remotes/origin/features]
[master] o  |
         |  o
         o /
         |/
         o
         |
         o

I wtedy musiałbyś git push --force to. Możesz zobaczyć, dlaczego musisz go wymusić, historia ma dużą starą schizmę z [piloty / pochodzenie/funkcje] do nowego obecnego Post-rebase [funkcje] .

To wszystko działa, ale to dużo wysiłku. Jeśli masz zamiar być stałym współpracownikiem, najlepiej będzie pracować w ten sposób przez jakiś czas, wyślij kilka łatek pod prąd i sprawdź, czy możesz uzyskać dostęp do commitów do Subversion. Jeśli tego nie zrobisz, może nie wypychaj swoich zmian na GitHub. Utrzymuj je na miejscu i postaraj się je zaakceptować pod prąd.