2012-05-10 14 views
30

मैं एक विशिष्ट ग्रहण/सबवर्जन उपयोगकर्ता हूं जो गिट में माइग्रेशन शुरू कर रहा है। मैंने गिट की बुनियादी अवधारणाओं का शोध किया है और चीजों को सरल रखने के लिए शुरू में एक प्रति परियोजना प्रति रिपोजिटरी दृष्टिकोण से चिपकने का फैसला किया है। मुझे अभी भी परेशानी हो रही है, हालांकि, यह तय करना कि प्रत्येक परियोजना के लिए भंडार कहां रखना है।ग्रहण कार्यक्षेत्र के अंदर या बाहर गिट भंडार रखना बेहतर है?

मैंने this question के उत्तरों की समीक्षा करने में बहुत समय व्यतीत किया है, हालांकि मुझे विश्वास है कि उस प्रश्न के लेखक को यह माना जा रहा था कि यदि आप ग्रहण कार्यक्षेत्र के भीतर भंडार स्थित है, तो आप केवल भंडार का प्रबंधन करने के लिए ग्रहण का उपयोग कर सकते हैं, बेशक, सच नहीं है।

बात है कि मेरे, उस सवाल के बारे में सबसे मारा हालांकि, तथ्य यह है कि सभी लेकिन एक जवाब (स्वीकार किए जाते हैं जवाब भी शामिल है), जबकि केवल एक ही जवाब ने बताया कि EGit User Guide सिफारिश की गई है ग्रहण कार्यक्षेत्र के अंदर भंडार रखने का सुझाव दिया था ठीक उलटा।

यह प्रैक्टिस में दिखाई देगा, हालांकि, ग्रहण/ईजीआईटी द्वारा लागू कई दृष्टिकोण हैं, जिनमें से कुछ ईजीआईटी सिफारिशों का खंडन करते हैं।

उदाहरण के लिए, यदि आप गिट से नया PHP प्रोजेक्ट बनाने के लिए नया प्रोजेक्ट विज़ार्ड का उपयोग करते हैं और रिपोजिटरी रिमोट है, तो ग्रहण/ईजीट ग्रहण कार्यक्षेत्र में खुशी से एक प्रोजेक्ट फ़ोल्डर बनायेगा और रिपोजिटरी (.git) रखेगा परियोजना फ़ोल्डर। यह अंत परिणाम है जो मैं वास्तव में चाहता हूं, क्योंकि यह ग्रहण कार्यक्षेत्र के भीतर सब कुछ encapsulated रखता है।

हालांकि, यदि आप नए प्रोजेक्ट विज़ार्ड का उपयोग करते हैं और स्थानीय गिट रिपोजिटरी का चयन करते हैं, तो एक्लिप्स/ईजीट रिमोट रिपोजिटरी के लिए रिपोजिटरी को क्लोन नहीं करता है। इसके बजाय यह प्रोजेक्ट स्थान के रूप में उस भंडार की कार्यशील प्रति का उपयोग करता है, उस स्थान पर इसकी प्रोजेक्ट और अन्य मेटा सामग्री बनाता है और उस प्रोजेक्ट के भीतर एक नई (प्रतीत होता है अनावश्यक) फ़ोल्डर बनाता है जो आपके प्रोजेक्ट के समान नाम से होता है (इसलिए आप समाप्त करते हैं उदाहरण के लिए, ~/git/blah/blah)। यदि आप उस अनावश्यक फ़ोल्डर को हटाते हैं जो आप पहले उदाहरण के समान संरचना के साथ समाप्त होते हैं, तो केवल अंतर यह है कि प्रोजेक्ट फ़ोल्डर आपके ग्रहण कार्यक्षेत्र फ़ोल्डर का उप-फ़ोल्डर नहीं है, यह आपके फ़ाइल सिस्टम पर कहीं और है (उदाहरण के लिए ~/git/blah)। ऐसा लगता है कि इस दृष्टिकोण के लिए एकमात्र सकारात्मक बात यह है कि यह ईजीआईटी उपयोगकर्ता मार्गदर्शिका में सिफारिशों का पालन करता है, लेकिन एक तकनीकी परिप्रेक्ष्य से, यह देखना मुश्किल है कि यह वास्तव में पहले उदाहरण के लिए अलग कैसे है।

इन परेशान अवलोकनों को देखते हुए, मैं सोच रहा हूं कि लोगों ने इन दृष्टिकोणों का उपयोग करके किस प्रकार के अनुभवों का उपयोग किया है और यदि कोई ईजीट उपयोगकर्ता मार्गदर्शिका में सिफारिशों को अनदेखा करता है तो क्या नुकसान हो सकता है।

+0

संभावित डुप्लिकेट [क्या मुझे घर या ग्रहण कार्यक्षेत्र में गिट भंडार स्टोर करना चाहिए?] (Http://stackoverflow.com/questions/7685246/should-i-store-git-repository-in-home-or-eclipse- वर्कस्पेस) – mallardz

+0

@JamesG आपके गिट निर्देशिका में वर्कस्पेस में हुए बदलावों को दर्शाने के लिए आप क्या दृष्टिकोण लेते हैं? स्रोत कोड चिपकाने के लिए एक बेहतर विकल्प है? –

+0

मैं अब ग्रहण का उपयोग नहीं करता - मैं PHPStorm का उपयोग करता हूं - इसलिए मैं बस एक प्रोजेक्ट फ़ोल्डर में क्लोन करता हूं और फिर वहां काम करना शुरू करता हूं। मुझे नहीं लगता कि PHPStorm भी परियोजना में एक अलग फ़ोल्डर में भंडार को स्टोर करने का विकल्प प्रदान करता है। ईमानदारी से, जो मैंने सुना है और चार साल पहले इस प्रश्न को पोस्ट करने के बाद पढ़ा है, मुझे नहीं लगता कि बहुत से लोग अपने प्रोजेक्ट फ़ोल्डरों के बाहर अपने भंडार भंडारित करेंगे। – JamesG

उत्तर

17

दोनों समाधानों के प्रभाव सीधे आपके द्वारा जुड़े गए उपयोगकर्ता मार्गदर्शिका में सूचीबद्ध हैं। भाग

यह परिणाम कर सकते हैं प्रदर्शन में जारी करता है कि

दुर्भाग्य से बिल्कुल सच है मैं आपको बता सकता। इसलिए यदि आपके पास आपके वर्कस्पेस के अंदर बड़ी संख्या में फाइलों के साथ गिट निर्देशिका है, तो कई गिट ऑपरेशंस "गिनती ऑब्जेक्ट्स ..." संवाद से शुरू हो जाएंगे जो आपके आईडीई को अवरुद्ध करता है क्योंकि यह कार्यक्षेत्र में सभी फ़ाइलों को स्कैन करता है। मेरी वर्तमान 20000 फाइलों के लिए इसका मतलब है कि हर प्रतिबद्धता के लिए 10 से 20 सेकेंड का इंतजार, प्रत्येक स्विच, ...

अतिरिक्त समय की गतिविधियों में, जहां मैं सौभाग्य से अन्य विकल्प (वर्कस्पेस के बाहर गिट कामकाजी निर्देशिका रखने) का उपयोग कर सकता हूं बहुत स्नैपियर महसूस करता है और मर्ज करना और स्विच करना मजेदार है।

तो यदि आप बड़ी परियोजनाओं के लिए जाते हैं, तो वर्कस्पेस के बाहर पहली पसंद के रूप में गिट निर्देशिका पर विचार करें।

+0

मैं जोड़ दूंगा कि ग्रहण और ईजीट स्वयं अपने कार्यक्षेत्र के बाहर अपने गिट रेपो का उपयोग करने के लिए खुद को स्थापित कर लेगा, और यह ठीक काम कर रहा है। –

+3

@ बानान्यूइज़ेन आपने उल्लेख किया है कि आपने वर्कस्पेस के बाहर गिट काम करने वाली निर्देशिका रखने के साथ प्रयोग किया है और सबकुछ स्नैपियर था। क्या आपकी बड़ी (20,000 फाइलें) परियोजना या छोटी सैंडबॉक्स परियोजनाओं के साथ किए गए उन प्रयोगों में से एक था? यही है, क्या आप निश्चित रूप से कह सकते हैं कि 20,000 फाइल प्रोजेक्ट वर्कस्पेस के बाहर और अधिक आसानी से काम करता है? – JamesG

+0

@Bananeweizen क्या आप बस किसी अन्य निर्देशिका में सबकुछ xcopy करते हैं, फिर इसे गिट एड करने से पहले इसे वापस संग्रहित करें? –

3

मैं मूल पोस्टर के रूप में ही प्रवास कर रहा हूँ और एक अन्य धागा जहां एक ही संदेह Egit सिफारिश पर व्यक्त कर रहे हैं पाया है: Should I store git repository in Home or Eclipse Workspace?

@JamesG तो यह अपने लेआउट है?

~/projectA/workspace/.metadata 
~/projectA/workspace/subproj1/.project 
~/projectA/workspace/subproj2/.project 
~/projectA/subproj1/.git 
~/projectA/subproj1/file1 
~/projectA/subproj2/.git 
~/projectA/subproj1/file2 
+0

उस पोस्ट को जोड़ने के लिए धन्यवाद। इसने एक परियोजना प्रति एक भंडार बनाम एक गिट रिपोजिटरी के भीतर कई परियोजनाओं के बीच एक बड़ा अंतर बना दिया। यदि पूर्व के लिए जा रहा है, तो मैं मानता हूं कि वर्कस्पेस में रेपो डालने से कोई अर्थ नहीं होता है, क्योंकि तब .git निर्देशिका परियोजनाओं के समान स्तर पर होती है, जो मुझे मेरे लिए सादा गलत लगता है। मेरे मामले में, मेरे पास रेपो संरचना का निर्धारण करने की लक्जरी है, इसलिए मैंने प्रति परियोजना एक रेपो पर फैसला किया है, इसलिए प्रत्येक ग्रहण परियोजना रेपो का एक क्लोन है। यह दृष्टिकोण मेरे लिए अच्छी तरह से काम कर रहा है, यहां तक ​​कि बड़ी परियोजनाओं (उदाहरण के लिए जेडएफ 2) के लिए भी। – JamesG

5

क्यों न केवल 2 संभावनाओं की अनुमति दें।

मैं एक बड़ी परियोजना के मामले में ठीक हूं जो .metadata फ़ोल्डर में कई फाइलें उत्पन्न करता है। भले ही प्रदर्शन को बेहतर बनाने के लिए .gitignore में .metadata लाइन डालना बहुत आसान है।

लेकिन मेरे मामले में (एंड्रॉइड डेवलपमेंट), मेरे पास लगभग 35 अलग-अलग परियोजनाएं हैं जिनमें केवल 50 फाइलें हैं।

ये सभी परियोजनाएं इस परियोजना के लिए एप्लिकेशन प्रोजेक्ट और लाइब्रेरी प्रोजेक्ट वाली विभिन्न वर्डस्पेस में हैं। (आवेदन प्रति submodules के साथ एक भंडार)

  • मैं सिर्फ अपने सभी के अंदर (पैकेज एक्सप्लोरर में स्क्रॉल/बंद/खुला परियोजनाओं के लिए समय बिताने) परियोजनाओं के साथ एक कार्यक्षेत्र होना चाहिए?

  • क्या मुझे अपनी सभी परियोजनाओं के केवल .metadatas फ़ोल्डर्स वाले अंतिम 2 फ़ोल्डर्स (प्रोजेक्ट्स और वॉर्स्स्पेस) का प्रबंधन करना चाहिए?

मेरे लिए यह समझ में नहीं आता है। EGit टीम को

संदेश:

क्यों रास्ता डेवलपर्स को बदलने आमतौर पर उनकी परियोजनाओं फ़ोल्डरों को व्यवस्थित:

---- Worspace

---- Worspace/.metada

----- Worspace/.git

----- Worspace/Project1

----- Worspace/LibraryProject1

----- Worspace/LibraryProject2

मैं सिर्फ प्रदर्शन कारण समझते हैं लेकिन बहुत बड़ी परियोजनाओं के साथ डेवलपर्स के सिर्फ 5% के लिए (बड़ा .metadata पैदा करने) आप हमें हमारी परियोजनाओं की संरचना करने की इजाजत नहीं दी गई है जैसे ग्रहण हमें वर्षों से करने के लिए कहता है।

तुम सिर्फ एक संदेश हमें चेतावनी देते हैं, भले ही यह है कि यह सलाह नहीं दी जाती है, worspace फ़ोल्डर में क्लोन प्रक्रिया को ब्लॉक कर सकते हैं नहीं है ("C: \ Worspaces \ एक खाली निर्देशिका नहीं है")

EGit है एक अच्छा उपकरण है, लेकिन मैं वास्तव में इस
सीमा के बैश मार्ग बीकॉज़ का उपयोग करने के बारे में सोच रहा हूं।

आपके उत्तर

पी एस के लिए धन्यवाद: ग्रहण के तहत developement के कई अलग अलग मामलों रहे हैं। यदि यह केवल एक प्रदर्शन मुद्दा है और यदि यह ईजीआईटी दुर्घटना नहीं करता है, तो कृपया हमें इसके बारे में चेतावनी दें लेकिन छोटी परियोजनाओं के मामले में हमें अवरुद्ध न करें।

+1

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