2010-06-08 16 views
12

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

हम मुख्य रूप से Joomla! सामग्री प्रबंधन प्रणाली (सीएमएस) पर हमारी वेबसाइटें विकसित करते हैं। मैं जानना चाहता हूं कि सीएमएस से निपटने के दौरान अन्य कंपनियां अपने भंडार कैसे प्रबंधित करती हैं। हम मुख्य रूप से टेम्पलेट भवन से निपटते हैं, और हम कभी-कभी उन घटकों या प्लगइन्स को कस्टमाइज़ करते हैं जिन्हें हमने इंस्टॉल किया है।

मेरा मुख्य सवाल कर रहे हैं:

  • सबसे अच्छा तरीका भंडार में (जूमला फ़ाइलों सहित) सभी फाइलों को स्टोर करने के लिए है, या बस फ़ाइलें है कि आप कर सकते हैं या अपने आप को बदलना?
  • क्या आप डेटाबेस परिवर्तनों के खाते में कहीं भी डेटाबेस की प्रतिलिपि रखते हैं (जो जूमला अपने ऑपरेशन और सामग्री भंडारण के लिए उपयोग करता है)?
+1

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

उत्तर

4

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

1

हम आपके लिए इसी तरह की स्थिति में हैं - जूमला साइटों के साथ डिज़ाइन एजेंसी।

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

5

Joe LeBlanc द्वारा यह लेख कुछ चीजों में से एक मैं जूमला में संशोधन नियंत्रण !: http://joomlaablog.blogspot.it/2010/11/how-to-track-your-joomla-project-with.html

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

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

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

2

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

मैं अलग-अलग भंडारों के लिए अलग-अलग भंडारों के लिए वकालत करता हूं, लेकिन मैं अभी भी एक संपूर्ण घटक (व्यवस्थापक + फ्रंट + इंस्टॉल) में एक रेपो रखने का तरीका ढूंढ रहा हूं। कोई विचार (submodules या subtree शायद विलय)?

9

मुझे पता है कि इस प्रश्न को पहले से ही एक स्वीकार्य उत्तर मिला है लेकिन शायद कोई इस पर वापस आ जाएगा और इसे उपयोगी लगेगा।

  • मुझे लगता है कि पूरे जूमला को ट्रैक करना और कोर फाइलों को बाहर करने की कोशिश करना लगभग असंभव है और @ vicgilbcn का कहना है कि यह एक दुःस्वप्न बन सकता है।
  • दूसरी तरफ यदि आप जे के लिए एक घटक विकसित कर रहे हैं! 'दुर्भाग्यवश' 'घटकों/com_mycomp', 'व्यवस्थापक/घटक/com_mycomp' और शायद 'मीडिया/com_mycomp' में फिसल गया है, आपको ट्रैक करने के लिए 3 अलग-अलग गिट रेपो होना चाहिए - इसलिए यह व्यवहार्य नहीं है।

तो मैं किसके साथ आया और बहुत अच्छी तरह से काम कर रहा प्रतीत होता है, यह है: मान लें कि मेरे पास सामान्य जे है! अंदर मेरे com_mycomp घटक के साथ निराशा।

  • मैं जूमला कोडबेस के बाहर एक फ़ोल्डर बनाता हूं और इसे "COMMON" कहता हूं।
  • में
  • "आम" मैं में "सामान्य/जूमला" एक "जूमला" फ़ोल्डर
  • बनाने मैं "myComp" फ़ोल्डर जो मेरे घटक
  • में "सामान्य/Joomla/myComp" मैं का उपयोग करने की पूरी codebase का आयोजन करेगा बनाने जूमला फ़ोल्डर संरचना और I MOVE (प्रतिलिपि नहीं) 'घटक/com_mycomp', 'व्यवस्थापक/घटक/com_mycomp' और 'मीडिया/com_mycomp' इसके अंदर।
  • फिर मैं उन स्थानों पर वापस जाता हूं जहां मैंने फ़ोल्डरों को हटा दिया और सिम्लिंक नए स्थानों पर बना दिया।

इस तरह अब कोई COMMON/joomla/myComp में एक गिट भंडार बना सकता है।

जाहिर है, यह वातावरण एक स्थानीय विकास वातावरण होना चाहिए जहां आप इस काम को करने के लिए सुरक्षा प्रभाव के बिना अपाचे/PHP कॉन्फ़िगरेशन समायोजित कर सकते हैं। (मुझे याद नहीं है कि अगर मुझे वास्तव में काम करने के लिए कोई विशेष कॉन्फ़िगरेशन संशोधन करना पड़ता है - यदि यह लॉग की जांच नहीं करता है ...)

वास्तव में, यह समाधान एक और समस्या का समाधान करता है। इस तरह से काम करते हुए आप वास्तव में अपने घटक के कोडबेस फ़ोल्डर को दो अलग जूमला तैनाती (उदाहरण के लिए जे! 2.5.एक्स और जे 3.एक्स.एक्स) में सिमंक कर सकते हैं और विभिन्न संस्करणों के खिलाफ तत्काल तरीके से अपने घटक compatibiliy को विकसित/जांचने में सक्षम हो सकते हैं।

+0

अच्छा जवाब! 'COMMON/joomla/myComp "में मैं जूमला फ़ोल्डर संरचना का उपयोग करता हूं' क्या इसका मतलब है कि आप पूर्ण जूमला संरचना या केवल इन तीन फ़ोल्डर्स: घटक, व्यवस्थापक और मीडिया? धन्यवाद –

संबंधित मुद्दे