Git-svn'deki uzak dal, normal bir Git uzaktan kumandasıyla hemen hemen aynıdır. Böylece yerel deponuzda git-svn klonunuzu alabilir ve değişiklikleri GitHub'a gönderebilirsiniz. Git umursamıyor. Git-svn klonunuzu oluşturur ve aynı değişiklikleri GitHub'a gönderirseniz, Google Code deposunun resmi olmayan bir yansımasına sahip olursunuz. Gerisi vanilya Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com:example/example.git
git push origin master
Artık buna sahip olduğunuza göre, ara sıra Subversion deposunu Git ile senkronize etmeniz gerekecektir. Şunun gibi görünecek:
git svn rebase
git push
Gitk veya her neyse, bu şuna benzer bir şeye benzeyecektir:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
Ve koştuğunda git svn rebase, şuna sahip olacaksın:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Yani şimdi koşmak git push, bu taahhütleri oradaki [uzaktan / kaynak / ana] dalı olan GitHub'a itecektir . Ve ilk ASCII sanat diyagramındaki senaryoya geri dönersiniz.
Şimdi sorun şu ki, değişikliklerinizi karışıma nasıl uygulayacaksınız? Buradaki fikir şu ki, git-svn-rebase-ing ve git-pushing olduğunuzla aynı şubeye asla bağlanmazsınız. Değişiklikleriniz için ayrı bir şubeye ihtiyacınız var. Aksi takdirde, Subversion'ın üzerine değişikliklerinizi yeniden sıralarsınız, bu da Git deponuzu klonlayan herkesi üzebilir. Beni takip et? Tamam, bir dal yaratın, buna "özellikler" diyelim. Ve bir taahhütte bulunup bunu GitHub'a özellikler dalına aktarırsınız. Gitk'iniz şöyle bir şeye benzeyecektir:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Burada özellikler dalınız, Google Code şubesinin önünde birkaç taahhüt var, değil mi? Peki, Google Code'dan yeni şeyler eklemek istediğinizde ne olur? Önce koşarsın git svn rebaseve şunu alırsın:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
Eğer varsa git pushdışarı usta, hayal edebileceğiniz [uzaktan kumanda / köken / ustası] ustası olarak aynı noktada olmak. Ancak özellik dalınızda değişiklikler yok. Şimdi seçimleriniz ana parçayı özelliklerle birleştirmek veya özellikleri yeniden sunmaktır. Bir birleştirme şöyle görünür
git checkout features
git merge master
o [features]
/|
/ o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Ardından özellikleri GitHub'a aktarırsınız. Ustanın yerden tasarruf etmesi için uzaktan kumandaları bıraktım, [usta] ile aynı noktada olacaklardı .
Rebase yaklaşımı biraz daha kötüdür - zorlamanız gerekir, çünkü itmeniz hızlı ileri birleştirme olmayacaktır (özellikler dalını klonlayan birinin altından çekersiniz). Bunu yapmak pek uygun sayılmaz, ancak kararlıysanız kimse sizi durduramaz. Yamaların biraz yeniden işlenmiş biçimde yukarı akışta kabul edilmesi gibi bazı şeyleri de kolaylaştırır. Çatışmalarla uğraşmaktan kurtarır, sadece yeniden taban oluşturabilir, yukarı akışlı yamaları atlayabilirsiniz. Her neyse, geri ödeme şu şekilde olacaktır:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Ve sonra buna ihtiyacınız olacak git push --force. Neden onu zorlamanız gerektiğini anlayabilirsiniz, geçmişte [uzaktan / başlangıç / özellikler] ' den yeni mevcut yeniden ödeme sonrası [özellikler] arasında büyük bir eski ayrılık vardır .
Bunların hepsi işe yarıyor, ancak çok fazla çaba gerektiriyor. Düzenli bir katkıda bulunacaksanız, en iyi bahis bir süre böyle çalışmak, yukarı akışa bazı yamalar göndermek ve Subversion'a commit erişimi olup olmadığını görmek olacaktır. Bunu başaramazsanız, belki de değişikliklerinizi GitHub'a göndermeyin. Onları yerel tutun ve yine de yukarı akışta kabul ettirmeye çalışın.
gitçaylak burada.) Hızlı soru. Bunu büyük bir SVN deposuna karşı yaptım ve ~ 141 megabayta çıktı. Onu github'a ittim ve sonra geri klonladım ve 130 megabayta çıktı. İkisinegit gcde koştum . Farkı ne açıklayabilir?