Zdalna gałąź z git-svn jest prawie taka sama jak zwykły pilot Git. Więc w swoim lokalnym repozytorium możesz mieć swój klon git-svn i wypychać zmiany do GitHub. Gita to nie obchodzi. Jeśli utworzysz swój klon git-svn i wyślesz dokładnie te same zmiany do GitHub, będziesz mieć nieoficjalną kopię lustrzaną repozytorium Google Code. Reszta to waniliowy Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com:example/example.git
git push origin master
Teraz, gdy już to masz, od czasu do czasu będziesz musiał zsynchronizować repozytorium Subversion z Git. Będzie wyglądać mniej więcej tak:
git svn rebase
git push
W gitk czy czymkolwiek, wyglądałoby to mniej więcej tak:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
A kiedy biegniesz git svn rebase, miałbyś to:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Więc teraz uruchomienie git pushspowoduje wypchnięcie tych zatwierdzeń do GitHub, gałęzi [remotes / origin / master] tam. Wrócisz do scenariusza z pierwszego diagramu graficznego ASCII.
Problem w tym, jak wprowadzasz zmiany w miksie? Chodzi o to, że nigdy nie angażujesz się w tej samej gałęzi, w której korzystasz z git-svn-rebase-ing i git-pushing. Potrzebujesz osobnej gałęzi do wprowadzania zmian. W przeciwnym razie skończyłbyś na ponownym bazowaniu swoich zmian na tych z Subversion, co mogłoby zdenerwować każdego, kto sklonuje twoje repozytorium Git. Chodź za mną? OK, więc tworzysz gałąź, nazwijmy to „funkcjami”. Dokonujesz zatwierdzenia i wypychasz go do 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 gałąź funkcji kilka zatwierdzeń przed gałęzią Google Code, prawda? Więc co się dzieje, gdy chcesz włączyć nowe elementy z Google Code? Biegniesz git svn rebasepierwszy i dostaniesz to:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
Jeśli git pushopanujesz, możesz sobie wyobrazić, że [piloty / źródło / mistrz] znajduje się w tym samym punkcie co mistrz. Ale twoja gałąź funkcji nie ma zmian. Masz teraz do wyboru scalanie elementów głównych z funkcjami lub przebudowywanie funkcji. Scalanie wyglądałoby tak
git checkout features
git merge master
o [features]
/|
/ o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Następnie wysyłasz funkcje do GitHub. Zostawiłem piloty dla mastera, 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 pchnięcie nie byłoby szybkim łączeniem do przodu (wyciągnąłbyś gałąź funkcji spod kogoś, kto ją sklonował). Robienie tego nie jest uważane za w porządku, ale nikt nie może cię powstrzymać, jeśli jesteś zdeterminowany. Ułatwia to również pewne rzeczy, na przykład gdy łatki są akceptowane przez nadawcę w nieco zmienionej formie. Oszczędziłoby to kłopotów z konfliktami, możesz po prostu zmienić bazę - pomiń zainstalowane poprawki. W każdym razie rebase wyglądałby tak:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
A potem musiałbyś to zrobić git push --force. Możesz zobaczyć, dlaczego musisz to wymusić, historia ma wielką starą schizmę od [pilotów / pochodzenie / cechy] do nowej, obecnej po rebase [cechy] .
To wszystko działa, ale wymaga dużo wysiłku. Jeśli masz zamiar być stałym współpracownikiem, najlepiej byłoby popracować w ten sposób przez jakiś czas, wysłać kilka poprawek do systemu i sprawdzić, czy możesz uzyskać dostęp do Subversion. W przeciwnym razie być może nie wypychaj zmian do GitHub. Trzymaj je lokalnie i mimo wszystko spróbuj uzyskać ich akceptację w górę rzeki.
gitnoob tutaj.) Szybkie pytanie. Zrobiłem to na dużym repozytorium SVN i wyszło ~ 141 megabajtów. Wepchnąłem go na github, a następnie sklonowałem z powrotem i wyszło 130 megabajtów. Pobiegłemgit gcna obu. Co może tłumaczyć tę różnicę?