objective c - यदि आप CocoaPods का उपयोग कर रहे हैं तो आपके.gitignore में क्या जाता है?




objective-c (12)

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

मैंने इसे एक निजी प्रोजेक्ट पर आज़माया: मेरी पॉडफाइल में Kiwi निर्भरता को जोड़ा, pod install CocoaPodsTest.xcodeproj और pod install CocoaPodsTest.xcodeproj किया, यह बहुत अच्छा काम करता था।

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


.gitignore फ़ाइल

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

Pods निर्देशिका में जांच ( Benefits )

एक्सकोड / आईओएस अनुकूल गिट अनदेखा, मैक ओएस सिस्टम फाइलों, एक्सकोड, बिल्ड, अन्य भंडार और बैकअप छोड़ना।

.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/

पॉड्स निर्देशिका को अनदेखा करना ( Benefits )

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

# Cocoapods
Pods/

चाहे आप Pods निर्देशिका में जांचें या नहीं, Podfile और Podfile.lock हमेशा संस्करण नियंत्रण के तहत रखा जाना चाहिए।

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


Pods में जांचें।

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

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

क्यूं कर?

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

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

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


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

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

Pods निर्देशिका में जांच के लाभ

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

Pods निर्देशिका को अनदेखा करने के लाभ

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

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

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

चाहे आप Pods निर्देशिका में जांचें या नहीं, Podfile और Podfile.lock हमेशा संस्करण नियंत्रण के तहत रखा जाना चाहिए।


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

Pods निर्देशिका में जांच के लाभ

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

Pods निर्देशिका को अनदेखा करने के लाभ

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

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

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


मैं गिटहब के उद्देश्य-सी गिटिनोरोर का उपयोग करने की सलाह देता हूं । विस्तार से, सर्वोत्तम प्रथाएं हैं:

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

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

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

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

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

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

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

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

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

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


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

यदि यह हमारे स्वयं का ऐप था, तो शायद मैं पॉड्स निर्देशिका को तब तक बाहर कर दूंगा जब तक कि मैं थोड़ी देर के लिए इस पर काम नहीं करूँगा।

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


मैं सबकुछ जांचता हूं। ( Pods/ और Podfile.lock ।)

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

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


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

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

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

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


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

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


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





cocoapods