Die Remote-Zweigstelle von Git-Svn ist ziemlich genau die gleiche wie eine normale Git Remote. In Ihrem lokalen Repository können Sie also Ihren git-svn-Klon erstellen und Änderungen an GitHub vornehmen. Git ist es egal. Wenn Sie Ihren git-svn-Klon erstellen und die gleichen Änderungen an GitHub weitergeben, verfügen Sie über eine inoffizielle Spiegelung des Google Code-Repositorys. Der Rest ist Vanille Git.
Nun, da Sie dies haben, müssen Sie gelegentlich das Subversion-Repository mit Git synchronisieren Es wird in etwa so aussehen:
git svn rebase
git push
In gitk oder was auch immer, würde dies wie folgt aussehen:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
Und wenn Sie git svn rebase laufen, würden Sie diese:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
So jetzt läuft git push würde diese Commits auf GitHub, die [Fernbedienungen/Ursprung/Master] Niederlassung dort drücken. Und Sie würden zu dem Szenario im ersten ASCII-Kunstdiagramm zurückkehren.
Das Problem ist jetzt, wie arbeiten Sie Ihre Änderungen in den Mix? Die Idee ist, dass Sie sich nie auf den gleichen Zweig festlegen, den Sie git-svn-rebasing und git-pushing sind. Sie benötigen einen eigenen Zweig für Ihre Änderungen. Andernfalls würden Sie Ihre Änderungen am Anfang der Subversion-Dateien, die jeden verärgern könnten, der Ihr Git-Repository klont. Folge mir? OK, also erstellen Sie einen Zweig, nennen wir es "Features". Und du machst ein Commit und schiebst es zu GitHub zum Feature-Zweig. Ihre gitk würde wie folgt aussehen:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Hier haben Sie Ihre Eigenschaften Zweig bekam ein paar begeht vor dem Google Code Zweig, nicht wahr? Was passiert also, wenn Sie neue Inhalte aus Google Code integrieren möchten? Sie würden laufen git svn rebase erste und diese:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o/
|/
o[remotes/origin/master]
|
o
Wenn Sie git push Master aus, können Sie die [Fernbedienungen/origin/master] an der gleichen Stelle wie Herr zu sein vorstellen. Aber Ihr Feature-Zweig hat die Änderungen nicht. Ihre Auswahl besteht nun darin, den Master in Features oder Rebase-Features zu integrieren.Eine Zusammenführung würde so aussehen:
git checkout features
git merge master
o [features]
/|
/o [remotes/origin/features]
[master] o |
| o
o/
|/
o
|
o
Dann drücken Sie Features auf GitHub. Ich habe die Fernbedienungen für Master weggelassen, um Platz zu sparen, sie wären am selben Punkt wie [Master].
Der Rebase-Ansatz ist etwas böser - Sie müssten mit --force pushen, da es sich bei Ihrem Push nicht um eine Schnellvorlauf-Zusammenführung handelt (Sie würden den Feature-Zweig unter jemandem herausziehen, der ihn geklont hat). Es ist nicht wirklich in Ordnung, dies zu tun, aber niemand kann Sie aufhalten, wenn Sie entschlossen sind. Es erleichtert auch einige Dinge, etwa wenn Patches in leicht überarbeiteter Form upstream akzeptiert werden. Es würde sparen, sich mit Konflikten herumärgern zu müssen, Sie können einfach umbuchen - die Upstream-Patches überspringen. Wie dem auch sei, wäre ein rebase so aussehen:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o/
|/
o
|
o
Und dann würden Sie git push --force diesem haben. Sie können sehen, warum Sie es erzwingen müssen, die Geschichte hat eine große alte Spaltung von der [Fernbedienungen/Ursprung/Eigenschaften] zu der neuen aktuellen Post-Rebase [Eigenschaften].
Das alles funktioniert, aber es ist eine Menge Mühe. Wenn Sie regelmäßig Beiträge schreiben, sollten Sie am besten so vorgehen, einige Patches upstream senden und prüfen, ob Sie Commit-Zugriff auf Subversion erhalten. Gelingt dies nicht, schieben Sie Ihre Änderungen vielleicht nicht auf GitHub. Halten Sie sie lokal und versuchen Sie, sie trotzdem stromaufwärts zu akzeptieren.
Danke für die hervorragende Anleitung. ('git' noob hier.) Schnelle Frage. Ich habe dies gegen einen großen SVN Repo getan und es kam zu ~ 141 Megabyte. Ich schob es auf GitHub und klonte es dann wieder runter, und es kam auf 130 Megabyte heraus. Ich habe 'git gc' auf beiden gespielt. Was könnte für den Unterschied verantwortlich sein? – mpontillo
... herausgefunden. Ich brauchte 'git push Herkunft - Spiegel '. – mpontillo
Arbeitete wie ein Charme, jetzt muss ich nur den ursprünglichen googlecode devs sagen, um github mit mir zu verwenden: D – electblake