यदि आप कोकोआपोड्स का उपयोग कर रहे हैं, तो आपके .gitignore में क्या है?

Question

मैं कुछ महीनों के लिए आईओएस विकास कर रहा हूं और बस निर्भरता प्रबंधन के लिए होनहार कोकोआपोड्स लाइब्रेरी के बारे में सीखा है ।

मैं एक निजी परियोजना पर इसे बाहर की कोशिश की: करने के लिए एक निर्भरता जोड़ा कीवी मेरी Podfile, के चलने के pod install CocoaPodsTest.xcodeproj, और देखा , यह बहुत अच्छा काम किया।

केवल एक चीज जो मुझे आश्चर्यचकित करती है वह यह है: मैं क्या जांच करूं और संस्करण नियंत्रण के लिए मैं क्या अनदेखा करूं? यह स्पष्ट लगता है कि मैं पॉडफाइल में ही जांच करना चाहता हूं, और शायद .xcworkspace फ़ाइल भी; लेकिन क्या मैं फली / निर्देशिका की उपेक्षा करता हूं? क्या अन्य फाइलें हैं जो सड़क के नीचे उत्पन्न होंगी (जब मैं अन्य निर्भरताएं जोड़ूंगा) जो मुझे अपने .gitignore में भी जोड़ना चाहिए?

Answer 1

व्यक्तिगत रूप से मैं फली निर्देशिका और सामग्री में जाँच नहीं करता। मैं यह नहीं कह सकता कि मैंने निहितार्थों पर विचार करते हुए लंबी उम्र बिताई लेकिन मेरा तर्क कुछ इस तरह है:

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

Comments

यह उल्लेखनीय है कि CocoaPods परियोजना उदाहरण में पॉड्स निर्देशिका को अनदेखा करती है ।

— जोशेपवर्थ

मैं Podfile.lock फ़ाइल को जोड़ने पर विचार करूंगा, क्योंकि तब आप वास्तव में उन पुस्तकालयों के संस्करणों को रिकॉर्ड करते हैं जो आपने किसी विशिष्ट बिल्ड के लिए उपयोग किए थे, और टीम के अन्य सदस्यों के लिए इसे पुन: प्रस्तुत कर सकते हैं। "एक्स के किस संस्करण का आप उपयोग कर रहे हैं" पूछना बहुत कष्टप्रद हो सकता है। यहाँ माणिक जेमफाइल समकक्ष की एक अच्छी चर्चा है: yehudakatz.com/2010/12/16/…

— मैट कॉनॉली

मुझे समझ में नहीं आता कि आप पॉडफाइल.लोक क्यों करेंगे, क्या आपको अपने पॉडफाइल में सिर्फ इतना विशिष्ट नहीं होना चाहिए कि आप किन संस्करणों पर निर्भर हैं? मैं क्या नहीं समझ रहा हूँ?

— माइकल बाल्टाकस

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

— दाविदकोव्स्की

यह उल्लेख करना महत्वपूर्ण है Podfile.lock: इसे Cocoapods द्वारा संस्करण नियंत्रण के तहत अनुशंसित होने के रूप में कहा जाता है ।

— cbowns

Answer 2

मैं अपनी पॉड्स निर्देशिका करता हूं। मैं इस बात से सहमत नहीं हूं कि पॉड्स डायरेक्टरी एक बिल्ड आर्टिफैक्ट है। वास्तव में मैं कहूंगा कि यह निश्चित रूप से नहीं है। यह आपके एप्लिकेशन स्रोत का हिस्सा है: यह इसके बिना निर्माण नहीं करेगा!

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

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

यदि आप बार-बार शाखाओं को स्विच करते हैं, तो आपकी पॉड्स निर्देशिका को कमिट नहीं करना भी एक भारी सिरदर्द बनाता है। अब आपको हर बार जब आप शाखाओं को स्विच करना चाहते हैं, तो सुनिश्चित करें कि आपकी निर्भरता सही हो। यह कम परेशानी वाला हो सकता है क्योंकि आपकी निर्भरता स्थिर हो जाती है, लेकिन एक परियोजना में जल्दी यह एक बड़े समय का सिंक है।

तो, मैं क्या उपेक्षा? कुछ भी तो नहीं। पॉडफाइल, लॉक फाइल और पॉड्स निर्देशिका सभी प्रतिबद्ध हैं। मेरा विश्वास करो, यह आपको बहुत परेशानी से बचाएगा। क्या विपक्ष हैं? थोड़ा बड़ा रेपो? दुनिया समाप्त नहीं हो जाती है।

Comments

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

— जोशुआ ग्रॉस

शाखा स्विच करते समय और जब समय में वापस जाना आसान हो जाता है ... यह एक बड़ा तर्क है।

— महाशय

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

— ल्यूक रेडपथ

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

— फतहोकू

It won't build without it!आप XCode को भी कमिट कर सकते हैं

— सौरभ

Answer 3

मैं GitHub के Objective-C gitignore का उपयोग करने की सलाह देता हूं । विस्तार से, सर्वोत्तम प्रथाएँ हैं:

• Podfile चाहिए हमेशा स्रोत नियंत्रण में हो।
• Podfile.lock चाहिए हमेशा स्रोत नियंत्रण में हो।
• कोकोपोड्स द्वारा उत्पन्न कार्यक्षेत्र को स्रोत नियंत्रण में रखा जाना चाहिए।
• :pathविकल्प के साथ संदर्भित किसी भी पोड को स्रोत नियंत्रण में रखा जाना चाहिए।
• ./Podsफ़ोल्डर कर सकते हैं स्रोत नियंत्रण में रखा जा सकता है।

अधिक जानकारी के लिए आप आधिकारिक गाइड का उल्लेख कर सकते हैं ।

source: मैं CocalPods की कोर टीम का सदस्य हूं, जैसे @alloy

---

हालांकि पॉड्स फ़ोल्डर एक बिल्ड आर्टवर्क है, ऐसे कारण हैं जो आप इसे नियंत्रण में रखने के लिए विदर तय करते समय विचार कर सकते हैं:

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

Comments

कार्यक्षेत्र फ़ाइल रखने में परेशान क्यों? यह वैसे भी Cocoapods द्वारा उत्पन्न होता है।

— फतहोकू

Cocoapods- अंधा निरंतर-एकीकरण परीक्षण सर्वर के लिए @fatuhoku, मेरे अनुभव में। मैं यह सब जांचता हूं क्योंकि मुझे अपने CI होस्ट (व्यावसायिक नियम) के लिए बिल्ड स्क्रिप्ट तक पहुंच नहीं है और एक डेवलपर टूल के रूप में कोकोपोड्स का इलाज करता है, न कि एक बिल्ड सिस्टम या पैकेज मैनेजर।

— कोडपोइट

CocodPods द्वारा .Pod फोल्डर को सोर्स कंट्रोल (यह ऑटो उत्पन्न होता है) के अंतर्गत नहीं रखा जाना चाहिए। पॉड्स फोल्डर बिल्ड प्रोसेस का एक आर्टिफैक्ट है। कार्यक्षेत्र को स्रोत नियंत्रण से भी हटाया जा सकता है जब तक कि उसके पास अन्य परियोजनाएं नहीं हैं जो कोकोपोड्स के साथ प्रबंधित नहीं हैं।

— व्लाद

मुझे लगता है कि इसकी जाँच होनी चाहिए क्योंकि एक फली स्थापित करने के लिए दर्द होता है जब मैं एक पुल करता हूं।

— mskw

Answer 4

.gitignore फ़ाइल

कोई जवाब वास्तव में प्रदान नहीं करता है .gitignore, इसलिए यहां दो स्वाद हैं।

---

फली निर्देशिका ( लाभ ) में जाँच

Xcode / iOS के अनुकूल git को अनदेखा करना, Mac OS सिस्टम फ़ाइलों को छोड़ना, Xcode, बिल्ड, अन्य रिपॉजिटरी और बैकअप।

.gitignore:

# Mac OS X Finder
.DS_Store

# Private Keys
*.pem

# Xcode legacy
*.mode1
*.mode1v3
*.mode2v3
*.perspective
*.perspectivev3
*.pbxuser

# Xcode
xcuserdata/
project.xcworkspace/
DerivedData/

# build products
build/
*.[oa]

# repositories
.hg
.svn
CVS

# automatic backup files
*~.nib
*.swp
*~
*(Autosaved).rtfd/
Backup[ ]of[ ]*.pages/
Backup[ ]of[ ]*.key/
Backup[ ]of[ ]*.numbers/

---

फली निर्देशिका की उपेक्षा ( लाभ )

.गरिग्नोर: (पिछली सूची में संलग्न)

# Cocoapods
Pods/

आप पॉड्स डायरेक्टरी में चेक करते हैं या नहीं, पॉडफाइल और पॉडफाइल.लॉक को हमेशा वर्जन कंट्रोल में रखा जाना चाहिए।

यदि Podsचेक-इन नहीं किया जाता है, तो Podfileसंभवतः आपको प्रत्येक कोकोपॉड के लिए स्पष्ट संस्करण संख्याओं का अनुरोध करना चाहिए। Cocoapods.org यहां चर्चा करता है ।

Answer 5

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

अगर यह हमारी खुद की एक ऐप होती, तो मैं पॉड्स डायरेक्टरी को तब तक के लिए छोड़ देता, जब तक कि मैं उस पर काम नहीं करूंगा।

वास्तव में, मुझे यह निष्कर्ष निकालना चाहिए कि मैं आपके सवाल का जवाब देने के लिए सबसे अच्छा व्यक्ति नहीं हो सकता, बनाम शुद्ध उपयोगकर्ताओं के विचार :) मैं इस सवाल के बारे में https://twitter.com/CocoaPodsOrg से ट्वीट करूंगा ।

Comments

मैं इसे भी प्रतिध्वनित करूँगा। आप अपने अन्य डेवलपर्स के बिना कोकोआ पॉड्स का उपयोग कर सकते हैं, पोड्स फोल्डर में चेक करके (हालांकि उन्हें चाहिए)। कोकोपोड्स सर्वव्यापी हो जाने के बाद, फली रत्नों के समान होगी, आप उन्हें उन्हीं मामलों में जांचेंगे, जिन्हें आप "वेंडर" रूबी रत्नों से करते हैं।

— बेन शहीरमैन

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

— एड्रियन

चेकआउट, निर्माण और रन सबसे महत्वपूर्ण विचार है। आप अपने निर्माण, और किसी भी बाहरी कारकों पर निर्भर बनाने की क्षमता क्यों बनाएंगे? मैं सभी पॉड्स में जांच करता हूं। आप सही पॉड्स को खोजने के लिए अन्य डेवलपर्स (या अपने भविष्य के स्वयं) को बचा सकते हैं। मैं किसी भी downsides उन्हें में जाँच करने के लिए नहीं देख रहा हूँ।

— n13

Answer 6

मैं हर चीज में जांच करता हूं। ( Pods/और Podfile.lock)

मैं रिपॉजिटरी को क्लोन करने में सक्षम होना चाहता हूं और जानता हूं कि सब कुछ बस काम करेगा जैसा कि पिछली बार मैंने ऐप का इस्तेमाल किया था।

मैं इसके बजाय अलग-अलग परिणाम वाले जोखिम के मामले में वेंडर की बात करता हूं, जो मणि के एक अलग संस्करण के कारण हो सकता है, या पॉड के भंडार में इतिहास को फिर से लिखना हो सकता है, आदि।

Comments

ऐसा करने के बारे में दूसरी अच्छी बात यह है कि एक अपडेट के बाद, आप चेक करने से पहले अंतर को देख सकते हैं और यह देख सकते हैं कि पॉड्स में कौन सी फाइलें बदल गईं।

— फन

इसके अतिरिक्त, आपके प्रोजेक्ट को आपके सभी डेवलपर्स को CocoaPods स्थापित करने की आवश्यकता नहीं है (जो कि यदि आप नियंत्रित करना चाहते हैं कि कौन / कैसे निर्भरताएं जोड़ी और अपडेट की गई हैं) एक अच्छी बात हो सकती है।

— टोनी अर्नोल्ड

Answer 7

इसका उत्तर सीधे कोकोपॉड डॉक्स में दिया गया है। आप " http://guides.cocoapods.org/using/cocoapods.html#should-i-ignore-the-pods-directory-in-source-control " देख सकते हैं

आपके पॉड्स फोल्डर में आप चेक करते हैं या नहीं यह आपके ऊपर है, क्योंकि वर्कफ्लो प्रोजेक्ट से प्रोजेक्ट में भिन्न होता है। हम अनुशंसा करते हैं कि आप पॉड्स निर्देशिका को स्रोत नियंत्रण में रखें, और इसे अपने .gitignore में न जोड़ें। लेकिन अंततः यह निर्णय आप पर निर्भर है:

फली निर्देशिका में जाँच के लाभ

• रेपो क्लोनिंग के बाद, मशीन पर कोकोआपॉड स्थापित किए बिना भी परियोजना तुरंत निर्माण और चला सकती है। पॉड इंस्टॉल को चलाने की कोई आवश्यकता नहीं है, और कोई इंटरनेट कनेक्शन आवश्यक नहीं है।
• पॉड कलाकृतियों (कोड / लाइब्रेरी) हमेशा उपलब्ध हैं, भले ही एक पॉड (जैसे GitHub) का स्रोत नीचे जाना था।
• रेपो क्लोनिंग के बाद मूल स्थापना में पॉड कलाकृतियों को समान होने की गारंटी है।

फली निर्देशिका की अनदेखी के लाभ

• स्रोत नियंत्रण रेपो छोटा होगा और कम जगह लेगा।

• जब तक सभी पॉड्स के लिए स्रोत (जैसे GitHub) उपलब्ध हैं, कोकोआपोड्स आमतौर पर एक ही स्थापना को फिर से बनाने में सक्षम हैं। (तकनीकी रूप से इस बात की कोई गारंटी नहीं है कि पॉडफाइल में कमिटेड SHA का उपयोग नहीं करने पर पॉड इंस्टॉल को चलाने और समान कलाकृतियों को फिर से बनाना होगा। पॉडफाइल में ज़िप फ़ाइलों का उपयोग करते समय यह विशेष रूप से सच है।)

• स्रोत नियंत्रण संचालन करते समय, विभिन्न पॉड संस्करणों के साथ शाखाओं को मर्ज करने जैसी किसी भी समस्या से निपटने के लिए कोई संघर्ष नहीं होगा।

आप पॉड्स डायरेक्टरी में चेक करते हैं या नहीं, पॉडफाइल और पॉडफाइल.लॉक को हमेशा वर्जन कंट्रोल में रखा जाना चाहिए।

Answer 8

मैं डेवलपर्स के शिविर में हूं, जो पुस्तकालयों में जांच नहीं करते हैं, यह मानते हुए कि हमारे पास किसी अन्य स्थान पर एक अच्छी प्रतिलिपि उपलब्ध है। इसलिए, मेरे .gitignore में मैं CocoaPods के लिए विशिष्ट निम्नलिखित लाइनें शामिल करता हूं:

Pods/
#Podfile.lock  # changed my mind on Podfile.lock

फिर मैं यह सुनिश्चित करता हूं कि हमारे पास सुरक्षित स्थान पर पुस्तकालयों की एक प्रति है। इसके बजाय (गलत-) निर्भरता को संकलित करने के लिए एक परियोजना के कोड भंडार का उपयोग करें (संकलित या नहीं) मुझे लगता है कि ऐसा करने का सबसे अच्छा तरीका संग्रह बनाता है। यदि आप अपने बिल्ड (जैसे जेनकिन्स) के लिए CI सर्वर का उपयोग करते हैं, तो आप स्थायी रूप से आपके लिए महत्वपूर्ण किसी भी बिल्ड को संग्रहीत कर सकते हैं। यदि आप अपना सारा उत्पादन अपने स्थानीय Xcode में करते हैं, तो अपने प्रोजेक्ट के संग्रह को किसी भी बिल्ड के लिए लेने की आदत डालें, जिसे आपको रखने की आवश्यकता है। कुछ इस तरह: 1. उत्पाद -> पुरालेख

1. वितरित करें ... iOS ऐप स्टोर में सहेजें / एंटरप्राइज या एड-हॉक परिनियोजन के लिए सहेजें / आपके पास क्या है

2. फाइंडर में अपने प्रोजेक्ट फ़ोल्डर को प्रकट करें

3. राइट क्लिक करें और कंप्रेस करें "जोप्रोप्रोजेक्ट"

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

अद्यतन: मैंने इस पर अपना विचार बदल दिया है और अब Podfile.lockस्रोत नियंत्रण के लिए प्रतिबद्ध हूं । हालाँकि, मुझे अभी भी विश्वास है कि फली खुद कलाकृतियों का निर्माण करती है और इसे अन्य नियंत्रण विधि जैसे कि आपके CI सर्वर या एक संग्रह प्रक्रिया के माध्यम से प्रबंधित किया जाना चाहिए जैसे कि मैं ऊपर वर्णित करता हूं।

Comments

Cocoapods विशेष रूप से इसमें चेक करने की सलाह देते हैं Podfile.lock: docs.cocoapods.org/guides/working_with_teams.html

— cbowns

दिलचस्प। चूंकि Podfile.lockस्थानीय फली के रास्तों में सेंध लगाई जाती है, इसलिए मैंने इसे संस्करण नियंत्रण में जोड़ने पर विचार नहीं किया था। हालाँकि, अब मैं इसके बारे में सोचता हूं, यह मेरे द्वारा किए गए स्थानीय परिवर्तनों से अलग नहीं है, Podfileलेकिन कभी भी प्रतिबद्ध नहीं है। इस पर ध्यान दिलाने के लिए धन्यवाद।

— एलेक्स नौडा

क्या टीमों के लिंक के साथ काम करना बदल गया है? इसमें Podfile.lockफ़ाइल के बारे में कुछ नहीं बताया गया है।

— इंध।

@ ing0 मुझे लगता है कि नई कड़ी है इस एक

— फाई

Podfile.lock में जाँच का लाभ यह है कि यदि आपके किसी पॉड या उनकी निर्भरता को अपग्रेड किया गया है तो यह स्पष्ट है।

— टिम पॉटर

Answer 9

मैं और Podsसाथ निर्देशिका करना पसंद करते हैंPodfilePodfile.lock यह सुनिश्चित करने के लिए कि मेरी टीम में कोई भी कभी भी स्रोत की जांच कर सकता है और उन्हें इसे काम करने के लिए किसी भी चीज के बारे में चिंता करने या अतिरिक्त सामान करने की आवश्यकता नहीं है।

यह ऐसे परिदृश्य में भी मदद करता है, जहाँ आपने पॉड्स में से किसी एक के अंदर बग को ठीक किया है या अपनी आवश्यकताओं के अनुसार कुछ व्यवहार को संशोधित किया है, लेकिन ये बदलाव अन्य मशीनों पर उपलब्ध नहीं होंगे यदि वे प्रतिबद्ध नहीं हैं।

और अनावश्यक निर्देशिकाओं को अनदेखा करना:

xcuserdata/

Answer 10

मुझे कहना होगा, मैं रिपॉजिटरी को पोड्स कमिट करने का प्रशंसक हूं। पहले से बताए गए एक लिंक के बाद आपको पॉड्स की अनुमति देने के लिए iOS के लिए अपने Xcode प्रोजेक्ट्स को प्राप्त करने के लिए एक अच्छी .gitignore फ़ाइल मिलेगी, लेकिन अगर आप चाहें तो उन्हें आसानी से बाहर करने के लिए भी: https://github.com/github/gitignore/ ब्लॉब / मास्टर / उद्देश्य-C.gitignore

पॉड्स को रिपॉजिटरी में शामिल करने का प्रशंसक होने का मेरा तर्क एक मौलिक कारण से है, जिस पर किसी का ध्यान नहीं जा रहा है, एक पुस्तकालय जो हमारी परियोजना पर निर्भर है, अचानक वेब से हटा दिए जाने पर क्या होता है?

• हो सकता है कि मेजबान यह तय करे कि वे अब अपने गीथहब खाते को खुला नहीं रखना चाहते हैं, यदि पुस्तकालय को कई साल पुराना (उदाहरण के लिए 5 वर्ष से अधिक पुराना) कहा जाता है तो क्या होता है एक उच्च जोखिम परियोजना के स्रोत पर उपलब्ध नहीं हो सकता है
• इसके अलावा एक और बिंदु, अगर रिपॉजिटरी में URL बदल जाए तो क्या होगा? आइए कहते हैं कि व्यक्ति अपने GitHub खाते से पोड की सेवा कर रहा है, एक अलग हैंडल के तहत खुद का प्रतिनिधित्व करने का फैसला करता है - आपके पॉड्स URL टूटने वाले हैं।
• अंत में एक और बात। कहो अगर तुम मेरे जैसे एक डेवलपर हो जो देशों के बीच उड़ान पर बहुत कोडिंग करता है। मैं 'मास्टर' शाखा पर एक त्वरित पुल करता हूं, उस शाखा पर एक पॉड स्थापित करता हूं, जबकि हवाई अड्डे पर बैठकर खुद को आगामी 8 घंटे की उड़ान के लिए सेट किया जाता है। मुझे अपनी उड़ान में 3 घंटे मिलते हैं, और महसूस होता है कि मुझे दूसरी शाखा में जाने की आवश्यकता है .... 'डीओएच' - लापता पॉड जानकारी जो केवल 'मास्टर' शाखा पर उपलब्ध है।

NB ... कृपया ध्यान दें कि विकास के लिए 'मास्टर' शाखा सिर्फ उदाहरण के लिए है, जाहिर है कि संस्करण नियंत्रण प्रणालियों में 'मास्टर' शाखाएं, किसी भी समय साफ और तैनात / निर्माण योग्य होनी चाहिए

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

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

Comments

यह "क्या मैं स्रोत नियंत्रण में अपनी निर्भरता की जाँच करता हूँ" का सबसे अच्छा जवाब है। सबसे पहले, आप अपने तर्क के लिए एक वास्तविक ठोस, जोखिम-आधारित, व्यावसायिक औचित्य की व्याख्या करते हैं। दूसरे, आप सभी को याद दिलाते हैं कि दिन के अंत में, सबसे अच्छा समाधान जो कुछ भी काम मिलता है और लोगों को एक साथ काम करना होता है। आप धर्म को समीकरण से हटा दें। अच्छी नौकरी!

— ब्रैंडन

Answer 11

अंत में आप पर निर्भर है कि आप क्या तरीका अपनाते हैं।

यह वही है जो कोकोपोड्स टीम इसके बारे में सोचती है:

आपके पॉड्स फोल्डर में आप चेक करते हैं या नहीं, यह आप पर निर्भर है, क्योंकि वर्कफ्लो प्रोजेक्ट से प्रोजेक्ट में भिन्न होता है। हम अनुशंसा करते हैं कि आप पॉड्स निर्देशिका को स्रोत नियंत्रण में रखें, और इसे अपने .gitignore में न जोड़ें। लेकिन अंततः यह निर्णय आप पर निर्भर है।

व्यक्तिगत रूप से मैं पॉड्स को बाहर रखना चाहूंगा, अगर मैं नोड या बोवर_काउंटर का उपयोग कर रहा हूं तो अगर मैं बोवर का उपयोग कर रहा हूं तो नोड_मॉड्यूल्स । यह लगभग किसी भी डिपेंडेंसी मैनेजर के लिए लागू होता है, और गिट सबमॉड्यूल के पीछे दर्शन होता है ।

हालांकि कभी-कभी ऐसा होता है कि आप एक निश्चित निर्भरता की अत्याधुनिकता के बारे में वास्तव में निश्चित होना चाहते हैं , इस तरह से आप अपनी परियोजना के भीतर निर्भरता को ले जा रहे हैं। बेशक, कई कमियां हैं जो यदि आप ऐसा करते हैं तो लागू होते हैं, लेकिन चिंता केवल कोकोपॉड्स पर ही लागू नहीं होती है, जो किसी भी डिपेंडेंसी मैनेजर पर लागू होती हैं।

नीचे Cocoapods टीम द्वारा किए गए एक अच्छे पेशेवरों / विपक्ष की सूची है, और पहले उल्लेखित उद्धरण का पूरा पाठ है।

कोकोपोड्स टीम: क्या मुझे पॉड्स निर्देशिका को स्रोत नियंत्रण में जांचना चाहिए?

Answer 12

यह निर्भर करता है, व्यक्तिगत रूप से:

क्यों फली को रेपो (स्रोत नियंत्रण के तहत) का हिस्सा होना चाहिए और इसे नजरअंदाज नहीं किया जाना चाहिए

• स्रोत समान है
• आप इसे ठीक वैसे ही बना सकते हैं जैसे कि (कोकोपोड्स के बिना भी)
• अगर कोई पॉड डिलीट हो जाता है, तब भी हमारे पास इसकी कॉपी है (हां, ऐसा हो सकता है और ऐसा हुआ है। एक पुराने प्रोजेक्ट में, जहां आप बस एक छोटा सा बदलाव चाहते हैं, आपको एक नई लाइब्रेरी को लागू करने की भी आवश्यकता होगी, जो निर्माण के लिए भी सक्षम हो)।
• pods.xcodeprojसेटिंग्स स्रोत नियंत्रण का भी हिस्सा हैं। इसका मतलब यह है कि यदि आपके पास परियोजना है swift 4, लेकिन कुछ पॉड्स में होना चाहिए swift 3.2क्योंकि वे अभी तक अपडेट नहीं किए गए हैं, तो ये सेटिंग्स सहेज ली जाएंगी। अन्यथा रेपो का क्लोन बनाने वाला त्रुटियों के साथ समाप्त हो जाएगा।
• आप हमेशा प्रोजेक्ट से पॉड्स को हटा सकते हैं और चला pod installसकते हैं, इसके विपरीत नहीं किया जा सकता है।
• यहां तक ​​कि कोकोपोड्स के लेखक भी इसकी सलाह देते हैं।

कुछ विपक्ष: बड़ा भंडार, भ्रामक अंतर (मुख्य रूप से टीम के सदस्यों के लिए), संभवतः अधिक संघर्ष।

Answer 13

मेरे लिए, सबसे बड़ी चिंता का विषय भविष्य में आपके स्रोत का प्रमाण है। यदि आप अपनी परियोजना को कुछ समय तक चलने की योजना बनाते हैं और कोकोआपोड्स कभी भी चले जाते हैं या पॉड्स में से एक का स्रोत नीचे चला जाता है, तो आप आर्क से नए सिरे से निर्माण करने की कोशिश कर रहे हैं।

यह आवधिक पूर्ण स्रोत अभिलेखों के साथ कम किया जा सकता है।

Answer 14

फली में जाँच करें।

मुझे लगता है कि यह सॉफ्टवेयर विकास का एक सिद्धांत होना चाहिए

• सभी बिल्ड को प्रतिलिपि प्रस्तुत करने योग्य होना चाहिए
• बिल्ड सुनिश्चित करने का एकमात्र तरीका प्रतिलिपि प्रस्तुत करने योग्य है सभी निर्भरता के नियंत्रण में होना; सभी निर्भरता में जाँच इसलिए जरूरी है।
• खरोंच से शुरू होने वाला एक नया डेवलपर आपकी परियोजना की जांच करने और काम शुरू करने में सक्षम होगा।

क्यों?

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

अब, वास्तविक रूप से, आप वास्तव में सभी निर्भरताओं में जांच नहीं कर सकते। आप उस मशीन की एक छवि की जांच नहीं कर सकते हैं जिसे आपने बिल्ड बनाने के लिए उपयोग किया था; आप संकलक के सटीक संस्करण में जाँच नहीं कर सकते। और इसी तरह। यथार्थवादी सीमाएँ हैं। लेकिन आप सभी में जाँच कर सकते हैं - ऐसा नहीं करना आपके जीवन को कठिन बनाता है। और हम ऐसा नहीं चाहते हैं।

अंतिम शब्द: फली कलाकृतियों का निर्माण नहीं कर रहे हैं। बिल्ड कलाकृतियां हैं जो आपके बिल्ड से उत्पन्न होती हैं। आपका निर्माण पॉड्स का उपयोग करता है, उन्हें उत्पन्न नहीं करता है। मुझे यकीन भी नहीं है कि इस पर बहस क्यों होनी है।

Answer 15

संस्करण नियंत्रण (महत्व के व्यक्तिपरक क्रम में) की जाँच नहीं करने के पेशेवरों Pods/:

1. बहुत आसान है कमिट्स मर्ज करना, और कोड की समीक्षा करना अलग है। मर्जिंग कोड बेस में समस्याओं का एक आम स्रोत है, और यह आपको केवल उन चीजों पर ध्यान केंद्रित करने की अनुमति देता है जो प्रासंगिक हैं।
2. कुछ यादृच्छिक योगदानकर्ता के लिए निर्भरता को स्वयं संपादित करना और उन परिवर्तनों की जांच करना असंभव है, जो उन्हें कभी नहीं करना चाहिए (और फिर यह पहचानना मुश्किल होगा कि क्या अंतर बड़े पैमाने पर है)। भविष्य पर निर्भरता का संपादन बहुत बुरा अभ्यास हैpod install में परिवर्तनों को कर सकता है।
3. Podfileऔर Pods/निर्देशिका के बीच विसंगतियां टीम के साथियों के बीच तेज पाई जाती हैं। यदि आप Pods/उदाहरण के लिए चेक इन करते हैं और संस्करण में अपडेट करते हैं Podfile, लेकिन pod installपरिवर्तनों को चलाने या जांचना भूल जाते हैं Pods/, तो आपके पास विसंगति के स्रोत को नोट करने में बहुत कठिन समय होगा। अगर Pods/इसमें जाँच नहीं की गई है, तो आपको हमेशा pod installवैसे भी चलने की आवश्यकता है ।
4. छोटे रेपो आकार। एक छोटा बाइट फुटप्रिंट होना अच्छा है, लेकिन यह भव्य योजना में ज्यादा मायने नहीं रखता है। इससे भी महत्वपूर्ण बात: रेपो में अधिक चीजें होने से आपका संज्ञानात्मक भार भी बढ़ता है। रेपो में चीजें होने का कोई कारण नहीं है जिसे आपको नहीं देखना चाहिए। कोड (कार्यान्वयन) में नहीं, यह जानने के लिए प्रलेखन (अमूर्त) का संदर्भ लें।
5. यह समझने में आसान है कि कोई कितना योगदान देता है (क्योंकि कोड की उनकी पंक्तियों ने योगदान दिया है, इसमें वे निर्भरताएं शामिल नहीं होंगी जो उन्होंने नहीं लिखी थीं)
6. JARफ़ाइलें, .venv/(आभासी वातावरण), और node_modules/संस्करण नियंत्रण में कभी शामिल नहीं हैं। यदि हम सवाल के बारे में पूरी तरह से अज्ञेय थे, तो जाँच नहीं करना Podsमिसाल के आधार पर डिफ़ॉल्ट होगा।

में जाँच नहीं की विपक्षPods/

1. आपको pod installशाखाओं को स्विच करते समय चलाना चाहिए , या कमिट करना चाहिए ।
2. आप केवल रिपॉजिटरी को क्लोन करके एक प्रोजेक्ट नहीं चला सकते हैं। आपको पॉड टूल इंस्टॉल करना होगा, फिर रन करना होगा pod install।
3. आपके पास चलाने के लिए एक इंटरनेट कनेक्शन होना चाहिए pod install, और पॉड्स का स्रोत उपलब्ध होना चाहिए।
4. अगर एक निर्भरता का मालिक उनके पैकेज को हटा देता है, तो आप मुसीबत में हैं।

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

Answer 16

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

Answer 17

TL; DR: जब आप Pods/फ़ोल्डर ट्रैक करते हैं , तो प्रोजेक्ट को चुनना आसान होता है। जब आप इसे ट्रैक नहीं करते हैं, तो जब आप किसी टीम में काम करते हैं, तो उसमें सुधार करना आसान होता है।

हालांकि कोकोपोड्स संगठन हमें Pods/निर्देशिका को ट्रैक करने के लिए प्रोत्साहित करते हैं , वे कहते हैं कि यह निर्णय लेने और न करने के लिए देवों पर निर्भर है कि वे इन पेशेवरों और विपक्षों के आधार पर करें:  http://guides.cocoapods.org/use/use/cocoapod.net.html # चाहिए-ए-चेक--फली-निर्देशिका-में-स्रोत नियंत्रण

व्यक्तिगत रूप से, मैं आमतौर पर Pods/फ़ोल्डर को केवल उन परियोजनाओं के लिए ट्रैक करता हूं जो मैं कुछ समय के लिए काम नहीं करूंगा। इस तरह से कोई भी डेवलपर जल्दी से इसे उठा सकता है और कोकोपोड्स के उचित संस्करण का उपयोग करके काम जारी रख सकता है।

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

इसके अलावा, जब Pods/निर्देशिका को ट्रैक किया जा रहा है , तो सभी देवों को एक ही संस्करण को कोकोपोड्स का उपयोग करना पड़ता है ताकि इसे हर बार दर्जनों फाइलें बदलने से रोकने के लिए हम pod installएक पॉड जोड़ने / निकालने के लिए दौड़ें ।

निचला रेखा : जब आप Pods/फ़ोल्डर को ट्रैक करते हैं , तो प्रोजेक्ट को चुनना आसान होता है। जब आप इसे ट्रैक नहीं करते हैं, तो इसे सुधारना आसान होता है।

Answer 18

यह संरचना के लिए एक अच्छा तरीका की तरह लगता है कि वास्तव में "पॉड्स" निर्देशिका एक गिट सबमॉड्यूल / अलग प्रोजेक्ट के रूप में होगी, यहाँ क्यों है।

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

• मैं कुछ भी करने के लिए प्रतिबद्ध नहीं होने के मुद्दे को देखता हूं, क्योंकि पुस्तकालय के मालिक व्यक्ति इसे किसी भी समय नीचे ले जा सकते हैं और आप अनिवार्य रूप से एसओएल हैं, यह भी हल करता है।

Answer 19

आपके पॉड्स फोल्डर में आप चेक करते हैं या नहीं, यह आप पर निर्भर है, क्योंकि वर्कफ्लो प्रोजेक्ट से प्रोजेक्ट में भिन्न होता है। हम अनुशंसा करते हैं कि आप पॉड्स निर्देशिका को स्रोत नियंत्रण में रखें, और इसे अपने .gitignore में न जोड़ें। लेकिन अंततः यह निर्णय आप पर निर्भर है:

फली निर्देशिका में जाँच के लाभ

1. रेपो क्लोनिंग के बाद, मशीन पर कोकोआपॉड स्थापित किए बिना भी परियोजना तुरंत निर्माण और चला सकती है। पॉड इंस्टॉल को चलाने की कोई आवश्यकता नहीं है, और कोई इंटरनेट कनेक्शन आवश्यक नहीं है।
2. पॉड कलाकृतियों (कोड / लाइब्रेरी) हमेशा उपलब्ध हैं, भले ही एक पॉड (जैसे GitHub) का स्रोत नीचे जाना था।
3. रेपो क्लोनिंग के बाद मूल स्थापना में पॉड कलाकृतियों को समान होने की गारंटी है।

फली निर्देशिका की अनदेखी के लाभ

1. स्रोत नियंत्रण रेपो छोटा होगा और कम जगह लेगा। जब तक सभी पॉड्स के लिए स्रोत (जैसे GitHub) उपलब्ध हैं, कोकोआपोड्स आम तौर पर एक ही इंस्टॉलेशन को फिर से बनाने में सक्षम हैं। (तकनीकी रूप से इस बात की कोई गारंटी नहीं है कि पॉडफाइल में एक प्रतिबद्ध SHA का उपयोग करते समय पॉड इंस्टाल चलाने पर समान कलाकृतियों को लाना और फिर से बनाना होगा। यह विशेष रूप से सच है जब पॉडफाइल में ज़िप फ़ाइलों का उपयोग किया जाता है।)
2. स्रोत नियंत्रण संचालन करते समय, विभिन्न पॉड संस्करणों के साथ शाखाओं को मर्ज करने जैसी किसी भी समस्या से निपटने के लिए कोई संघर्ष नहीं होगा। आप पॉड्स डायरेक्टरी में चेक करते हैं या नहीं, पॉडफाइल और पॉडफाइल.लॉक को हमेशा वर्जन कंट्रोल में रखा जाना चाहिए।

Comments

: आप किसी भी संदेह के लिए इस लिंक का उपयोग कर सकते guides.cocoapods.org/using/...

— सौरभ Mahna