Git-svn से दूरस्थ शाखा नियमित रूप से Git रिमोट के समान ही है। तो अपने स्थानीय भंडार में आप अपने git-svn क्लोन कर सकते हैं और GitHub के लिए परिवर्तनों को धकेल सकते हैं। गिट परवाह नहीं है। यदि आप अपना git-svn क्लोन बनाते हैं और GitHub में ठीक उसी परिवर्तन को धकेलते हैं, तो आपके पास Google कोड रिपॉजिटरी का एक अनौपचारिक दर्पण होगा। बाकी वेनिला गिट है।
git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com:example/example.git
git push origin master
अब जब आपके पास यह है, तो कभी-कभी आपको गिट के साथ तोड़फोड़ के भंडार को सिंक्रनाइज़ करना होगा। यह कुछ इस तरह दिखेगा:
git svn rebase
git push
Gitk या जो भी हो, यह कुछ इस तरह दिखेगा:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
और जब आप दौड़ेंगे git svn rebase, तो आपके पास यह होगा:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
इसलिए अब दौड़ना git pushउन लोगों को GitHub की ओर धकेलेगा, जो [रिमोट / मूल / मास्टर] हैं शाखा है। और आप पहले ASCII कला आरेख में परिदृश्य पर वापस आ जाएंगे।
अब समस्या यह है कि आप अपने बदलाव को मिक्स में कैसे काम करेंगे? विचार यह है, आप कभी भी उसी शाखा पर प्रतिबद्ध नहीं होते हैं जो आप git-svn-rebase-ing और git-push करते हैं। आपको अपने परिवर्तनों के लिए एक अलग शाखा की आवश्यकता है। अन्यथा, आप अपने बदलावों को तोड़फोड़ करने वालों के ऊपर समाप्त कर देंगे, जो किसी को भी परेशान कर सकते हैं जो आपके गिट रिपॉजिटरी को क्लोन करता है। मेरे पीछे आओ? ठीक है, इसलिए आप एक शाखा बनाते हैं, चलो इसे "सुविधाएँ" कहते हैं। और आप एक प्रतिबद्ध बनाते हैं और इसे GitHub से फीचर शाखा में धकेल देते हैं। आपका gitk कुछ इस तरह दिखेगा:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
यहाँ आपने अपनी सुविधाओं की शाखा को Google कोड शाखा से आगे आने वाले एक-दूसरे को मिलाया है, है ना? तो क्या होता है जब आप Google कोड से नए सामान को शामिल करना चाहते हैं? आप git svn rebaseपहले दौड़ेंगे और इसे प्राप्त करेंगे:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
यदि आप git pushबाहर मास्टर करते हैं, तो आप मास्टर के रूप में एक ही बिंदु पर होने वाले [उपाय / मूल / मास्टर] की कल्पना कर सकते हैं । लेकिन आपकी सुविधा शाखा में परिवर्तन नहीं हैं। आपकी पसंद अब मास्टर को फीचर्स, या रीबेज फीचर्स में मर्ज करना है। एक मर्ज इस तरह दिखेगा
git checkout features
git merge master
o [features]
/|
/ o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
तब आप सुविधाओं को GitHub पर धकेल देते हैं। मैंने अंतरिक्ष को बचाने के लिए मास्टर के लिए छूट छोड़ दी है, वे [मास्टर] के समान बिंदु पर होंगे ।
रिबास दृष्टिकोण थोड़ा अधिक दुष्ट है - आपको धक्का देना होगा - प्रवर्तन के रूप में आपका धक्का एक तेजी से आगे मर्ज नहीं होगा (आप किसी व्यक्ति के नीचे से सुविधा शाखा को खींच लेंगे जिसने इसे क्लोन किया था)। यह वास्तव में ऐसा करने के लिए ठीक नहीं माना जाता है, लेकिन यदि आप दृढ़ हैं तो कोई भी आपको रोक नहीं सकता है। यह कुछ चीजों को आसान भी बनाता है, जैसे कि जब पैच को थोड़ा उल्टा रूप में स्वीकार किया जाता है। यह संघर्ष के साथ खिलवाड़ होने से बचाएगा, आप बस उलट-पुलट कर सकते हैं। वैसे भी, एक छूट इस तरह होगी:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
और फिर आपको वह करना होगा git push --force। आप यह देख सकते हैं कि आपको इसे मजबूर करने की आवश्यकता क्यों है, इतिहास में एक बड़ा पुराना धर्म है [रीमोट / उत्पत्ति / सुविधाएँ] से नए वर्तमान पोस्ट-रिबेस [फीचर्स] ।
यह सब काम करता है, लेकिन यह बहुत प्रयास है। यदि आप एक नियमित योगदानकर्ता बनने जा रहे हैं, तो सबसे अच्छा शर्त यह होगा कि आप थोड़ी देर के लिए इस तरह से काम करें, कुछ पैच अपस्ट्रीम भेजें और देखें कि क्या आप सबवर्सन के लिए प्रतिबद्ध हो सकते हैं। असफल होना, शायद GitHub के लिए आपके परिवर्तनों को बाहर नहीं धकेलता है। उन्हें स्थानीय रखें और कोशिश करें और उन्हें ऊपर की ओर वैसे भी स्वीकार करें।
gitnoob यहाँ।) त्वरित प्रश्न। मैंने एक बड़े एसवीएन रेपो के खिलाफ यह किया और यह ~ 141 मेगाबाइट पर आ गया। मैंने इसे गीथब पर धकेल दिया और फिर इसे वापस नीचे कर दिया, और यह 130 मेगाबाइट पर आ गया। मैंgit gcदोनों पर भागा । अंतर का क्या हिसाब हो सकता है?