Cabang remote dari git-svn hampir sama dengan remote Git biasa. Jadi di repositori lokal Anda, Anda dapat memiliki klon git-svn dan mendorong perubahan ke GitHub. Git tidak peduli. Jika Anda membuat git-svn clone dan mendorong perubahan yang sama persis ke GitHub, Anda akan memiliki mirror tidak resmi dari repositori Google Code. Sisanya adalah vanilla Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com:example/example.git
git push origin master
Sekarang Anda sudah memiliki ini, kadang-kadang Anda harus menyinkronkan repositori Subversion dengan Git. Ini akan terlihat seperti:
git svn rebase
git push
Di gitk atau apa pun, ini akan terlihat seperti ini:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
Dan ketika Anda berlari git svn rebase
, Anda akan memiliki ini:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Jadi sekarang menjalankan git push
akan mendorong komit ke GitHub, cabang [remote / asal / master] di sana. Dan Anda akan kembali ke skenario di diagram seni ASCII pertama.
Masalahnya sekarang adalah, bagaimana Anda mengerjakan perubahan Anda ke dalam campuran? Idenya adalah, Anda tidak pernah berkomitmen ke cabang yang sama dengan git-svn-rebase-ing dan git-push. Anda memerlukan cabang terpisah untuk perubahan Anda. Jika tidak, Anda akan berakhir dengan mem-rebound perubahan Anda di atas yang Subversion, yang dapat mengganggu siapa saja yang mengkloning repositori Git Anda. Ikuti aku? OK, jadi Anda membuat cabang, sebut saja "fitur". Dan Anda membuat komit dan mendorongnya ke GitHub ke cabang fitur. Gitk Anda akan terlihat seperti ini:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Di sini Anda punya fitur Anda bercabang beberapa komitmen di depan cabang Google Code, kan? Jadi apa yang terjadi ketika Anda ingin memasukkan hal-hal baru dari Google Code? Anda sudah lari git svn rebase
dulu dan dapatkan ini:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
Jika Anda git push
menguasai, Anda bisa membayangkan [remote / asal / master] berada pada titik yang sama dengan master. Tetapi cabang fitur Anda tidak memiliki perubahan. Pilihan Anda sekarang adalah menggabungkan master menjadi fitur, atau rebase fitur. Gabungan akan terlihat seperti ini
git checkout features
git merge master
o [features]
/|
/ o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Kemudian Anda mendorong fitur ke GitHub. Saya telah meninggalkan remote untuk master untuk menghemat ruang, mereka akan berada pada titik yang sama dengan [master] .
Pendekatan rebase sedikit lebih jahat - Anda harus mendorong dengan - memaksa karena dorongan Anda tidak akan menjadi penggabungan maju cepat (Anda akan menarik cabang fitur dari bawah seseorang yang telah mengkloningnya). Ini tidak benar-benar dianggap OK untuk melakukan ini, tetapi tidak ada yang bisa menghentikan Anda jika Anda bertekad. Itu memang membuat beberapa hal lebih mudah juga, seperti ketika tambalan diterima di hulu dalam bentuk yang sedikit dikerjakan ulang. Ini akan menghemat karena harus dipusingkan dengan konflik, Anda hanya dapat rebase - lewati patch yang di-upstream. Bagaimanapun, rebase akan seperti ini:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Dan kemudian Anda harus melakukannya git push --force
. Anda dapat melihat mengapa Anda harus memaksanya, sejarah memiliki perpecahan lama yang besar dari [remote / asal / fitur] ke [fitur] post-rebase baru saat ini .
Ini semua bekerja, tetapi banyak usaha. Jika Anda akan menjadi kontributor tetap, taruhan terbaik adalah bekerja seperti ini untuk sementara waktu, mengirim beberapa tambalan ke hulu dan melihat apakah Anda bisa mendapatkan akses komit ke Subversion. Jika gagal, mungkin jangan mendorong perubahan Anda ke GitHub. Buat mereka tetap lokal dan coba agar mereka diterima di hulu
git
noob di sini.) Pertanyaan cepat. Saya melakukan ini terhadap repo SVN besar dan hasilnya ~ 141 megabita. Saya mendorongnya ke github dan kemudian mengkloningnya kembali, dan hasilnya mencapai 130 megabita. Saya berlarigit gc
pada keduanya. Apa yang bisa menjelaskan perbedaannya?