2017-02-12 6 views
5

मैं एक छोटी फर्मवेयर टीम का सदस्य हूं और हम संस्करण नियंत्रण के लिए एक निजी गिट सर्वर का उपयोग करते हैं। हमारे कोडबेस में आम तौर पर प्लेटफ़ॉर्म विशिष्ट कोड, एकाधिक प्लेटफ़ॉर्म द्वारा उपयोग किए जाने वाले सामान्य कोड और माइक्रोप्रोसेसर के निर्माता द्वारा प्रदान किए गए एक एसडीके के लिए फ़ोल्डर्स होते हैं।गिट subrepositories

वर्तमान में हमारे भंडार सामान्य कोड के आसपास केंद्रित हैं; प्रत्येक प्लेटफ़ॉर्म में भंडार में एक फ़ोल्डर होता है। इसमें कम से कम दो गंभीर परिणाम हैं;

  1. जब हम एक मंच के लिए परिवर्तन धक्का यह सब अन्य प्लेटफार्मों जो हिस्सा एक ही आम कोड के लिए दिखाई दे। यह कई प्लेटफार्मों के लिए रिलीज के साथ प्रतिबद्ध इतिहास को अव्यवस्थित करता है और अतीत में इस बात के बारे में भ्रम पैदा हुआ है कि हम किस प्लेटफ़ॉर्म के लिए परिवर्तनों की समीक्षा कर रहे हैं।

  2. भंडारण में सभी प्लेटफ़ॉर्म के लिए सामान्य कोड में परिवर्तनों को सत्यापित करने से पहले सत्यापित किया जाना चाहिए, जिससे अनावश्यक दर्द होता है।

मैं प्रत्येक के लिए भंडार है करने के लिए जोर दे रहा हूँ (किसी ने इस कल नहीं किया और परिवर्तन है कि हमारे पुराने प्लेटफार्मों की एक जोड़ी की वजह से निर्माण करने के लिए विफल बना दिया। यह विशेष रूप से भंडार में 5 प्लेटफार्मों है) प्लेटफ़ॉर्म ताकि हम सामान्य कोड में परिवर्तन कर सकें और एसडीके को समय-समय पर अपग्रेड किए बिना प्लेटफार्मों के सभी को अपडेट और सत्यापित करने के लिए मजबूर किए जा सकें। चूंकि हम पांच व्यक्ति टीम हैं और ये समस्याएं आम तौर पर एक रिलीज तक पहुंचने वाले क्रंच-टाइम के दौरान पीछे आती हैं, इससे हमें अनावश्यक मस्तिष्क क्षति और समय का एक टन बचाएगा। स्वाभाविक रूप से कठिन हिस्सा कार्यान्वयन में है।

अभी मैं एक ऐसी प्रणाली की कल्पना कर रहा हूं जहां प्रत्येक प्लेटफार्म का अपना भंडार होता है, प्रत्येक सामान्य कोड बेस का अपना भंडार होता है और हमारे द्वारा उपयोग किए जाने वाले प्रत्येक एसडीके में अपना स्वयं का भंडार होता है। प्लेटफॉर्म रिपॉजिटरीज सामान्य कोड और एसडीके को संदर्भित या अन्यथा संदर्भित करेंगे जो वे "उप-भंडार" के रूप में उपयोग करते हैं।

मैंने सबमिड्यूल के बारे में पढ़ा है लेकिन मुझे लगता है कि वे ठीक होने से अधिक मुद्दों का कारण बनेंगे; हाल ही में हमें तीन साल के फर्मवेयर को डीबग करना पड़ा, जिसके लिए स्थिर विश्लेषण करने के लिए जारी होने वाली समस्या के लिए हमारे स्थानीय कोडेबेस को रीसेट करना आवश्यक था। जैसा कि मैं समझता हूं कि सबमिशन के स्थानीय संस्करण को उस भंडार से अलग किया गया है जिसमें यह रहता है, जिसका मतलब है कि भंडार को पुरानी प्रतिबद्धता में रीसेट करना बाकी के भंडार के संबंध में "भविष्य" में सबमिशन छोड़ देगा। पुराने कोड डीबग करने के संदर्भ में यह व्यवहार 100% अस्वीकार्य है।

यहां मैं जो हासिल करना चाहता हूं उसकी एक बुलेट सूची है; (महत्व के क्रम में)

  1. तोड़ मंच विशिष्ट कोड आम कोड से दूर इतना आम कोड और/या एसडीके में परिवर्तन दूसरे प्लेटफार्म पर अप्रत्याशित परिणाम नहीं है।

  2. प्रत्येक प्लेटफार्म, प्रत्येक सामान्य कोड बेस और प्रत्येक एसडीके के लिए नए भंडार बनाएं।

  3. स्थानीय मशीन पर रिमोट रिपोजिटरी क्लोन करना एक चरण की प्रक्रिया होनी चाहिए; मंच बनाने से पहले नए उपयोगकर्ताओं को प्रत्येक सब-रिपोजिटरी खींचने के लिए मजबूर नहीं किया जाना चाहिए।

    • इसके अतिरिक्त; पुराने कोड को बहाल करना, जिसमें सामान्य कोड और एसडीके शामिल है जिसका उपयोग किसी भी दिए गए प्लेटफ़ॉर्म के संस्करण XXX-YYY को बनाने के लिए किया गया था, संभव होना चाहिए।

    • संपादित करें: पिछली बार मैं कोड "बहाल" करने के लिए मैं एक वर्ष एक निर्माण करने के लिए का निर्माण मैं डिबगिंग था और एक नरम रीसेट करने के लिए हार्ड रीसेट इस्तेमाल किया यह अधिक पुराने है कि मुझे पता था कि अच्छा था, लेकिन केवल था तो मेरे वाक्यविन्यास हाइलाइटर में गिट प्लगइन मेरे लिए ज्ञात-ज्ञात और ज्ञात-बुरे के बीच परिवर्तन प्रदर्शित करेगा।

      संयोग से इस विशेष मंच अखंड है और इस सवाल यह पर लागू नहीं होता है, लेकिन तर्क की खातिर हम कहूँगा यह लागू होता है।

  4. आम कोड संशोधित प्लेटफार्मों को प्रभावित नहीं करना चाहिए जब तक मंच के मेंटेनर नई सामान्य कोड में खींचती है। (मेरा मानना ​​है कि यह सामान्य कोड के मास्टर के बजाय सामान्य कोड के टैग किए गए कामों में से एक जोड़कर सबट्री के साथ संभव है)

  5. केवल पढ़ने-योग्य उप-संग्रह एक स्वीकार्य सीमा है। (यानी उप-भंडार या तो प्लेटफ़ॉर्म के भंडार में संशोधित नहीं किया जा सकता है या उप-भंडार में परिवर्तन प्लेटफ़ॉर्म के भंडार से नहीं धकेल दिया जा सकता है)

  6. स्मार्टगिट/एचजी समर्थन सभी के रूप में वांछनीय है लेकिन हमारे सदस्यों में से एक इसका उपयोग करता है।

  7. स्क्रिप्टिंग एक बार कार्य स्वीकार्य है, लेकिन मैं स्क्रिप्ट है कि इसके लिए Git के काम करने के साथ प्लेटफार्मों अपवित्र नहीं करना चाहती।

मैं भी उपतरू के बारे में पढ़ा है, लेकिन इस समय मैं क्या वे सहज व्यवहार मैं इच्छा की अनुमति होगी की अनिश्चित हूँ। मेरा मुख्य प्रश्न यह है: क्या गिट इस तरह की कार्यक्षमता का समर्थन करता है? यदि हां, क्या यह कार्यक्षमता subtrees या किसी अन्य विधि द्वारा कार्यान्वित की गई है, मुझे अभी तक पता नहीं है?

उत्तर

1

मुझे लगता है कि वे और अधिक मुद्दों की तुलना में वे ठीक हैं कारण होगा; हाल ही में हमें तीन साल के फर्मवेयर को डीबग करना पड़ा, जिसके लिए स्थिर विश्लेषण करने के लिए जारी होने वाली समस्या के लिए हमारे स्थानीय कोडेबेस को रीसेट करना आवश्यक था। जैसा कि मैं समझता हूं कि सबमिशन के स्थानीय संस्करण को उस भंडार से अलग किया गया है जिसमें यह रहता है, जिसका मतलब है कि भंडार को पुरानी प्रतिबद्धता में रीसेट करना बाकी के भंडार के संबंध में "भविष्य" में सबमिशन छोड़ देगा।

बिलकुल नहीं।
Submoduleबिल्कुल आपको जो चाहिए वह है।

और आप एक अतीत को एक माता पिता रेपो रीसेट करने की आवश्यकता चाहिए प्रतिबद्ध है, यह भी submodule रूट फ़ोल्डर रीसेट हो जाएंगे, एक gitlink बुलाया सटीक सही SHA1 करने के लिए (एक समय में recoreded)। वह what a gitlink is for है।

एक clone --recursive एक माता पिता रेपो और एक आदेश में अपने submodule क्लोन होगा।

आवश्यक होने पर आप configure a submodule to follow the latest commits of a branch कर सकते हैं।

और आप अपने माता-पिता रेपो both said parent repo and its submodules, again in one command से धक्का कर सकते हैं।

+0

नहीं धन्यवाद; सबमिशन दस्तावेज को फिर से पढ़ने के बाद भी मुझे लगता है कि सबमिशन पैराडाइम कुछ गंभीर परेशानी को आमंत्रित करता है। उदाहरण के लिए; गिट के दस्तावेज़ीकरण के अनुसार 'गिट सबमिशन अपडेट' रिमोट रिपोजिटरी से सबसे अद्यतित प्रतिबद्धता प्राप्त करेगा लेकिन सबमिशन के सिर को अलग करेगा। क्या होगा यदि किसी ने परिवर्तन किया और सोचा कि उन्होंने उन्हें धक्का दिया, और फिर एक अलग सिर के साथ एक रिहाई किया? बाधाएं हैं कि वे कोड पर अपना काम खो देंगे जो इसे कभी भी भंडार में नहीं बनायेगा। – JacaByte

+1

"गिट सबमिशन अपडेट रिमोट रिपोजिटरी से सबसे अद्यतित प्रतिबद्धता प्राप्त करेगा": नहीं, यह नहीं होगा। तब तक जब तक आप स्पष्ट रूप से कॉन्फ़िगर नहीं करते हैं, ऐसा करने के लिए सबमिशन कहा जाता है। पुश के लिए इसे http://stackoverflow.com/questions/5814319/git-submodule-push/10878273#10878273 के साथ ख्याल रखा जाता है। फिर, सबमिशन समाधान है। Subtree पुराने तंत्र है जो submodules से पहले अस्तित्व में था। – VonC

+0

यह subrepositories के सिर को अलग करने के बारे में मेरी चिंता का समाधान नहीं करता है। – JacaByte

1

मैं केवल यहां चिंतन कर रहा हूं क्योंकि मुझे लगता है कि @ वोनसी का जवाब पूरी तरह से समझा नहीं जाता है कि पता @ जैकाबीट की चिंताओं को क्यों डूबता है।

मुझे लगता है कि वे ठीक होने से अधिक मुद्दों का कारण बनेंगे; हाल ही में हमें तीन साल के फर्मवेयर को डीबग करना पड़ा, जिसके लिए स्थिर विश्लेषण करने के लिए जारी होने वाली समस्या के लिए हमारे स्थानीय कोडेबेस को रीसेट करना आवश्यक था। जैसा कि मैं समझता हूं कि सबमिशन के स्थानीय संस्करण को उस भंडार से अलग किया गया है जिसमें यह रहता है, जिसका मतलब है कि भंडार को पुरानी प्रतिबद्धता में रीसेट करना बाकी के भंडार के संबंध में "भविष्य" में सबमिशन छोड़ देगा।

यह पूरी तरह से गलत नहीं है। हालांकि, यह कहना गलत है कि submodules आपको अपने कोडबेस का पुराना संस्करण देखने की अनुमति नहीं देते हैं। यह भ्रम इस तथ्य से उत्पन्न होता है कि git checkout प्रसंस्करण कार्यरत पेड़ों को अपडेट नहीं करता है, बल्कि आपको वह नौकरी छोड़ देता है (git submodule update --init --recursive यह आपके लिए करेगा)।

सबमोड्यूल रिपोजिटरी निर्भरताओं को नियंत्रित करने के लिए शानदार उपकरण हैं। वास्तव में, वे विशेष रूप से क्या आप उन्हें करना चाहते हैं: निर्भरता की एक विशिष्ट संस्करण साथ अपने कोड की एक विशिष्ट संस्करण संबद्ध करते हैं। विशेष रूप से, एक "सबमिशन" वास्तव में केवल एक टेक्स्ट फ़ाइल है जिसमें SHA-1 हैश है जो सबमिशन रेपो पर एक प्रतिबद्धता के अनुरूप है (.gitmodules में सबमिशन रिमोट के बारे में गिट स्टोर्स मेटाफॉर्मेशन, यह है कि यह कैसे जानता है कि सबमिशन की एक प्रति कहां प्राप्त करें से रेपो)।

हालांकि, submodules के साथ काम करना, कांटेदार हो सकता है। इसके लिए आपको गिट मॉडल की अच्छी समझ होनी चाहिए (& काम करने वाले पेड़/स्टेजिंग/रेपो) और सबमिशन सिस्टम की समझ स्वयं ही होती है। लेकिन अगर आप सुनिश्चित करते हैं कि लोग जानते हैं कि वे क्या कर रहे हैं (और यह बहुत बड़ा है), तो आप अपने पैर में खुद को शूटिंग से बच सकते हैं।


तुम बहुत विशेष रूप से अपने codebase के एक पुराने संस्करण को रोलबैक करने की क्षमता के बारे में चिंतित होने लगते हैं, और @ VonC के जवाब अपनी चिंताओं allayed गए हैं लगता नहीं है, इसलिए मैं एक पूर्वाभ्यास कैसे की यहाँ प्रदान करेंगे ऐसा करने के लिए:

मैं अपने personal .dotfiles repo एक उदाहरण के रूप इस्तेमाल करेंगे (मैं submodules के रूप में विम एक्सटेंशन में खींच; इस लेखन के समय में, HEADd9c0a797ad45a0d2fd92a07d3c3802528ed7b82a है):

$ git clone https://github.com/sxlijin/.dotfiles dotfiles 
Cloning into 'dotfiles'... 
remote: Counting objects: 350, done. 
remote: Compressing objects: 100% (31/31), done. 
remote: Total 350 (delta 12), reused 0 (delta 0), pack-reused 318 
Receiving objects: 100% (350/350), 86.61 KiB | 0 bytes/s, done. 
Resolving deltas: 100% (176/176), done. 
$ cd dotfiles/ 
$ git submodule update --init --recursive 
Submodule 'bundle/jedi-vim' (http://github.com/davidhalter/jedi-vim) registered for path 'vim/bundle/jedi-vim' 
Submodule 'bundle/nerdtree' (https://github.com/scrooloose/nerdtree.git) registered for path 'vim/bundle/nerdtree' 
Submodule 'bundle/supertab' (https://github.com/ervandew/supertab.git) registered for path 'vim/bundle/supertab' 
Submodule 'vim/bundle/vim-flake8' (https://github.com/nvie/vim-flake8.git) registered for path 'vim/bundle/vim-flake8' 
Submodule 'bundle/vim-pathogen' (https://github.com/tpope/vim-pathogen.git) registered for path 'vim/bundle/vim-pathogen' 
Cloning into '/home/pockets/dotfiles/vim/bundle/jedi-vim'... 
warning: redirecting to https://github.com/davidhalter/jedi-vim/ 
Cloning into '/home/pockets/dotfiles/vim/bundle/nerdtree'... 
Cloning into '/home/pockets/dotfiles/vim/bundle/supertab'... 
Cloning into '/home/pockets/dotfiles/vim/bundle/vim-flake8'... 
Cloning into '/home/pockets/dotfiles/vim/bundle/vim-pathogen'... 
Submodule path 'vim/bundle/jedi-vim': checked out '8cf616b0887276e026aefdf68bc0311b83eec381' 
Submodule 'jedi' (https://github.com/davidhalter/jedi.git) registered for path 'vim/bundle/jedi-vim/jedi' 
Cloning into '/home/pockets/dotfiles/vim/bundle/jedi-vim/jedi'... 
Submodule path 'vim/bundle/jedi-vim/jedi': checked out 'f05c0714c701ab784bd344aa063acd216fb45ec0' 
Submodule path 'vim/bundle/nerdtree': checked out '281701021c5001332a862da80175bf585d24e2e8' 
Submodule path 'vim/bundle/supertab': checked out 'cdaa5c27c5a7f8b08a43d0b2e65929512299e33a' 
Submodule path 'vim/bundle/vim-flake8': checked out '91818a7d5f5a0af5139e9adfedc9d00fa963e699' 
Submodule path 'vim/bundle/vim-pathogen': checked out '7ba2e1b67a8f8bcbafedaf6763580390dfd93436' 

कि पिछले आदेश 012,ने HEAD में संग्रहीत सबड्यूलर हैश को देखा, और मेरे काम करने वाले पेड़ को अपडेट किया (यह उन्हें अपने संबंधित रिपो में सबसे हालिया कामों में अपडेट नहीं करता है; यह git submodule update --remote है), संबंधित पथों पर संबंधित रिपॉजिटरीज की सामग्रियों को जोड़कर, इतनी बार कर रहा है (इसलिए यदि मेरे किसी भी submodules में submodules हैं, जो वे करते हैं, तो उन भंडारों की सामग्री भी मेरे काम करने वाले पेड़ में जोड़ दी जाती है)।

अब, यह इतना है कि मैं HEAD~2 में मेरी विम प्लगइन्स अद्यतन:

$ git show HEAD~2 -- vim/bundle/* 
commit 27bfe76851991026bd026b4bf2ab10d6ecbc6f74 
Author: First Last <[email protected]> 
Date: Thu Feb 2 13:33:30 2017 -0600 

    update dependencies 

diff --git a/vim/bundle/jedi-vim b/vim/bundle/jedi-vim 
index f191ccd..8cf616b 160000 
--- a/vim/bundle/jedi-vim 
+++ b/vim/bundle/jedi-vim 
@@ -1 +1 @@ 
-Subproject commit f191ccd6fb7f3bc2272a34d6230487caf64face7 
+Subproject commit 8cf616b0887276e026aefdf68bc0311b83eec381 
diff --git a/vim/bundle/nerdtree b/vim/bundle/nerdtree 
index eee431d..2817010 160000 
--- a/vim/bundle/nerdtree 
+++ b/vim/bundle/nerdtree 
@@ -1 +1 @@ 
-Subproject commit eee431dbd44111c858c6d33ffd366cae1f17f8b3 
+Subproject commit 281701021c5001332a862da80175bf585d24e2e8 
diff --git a/vim/bundle/supertab b/vim/bundle/supertab 
index 6651177..cdaa5c2 160000 
--- a/vim/bundle/supertab 
+++ b/vim/bundle/supertab 
@@ -1 +1 @@ 
-Subproject commit 66511772a430a5eaad7f7d03dbb02e8f33c4a641 
+Subproject commit cdaa5c27c5a7f8b08a43d0b2e65929512299e33a 

कहते हैं कि कुछ अभी मेरी विम प्लग इन के साथ अजीब हो रहा है, और मुझे लगता है के लिए प्रतिबद्ध है कि इसके बाद के संस्करण के लिए जिम्मेदार है यह अजीबता है, इसलिए मैं अपने प्लगइन को उन चीज़ों पर वापस रोल करना चाहता हूं जो मैंने उन्हें अपडेट करने से पहले किया था।

$ git checkout -b testing HEAD~2^ 
M  vim/bundle/jedi-vim 
M  vim/bundle/nerdtree 
M  vim/bundle/supertab 
Switched to a new branch 'testing' 
$ git status 
On branch testing 
Changes not staged for commit: 
    (use "git add <file>..." to update what will be committed) 
    (use "git checkout -- <file>..." to discard changes in working directory) 

     modified: vim/bundle/jedi-vim (new commits) 
     modified: vim/bundle/nerdtree (new commits) 
     modified: vim/bundle/supertab (new commits) 

no changes added to commit (use "git add" and/or "git commit -a") 

ठीक है, अब सामान थोड़ा अजीब लगता है। जब मैंने यह चेकआउट किया था, तो मेरे काम के पेड़ में मेरे पास कोई बदलाव नहीं था, तो ऐसा लगता है कि चेकआउट मेरे काम करने वाले पेड़ में बदलाव पेश कर रहा है? यहाँ क्या चल रहा है?

$ git diff 
diff --git a/vim/bundle/jedi-vim b/vim/bundle/jedi-vim 
index f191ccd..8cf616b 160000 
--- a/vim/bundle/jedi-vim 
+++ b/vim/bundle/jedi-vim 
@@ -1 +1 @@ 
-Subproject commit f191ccd6fb7f3bc2272a34d6230487caf64face7 
+Subproject commit 8cf616b0887276e026aefdf68bc0311b83eec381 
diff --git a/vim/bundle/nerdtree b/vim/bundle/nerdtree 
index eee431d..2817010 160000 
--- a/vim/bundle/nerdtree 
+++ b/vim/bundle/nerdtree 
@@ -1 +1 @@ 
-Subproject commit eee431dbd44111c858c6d33ffd366cae1f17f8b3 
+Subproject commit 281701021c5001332a862da80175bf585d24e2e8 
diff --git a/vim/bundle/supertab b/vim/bundle/supertab 
index 6651177..cdaa5c2 160000 
--- a/vim/bundle/supertab 
+++ b/vim/bundle/supertab 
@@ -1 +1 @@ 
-Subproject commit 66511772a430a5eaad7f7d03dbb02e8f33c4a641 
+Subproject commit cdaa5c27c5a7f8b08a43d0b2e65929512299e33a 

हू, ठीक है, तो यह दिलचस्प है। किसी कारण से, git diff कह रहा है कि मेरे वर्तमान काम करने वाले पेड़ में चेक किए गए सबमिड्यूल के संस्करण मेल नहीं खाते हैं - लेकिन यह भिन्नता लॉट जैसा कि मैंने ऊपर किया है git show जैसा दिखता है। मुझे आश्चर्य है कि क्या submodules HEAD में वास्तव में कर रहे ...

$ git ls-tree HEAD -- vim/bundle/ 
160000 commit f191ccd6fb7f3bc2272a34d6230487caf64face7 vim/bundle/jedi-vim 
160000 commit eee431dbd44111c858c6d33ffd366cae1f17f8b3 vim/bundle/nerdtree 
160000 commit 66511772a430a5eaad7f7d03dbb02e8f33c4a641 vim/bundle/supertab 
160000 commit 91818a7d5f5a0af5139e9adfedc9d00fa963e699 vim/bundle/vim-flake8 
160000 commit 7ba2e1b67a8f8bcbafedaf6763580390dfd93436 vim/bundle/vim-pathogen 

अहा! वहां हम जाते हैं - git checkout ने काम करने वाले पेड़ में सबमिशन के संस्करण को अपडेट नहीं किया है! गिट खुद को अभी भी पता है कि इन सबोडोड्यूल को किस हशों की जांच की जानी चाहिए। बदल जाता है वहाँ एक आदेश है कि आप के लिए यह कर देगा है बाहर:

$ git submodule update --init --recursive 
Submodule path 'vim/bundle/jedi-vim': checked out 'f191ccd6fb7f3bc2272a34d6230487caf64face7' 
Submodule path 'vim/bundle/jedi-vim/jedi': checked out '2ba78ab725f1e02dfef8bc50b0204cf656e8ee23' 
Submodule path 'vim/bundle/nerdtree': checked out 'eee431dbd44111c858c6d33ffd366cae1f17f8b3' 
Submodule path 'vim/bundle/supertab': checked out '66511772a430a5eaad7f7d03dbb02e8f33c4a641' 

अलग से आपकी चिंताओं को दूर करने के लिए: आम कोड से

  1. तोड़ मंच विशिष्ट कोड दूर तो आम में परिवर्तन कोड और/या एसडीके के पास अन्य प्लेटफॉर्म पर अप्रत्याशित परिणाम नहीं हैं।

    हाँ। Submodules।

  2. प्रत्येक प्लेटफ़ॉर्म के लिए प्रत्येक रिपॉजिटरीज़ बनाएं, प्रत्येक सामान्य कोड बेस और प्रत्येक एसडीके।

    इस तरह आप अपने वर्तमान codebase बाहर रखी है, उन पर एक बहुत निर्भर करने के लिए जा रहा है। यह संभव है कि git subtree हो जो आप चाहते हैं (विशेष रूप से git subtree split आपको एक अलग गिट रेपो में एक उपट्री में फ़ाइलों को निकालने देता है, प्रतिबद्ध इतिहास के साथ भर जाता है, लेकिन मुझे नहीं पता कि यह रिपो के साथ बड़े और पुराने के रूप में कितना अच्छा काम करेगा जैसा कि आप वर्णन कर रहे हैं - अधिक जानकारी के लिए man git subtree देखें)।

  3. एक स्थानीय मशीन एक रिमोट भंडार क्लोनिंग एक एक कदम प्रक्रिया होना चाहिए; नए उपयोगकर्ताओं को प्लेटफार्म बनाने से पहले प्रत्येक उप-संग्रह को खींचने के लिए मजबूर नहीं होना चाहिए।

    नहीं। उप-मॉड्यूल, डिज़ाइन द्वारा, उप-भंडार की सामग्री को ट्रैक न करें: यह सब-रिपोजिटरी का काम है। वे सब उप-रेपो में एक विशिष्ट प्रतिबद्धता के लिए एक सूचक रखें।

  4. इसके अतिरिक्त; पुराने कोड को बहाल करना, जिसमें सामान्य कोड और एसडीके शामिल है जिसका उपयोग किसी दिए गए प्लेटफ़ॉर्म के संस्करण XXX-YYY को बनाने के लिए किया गया था, संभव होना चाहिए। सामान्य कोड को संशोधित करने से प्लेटफार्मों को प्रभावित नहीं किया जाना चाहिए जब तक प्लेटफ़ॉर्म के रखरखाव नए सामान्य कोड में खींचें।(मेरा मानना ​​है कि इस आम कोड के टैग से एक जोड़कर उपतरू के साथ संभव है आम कोड के मास्टर के बजाय करता है)

    submodules डिजाइन करके करते हैं। यही कारण है कि वे रिमोट के बजाय विशिष्ट प्रतिबद्धताओं को इंगित करते हैं।

  5. केवल पढ़ने-योग्य उप-संग्रह एक स्वीकार्य सीमा है। (मंच के भंडार यानी उप भंडार या तो मंच के भंडार या उप-भंडार में परिवर्तन में बदला नहीं जा सकता से नहीं भेजा जा सकता है)

    submodules आम तौर पर केवल पढ़ने के लिए उप-खजाने के रूप में व्यवहार किया जाना चाहिए । Submodules से अद्यतन को धक्का देना संभव है, लेकिन यह सुनिश्चित करने के लिए उपयोगकर्ता पर अधिक ओवरहेड डालता है कि वे उस सबमिशन के संस्करण को पेंच नहीं करते हैं जिसके साथ वे काम कर रहे हैं। के रूप में सभी लेकिन हमारे सदस्यों में से एक का उपयोग करता है

  6. SmartGit/HG समर्थन वांछनीय है।

    यहाँ कोई गारंटी। इसे समझने के लिए आपको शायद सभी 3 विकास समुदायों (गिट, स्मार्टगिट, मर्कुरियल) तक पहुंचना होगा।

  7. स्क्रिप्टिंग एक बार कार्य स्वीकार्य है, लेकिन मैं स्क्रिप्ट है कि इसके लिए Git का काम करते हैं साथ प्लेटफार्मों अपवित्र नहीं करना चाहती।

    निर्भर करता है आप कैसे जटिल बात कर रहे हैं। मुझे लगता है कि अपने कोड के एक पुराने संस्करण बाहर की जाँच के ऊपर दिखाए गए हैं सिर्फ दो आदेशों है: checkout और submodule update --init --recursive है, लेकिन यह स्पष्ट नहीं है कि आप जो चाह रहे हैं।

+0

+1 आपका उत्तर VonC की तुलना में _far_ अधिक सहायक था। मैंने इस सवाल को संपादित करने के लिए संपादित किया है कि मैंने इसे डीबग करने के लिए रिपॉजिटरी को वापस कैसे घुमाया। (मैंने समस्या निर्माण की जांच नहीं की है) – JacaByte

+1

'रीसेट - हार्ड' करने के लिए मुझे लगता है कि 'सबमिशन अपडेट --init --recursive' की भी आवश्यकता होगी। किसी भी मामले में, 'गिट diff' आपके द्वारा उल्लिखित रोलबैक स्थिति के लिए भी काम करेगा। – Pockets

+1

टिप्पणी के लिए मैंने एक अंतर किया, मैं इसका उल्लेख करना भूल गया। और फिर मैंने पूरी चीज पढ़ी। एक वर्ष का लायक काम करता है। :( – JacaByte