गिट submodules वर्कफ़्लो मुद्दों

Question

हमें हाल ही में हमारे गिट भंडारों के साथ कई समस्याएं आ रही हैं। हम अपने अनुप्रयोगों के बीच कुल 4 साझा भंडारों के लिए गिट सबमिड्यूल के उपयोगकर्ता हैं।

उदाहरण के लिए, भंडार 'वेबसाइट' में कुल 3 सबोड्यूल हैं।

[submodule "vendor/api"] 
    path = vendor/api 
    url = git@your.cool.domain.com:api 
[submodule "vendor/auth"] 
    path = vendor/auth 
    url = git@your.cool.domain.com:auth 
[submodule "vendor/tools"] 
    path = vendor/tools 
    url = git@your.cool.domain.com:tools 

हमने सही ढंग से हमारी मुख्य भंडार 'वेबसाइट' की जांच की है। अब मेरी सह कार्यकर्ताओं में से एक, एक धक्का किया है तो मैं git pull; git status:

# On branch master 
# Changed but not updated: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
# modified: vendor/api (new commits) 
# modified: vendor/auth (new commits) 
# modified: vendor/tools (new commits) 
# 
no changes added to commit (use "git add" and/or "git commit -a") 

mcfly@future:~/projects/website$ git diff 

diff --git a/vendor/api b/vendor/api 
index 41795fc..b582d80 160000 
--- a/vendor/api 
+++ b/vendor/api 
@@ -1 +1 @@ 
-Subproject commit 41795fc4dde464d633f4c0f01eebb6ab1ad55582 
+Subproject commit b582d802419b0ee7bc3959e7623fec0b94680269 
diff --git a/vendor/auth b/vendor/auth 
index a00369b..4599a71 160000 
--- a/vendor/auth 
+++ b/vendor/auth 
@@ -1 +1 @@ 
-Subproject commit a00369bf29f14c761ce71f7b95aa1e9c107fb2ed 
+Subproject commit 4599a7179c9b7ca4afa610a15ffa4a8fc6ebf911 
diff --git a/vendor/tools b/vendor/tools 
index f966744..c678cf6 160000 
--- a/vendor/tools 
+++ b/vendor/tools 
@@ -1 +1 @@ 
-Subproject commit f966744359510656b492ae3091288664cdb1410b 
+Subproject commit c678cf6f599fc450e312f0459ffe74e593f5890f 

कि git diff साथ समस्या क्या है? समस्या यह है कि प्रत्येक सबमिशन के लिए नया काम ओल्डर होता है जो ओवरराइट किया जाएगा। यह वही नहीं है जो हम चाहते हैं क्योंकि भंडार पर 41795fc4dde464d633f4c0f01eebb6ab1ad55582, a00369bf29f14c761ce71f7b95aa1e9c107fb2ed और f966744359510656b492ae3091288664cdb1410b पर सही ढंग से इशारा कर रहा है और यदि हम अपने संशोधनों में यह संशोधन जोड़ते हैं तो हम शायद चीजों को तोड़ देंगे। मुझे नहीं पता कि यह सबसे पुराना संशोधन क्यों प्राप्त कर रहा है और न कि नवीनतम।

mcfly@future:~/projects/website$ git pull; git submodule foreach git pull 

पिछले आदेश यह सही नहीं है कर रहा है क्योंकि हम शायद प्रत्येक submodule के नवीनतम और हम करने के लिए 'वेबसाइट' का सूचक अपडेट कर देगा:

मैं अपने आप को द्वारा लेकिन कोई सफलता के साथ इस का समाधान करने की कोशिश की यह नहीं चाहते हैं। हम सही संशोधन को संरक्षित करना चाहते हैं कि यह भंडार पर है।

चीजें हैं जो मैं समझाने की है कि हम आम तौर पर, इस submodules के अंदर काम उदाहरण के लिए है में से एक:

mcfly@future:~/projects/website$ cd vendor/api 
mcfly@future:~/projects/website/vendor/api$ git checkout master 
mcfly@future:~/projects/website/vendor/api$ echo "lorem ipsum" >> example.file 
mcfly@future:~/projects/website/vendor/api$ git add example.file; git push 

जब हम एक git submodule update करना 'गुरु' शाखा हर submodule पर खो दिया है।

अंत में, push, pull करने और submodules के साथ काम करने और इन सभी समस्याओं को नहीं करने का सही तरीका क्या है?

अग्रिम

Answer 1

में धन्यवाद git-scm documention पर एक नजर डालें और अपनी टीम के लिए चारों ओर इसे पारित। जो घटना आप देख रहे हैं वह वास्तव में "Cloning a Project with Submodules" अनुभाग में वर्णित है।

पहले, प्रारंभिक अवस्था आप मनाया है, जहां git diff से पता चलता हैश प्रतिबद्ध लोगों के लिए अप्रत्याशित रूप से विपरीत परिणाम, यह संकेत करता है कि आप माता-पिता रेपो में एक submodule अद्यतन विलय कर दिया है, लेकिन स्थानीय स्तर पर git submodule update नहीं चला। जब भी आप मुख्य प्रोजेक्ट में एक सबमिशन परिवर्तन खींचते हैं तो आपको git submodule update चलाना होगा। क्यूं कर? सबमिशन के पॉइंटर, यानी अभिभावक भंडार क्या सोचता है vendor/auth की स्थिति है, वास्तव में HEAD सबमिशन रिपोजिटरी vendor/auth की प्रतिबद्धता नहीं है। जब तक आप समझते हैं कि गिट सबमिशन राज्यों को कैसे ट्रैक कर रहा है, यह थोड़ा उलझन में है। फिर, git-scm documentation पढ़ने के लायक है।

दूसरा, git submodule update डिज़ाइन द्वारा सबमिशन पर master शाखा को छोड़ देता है। उन दस्तावेज़ों के "Issues with submodules" अनुभाग देखें। आदमी पेज, जैसा कि अक्सर Git के साथ सच है, हमें बताता है कि हम क्या पता करने की जरूरत:

update 
    Update the registered submodules, i.e. clone missing submodules and checkout the commit specified in the index of the containing repository. This will 
    make the submodules HEAD be detached unless --rebase or --merge is specified or the key submodule.$name.update is set to rebase, merge or none. none 
    can be overridden by specifying --checkout. 

आप तर्क के बिना हर बार जब आप जारी git submodule update 'अलग HEAD' राज्य में अपने submodules डाल रहे हैं।

तो आप इन समस्याओं के बिना submodules के साथ कैसे काम करते हैं? सबसे पहले, खुद और अपनी टीम से पूछें: क्या हमें वास्तव में उनकी ज़रूरत है? Submodules कुछ मामलों में एक शक्तिशाली और उपयोगी विशेषता है, लेकिन वे उप-भंडारों में सक्रिय सक्रिय परियोजनाओं की तुलना में तीसरे पक्ष पुस्तकालयों के लिए अधिक डिजाइन किए गए थे। आप निश्चित रूप से इन तरीकों का उपयोग कर सकते हैं, लेकिन प्रबंधन ओवरहेड जो भी लाभ प्राप्त कर रहा है उससे तेज़ी से बढ़ सकता है। जब तक आपका भंडार काफी बड़ा न हो, या आपका सबोड्यूल्यूल पूरी तरह से मॉड्यूलर न हो, तो "Would we be better off with a single repository?" पूछने लायक है, भले ही उत्तर "नहीं" है, subtree merging, देखें जो आपके उपयोग के मामले में अधिक सफल हो सकता है।

यदि आप अभी भी पनडुब्बियों का उपयोग करना चाहते हैं, तो ऊपर से जुड़े the docs, साथ ही साथ questions और answers एसओ और अन्य मॉड्यूल वर्कफ़्लो के बारे में अन्य साइट देखें। उन्हें एक सैनर प्रक्रिया प्राप्त करने में आपकी मदद करनी चाहिए।