ฉันทำการพัฒนา iOS มาสองสามเดือนแล้วและเพิ่งเรียนรู้เกี่ยวกับห้องสมุดCocoaPods ที่มีแนวโน้มสำหรับการจัดการการพึ่งพา

ฉันลองใช้กับโปรเจ็กต์ส่วนตัว: เพิ่มการพึ่งพาKiwiใน Podfile ของฉันวิ่งpod install CocoaPodsTest.xcodeprojและvoilaมันใช้งานได้ดี

สิ่งเดียวที่ฉันสงสัยคือ: ฉันจะเช็คอินอะไรและฉันจะเพิกเฉยต่อการควบคุมเวอร์ชันได้อย่างไร ดูเหมือนชัดเจนว่าฉันต้องการตรวจสอบใน Podfile เองและอาจเป็นไฟล์. xcworkspace ด้วยเช่นกัน แต่ฉันไม่สนใจไดเรกทอรี Pods /? มีไฟล์อื่น ๆ ที่จะถูกสร้างขึ้นตามถนน (เมื่อฉันเพิ่มการอ้างอิงอื่น ๆ ) ที่ฉันควรเพิ่มใน. gitignore ของฉันด้วยหรือไม่

ส่วนตัวฉันไม่ได้ตรวจสอบในไดเรกทอรี Pods & เนื้อหา ฉันไม่สามารถพูดได้ว่าฉันใช้เวลานานในการพิจารณาความหมาย แต่เหตุผลของฉันคือ:

Podfile อ้างอิงถึงแท็กเฉพาะหรือการกระทำของแต่ละการพึ่งพาดังนั้น Pods เองสามารถสร้างขึ้นได้จาก podfile ดังนั้นพวกมันก็เหมือนผลิตภัณฑ์บิลด์กลางมากกว่าแหล่งและดังนั้นจึงไม่จำเป็นต้องควบคุมเวอร์ชันในโครงการของฉัน

ฉันยอมรับไดเรกทอรี Pods ของฉัน ฉันไม่เห็นด้วยว่าไดเรกทอรี Pods เป็นสิ่งประดิษฐ์ อันที่จริงฉันก็บอกว่ามันไม่แน่นอน เป็นส่วนหนึ่งของแหล่งที่มาของแอปพลิเคชันของคุณ: มันจะไม่สร้างหากไม่มี!

เป็นเรื่องง่ายกว่าที่จะนึกถึง CocoaPods ในฐานะเครื่องมือสำหรับนักพัฒนาแทนที่จะเป็นเครื่องมือสร้าง มันไม่ได้สร้างโครงการของคุณเพียง แต่โคลนและติดตั้งการพึ่งพาของคุณ ไม่จำเป็นต้องติดตั้ง CocoaPods เพื่อให้สามารถสร้างโครงการของคุณได้

ด้วยการทำให้ CocoaPods เป็นที่พึ่งของงานสร้างของคุณตอนนี้คุณต้องทำให้แน่ใจว่ามันสามารถใช้งานได้ทุกที่ที่คุณอาจจำเป็นต้องสร้างโครงการของคุณ ... ผู้ดูแลระบบของทีมต้องการเซิร์ฟเวอร์ CI ของคุณต้องการ ตามกฎแล้วคุณควรจะสามารถโคลนแหล่งเก็บข้อมูลของคุณและสร้างได้โดยไม่ต้องใช้ความพยายามใด ๆ เพิ่มเติม

การไม่ทำสารบบ Pods ของคุณจะทำให้คุณปวดหัวอย่างมากหากคุณเปลี่ยนสาขาเป็นประจำ ตอนนี้คุณต้องทำการติดตั้งพ็อดทุกครั้งที่คุณสลับสาขาเพื่อให้แน่ใจว่าการอ้างอิงของคุณนั้นถูกต้อง นี่อาจเป็นเรื่องยุ่งยากน้อยลงเนื่องจากการพึ่งพาของคุณมีเสถียรภาพ แต่ในช่วงแรกของโครงการนี่เป็นช่วงเวลาที่ยิ่งใหญ่

ดังนั้นฉันจะเพิกเฉยอะไร ไม่มีอะไร Podfile ไฟล์ล็อคและไดเรกทอรี Pod ทั้งหมดได้กระทำ เชื่อฉันสิมันจะช่วยให้คุณไม่ต้องยุ่งยากมากนัก ข้อเสียคืออะไร? ธุรกรรมซื้อคืนที่ใหญ่กว่าเล็กน้อย? ไม่ใช่จุดจบของโลก

ผมแนะนำให้ใช้GitHub ของวัตถุประสงค์ C-gitignore ในรายละเอียดการปฏิบัติที่ดีที่สุดคือ:

• Podfile ต้องเสมอจะอยู่ภายใต้การควบคุมแหล่ง
• Podfile.lock ต้องเสมอจะอยู่ภายใต้การควบคุมแหล่ง
• พื้นที่ทำงานที่สร้างโดย CocoaPods ควรเก็บไว้ภายใต้การควบคุมของแหล่งที่มา
• Pod ใด ๆ ที่อ้างอิงกับ:pathตัวเลือกควรเก็บไว้ภายใต้การควบคุมของแหล่งที่มา
• ./Podsโฟลเดอร์สามารถถูกเก็บไว้ภายใต้การควบคุมแหล่งที่มา

สำหรับข้อมูลเพิ่มเติมสามารถดูที่คู่มืออย่างเป็นทางการ

แหล่งที่มา: ฉันเป็นสมาชิกคนหนึ่งของทีมหลัก CocoaPods เช่น @alloy

แม้ว่าโฟลเดอร์ Pods เป็นสิ่งประดิษฐ์บิลด์มีเหตุผลที่คุณอาจต้องพิจารณาในขณะที่ตัดสินใจว่าจะอยู่ภายใต้การควบคุมของแหล่งข้อมูล:

• CocoaPods ไม่ใช่ผู้จัดการแพ็คเกจดังนั้นผู้แต่งสามารถลบแหล่งต้นฉบับของไลบรารีออกได้ในอนาคต
• หากโฟลเดอร์ Pods รวมอยู่ในการควบคุมแหล่งข้อมูลไม่จำเป็นต้องติดตั้ง CocoaPods เพื่อเรียกใช้โครงการเนื่องจากการชำระเงินจะเพียงพอ
• CocoaPods ยังคงทำงานอยู่และมีตัวเลือกที่ไม่นำไปสู่ผลลัพธ์เดียวกันเสมอ (ตัวอย่างเช่น:headและ:gitตัวเลือกปัจจุบันไม่ได้ใช้คอมมิทที่เก็บไว้ในPodfile.lock)
• มีจุดของความล้มเหลวน้อยลงถ้าคุณอาจกลับมาทำงานในโครงการหลังจากระยะเวลาปานกลาง / ยาว

ไฟล์. gitignore

ไม่มีคำตอบที่นำเสนอจริง.gitignoreดังนั้นนี่คือสองรสชาติ

การตรวจสอบในไดเรกทอรี Pods ( ประโยชน์ )

Git ที่เป็นมิตรกับ Xcode / iOS ข้ามไฟล์ระบบ 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/

ละเว้นไดเรกทอรี Pods ( ประโยชน์ )

.gitignore: (ต่อท้ายรายการก่อนหน้า)

# Cocoapods
Pods/

ไม่ว่าคุณจะเช็คอินในไดเรกทอรี Pods หรือไม่ก็ตาม Podfile และ Podfile.lock ควรเก็บไว้ภายใต้การควบคุมเวอร์ชันเสมอ

หากPodsไม่ได้เช็คอินคุณPodfileควรขอหมายเลขรุ่นที่ชัดเจนสำหรับ Cocoapod แต่ละรายการ อภิปราย Cocoapods.org ที่นี่

โดยทั่วไปฉันทำงานกับแอปของลูกค้า ในกรณีนี้ฉันเพิ่มไดเรกทอรี Pods ลงใน repo ด้วยเพื่อให้แน่ใจว่าในเวลาใดก็ตามนักพัฒนาสามารถทำการเช็คเอาต์และสร้างและเรียกใช้

หากเป็นแอปของเราเองฉันอาจจะไม่รวมไดเรกทอรี Pods จนกว่าฉันจะไม่ทำงานในขณะนั้น

อันที่จริงผมต้องสรุปผมไม่อาจจะเป็นคนที่ดีที่สุดที่จะตอบคำถามของคุณกับมุมมองของผู้ใช้บริสุทธิ์ :) ฉันจะ tweet เกี่ยวกับคำถามนี้จากhttps://twitter.com/CocoaPodsOrg

ฉันเช็คอินทุกอย่าง ( Pods/และPodfile.lock.)

ฉันต้องการโคลนที่เก็บและรู้ว่าทุกอย่างจะทำงานได้เหมือนเดิมเมื่อฉันใช้แอพครั้งสุดท้าย

ฉันต้องการขายสินค้ามากกว่าความเสี่ยงที่มีผลลัพธ์ที่แตกต่างกันซึ่งอาจเกิดจากอัญมณีรุ่นอื่นหรือมีคนเขียนประวัติศาสตร์ในที่เก็บของ Pod เป็นต้น

คำตอบสำหรับเรื่องนี้จะได้รับโดยตรงใน Cocoapod docs คุณอาจดู " http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control "

ไม่ว่าคุณจะเช็คอินในโฟลเดอร์ Pods ขึ้นอยู่กับคุณหรือไม่ก็ตามเนื่องจากเวิร์กโฟลว์นั้นแตกต่างกันไปในแต่ละโปรเจ็กต์ เราขอแนะนำให้คุณเก็บไดเรกทอรี Pods ไว้ภายใต้การควบคุมของแหล่งที่มาและไม่ควรเพิ่มลงใน. gitignore ของคุณ แต่ท้ายที่สุดการตัดสินใจนี้ขึ้นอยู่กับคุณ:

ประโยชน์ของการตรวจสอบในไดเรกทอรี Pods

• หลังจากโคลน repo โครงการสามารถสร้างและเรียกใช้ได้ทันทีโดยไม่ต้องติดตั้ง CocoaPods บนเครื่อง ไม่จำเป็นต้องเรียกใช้การติดตั้งพ็อดและไม่จำเป็นต้องเชื่อมต่ออินเทอร์เน็ต
• Pod วัตถุ (รหัส / ไลบรารี) พร้อมใช้งานเสมอถึงแม้ว่าแหล่งที่มาของ Pod (เช่น GitHub) จะลงไป
• สิ่งประดิษฐ์ Pod รับประกันว่าจะเหมือนกันกับสิ่งที่อยู่ในการติดตั้งดั้งเดิมหลังจากโคลน repo

ประโยชน์ของการเพิกเฉยไดเรกทอรี Pods

• repo การควบคุมแหล่งที่มาจะมีขนาดเล็กลงและใช้พื้นที่น้อยลง

• ตราบใดที่แหล่งที่มา (เช่น GitHub) สำหรับพ็อดทั้งหมดนั้นมีอยู่ CocoaPods ก็สามารถสร้างการติดตั้งเดียวกันได้อีกครั้ง (ในทางเทคนิคไม่มีการรับประกันว่าการติดตั้งพ็อดที่กำลังเรียกใช้จะดึงและสร้างสิ่งประดิษฐ์ที่เหมือนกันเมื่อไม่ได้ใช้ SHA ที่ส่งมอบใน Podfile สิ่งนี้เป็นจริงโดยเฉพาะอย่างยิ่งเมื่อใช้ไฟล์ zip ใน Podfile)

• จะไม่มีข้อขัดแย้งใด ๆ เมื่อจัดการการดำเนินการควบคุมแหล่งที่มาเช่นการรวมสาขากับรุ่น Pod ที่แตกต่างกัน

ไม่ว่าคุณจะเช็คอินในไดเรกทอรี Pods หรือไม่ก็ตาม Podfile และ Podfile.lock ควรเก็บไว้ภายใต้การควบคุมเวอร์ชันเสมอ

ฉันอยู่ในค่ายนักพัฒนาซอฟต์แวร์ที่ไม่ได้เช็คอินห้องสมุดโดยสมมติว่าเรามีสำเนาที่ดีอยู่ในที่อื่น ดังนั้นใน. gitignore ของฉันฉันรวมบรรทัดต่อไปนี้เฉพาะกับ CocoaPods:

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

จากนั้นฉันตรวจสอบให้แน่ใจว่าเรามีสำเนาของห้องสมุดในที่ปลอดภัย แทนที่จะ (mis-) ใช้ที่เก็บรหัสของโครงการเพื่อเก็บการอ้างอิง (รวบรวมหรือไม่) ฉันคิดว่าวิธีที่ดีที่สุดในการทำเช่นนี้คือการสร้างที่เก็บถาวร หากคุณใช้เซิร์ฟเวอร์ CI สำหรับงานสร้างของคุณ (เช่น Jenkins) คุณสามารถเก็บถาวรงานสร้างที่มีความสำคัญต่อคุณอย่างถาวร หากคุณผลิตงานสร้างทั้งหมดของคุณใน Xcode ในเครื่องของคุณสร้างนิสัยในการเก็บถาวรโครงการของคุณสำหรับงานสร้างที่คุณต้องการเก็บไว้ สิ่งที่ชอบ: 1. ผลิตภัณฑ์ -> เก็บถาวร

1. กระจาย ... ส่งไปยัง iOS App Store / Save for Enterprise หรือ Ad-hoc Deployment / คุณมีอะไรบ้าง

2. เปิดเผยโฟลเดอร์โครงการของคุณใน Finder

3. คลิกขวาและบีบอัด "AnythingProject"

สิ่งนี้ให้ภาพที่สร้างขึ้นของโครงการทั้งหมดรวมถึงการตั้งค่าโครงการและพื้นที่ทำงานทั้งหมดที่ใช้ในการสร้างแอปรวมถึงการแจกแจงแบบไบนารี (เช่น Sparkle, SDK ที่เป็นกรรมสิทธิ์เช่น TestFlight เป็นต้น) ไม่ว่าพวกเขาจะใช้ CocoaPods หรือไม่

อัปเดต:ฉันเปลี่ยนใจจากสิ่งนี้และตอนนี้ฉันได้กระทำการPodfile.lockควบคุมแหล่งที่มา อย่างไรก็ตามฉันยังเชื่อว่าตัวเองนั้นเป็นสิ่งก่อสร้างและควรจัดการเช่นภายนอกตัวควบคุมแหล่งข้อมูลผ่านวิธีอื่นเช่นเซิร์ฟเวอร์ CI ของคุณหรือกระบวนการเก็บถาวรอย่างที่ฉันอธิบายข้างต้น

ฉันต้องการคอมมิชชันที่ทำPodsไดเรกทอรีพร้อมPodfileและPodfile.lockเพื่อให้แน่ใจว่าทุกคนในทีมของฉันสามารถเช็คเอาต์แหล่งข้อมูลได้ทุกเวลาและพวกเขาไม่ต้องกังวลเกี่ยวกับสิ่งใด ๆ หรือทำสิ่งเพิ่มเติมเพื่อให้มันทำงานได้

นอกจากนี้ยังช่วยในสถานการณ์ที่คุณได้แก้ไขข้อผิดพลาดภายในหนึ่งฝักหรือแก้ไขพฤติกรรมบางอย่างตามความต้องการของคุณ แต่การเปลี่ยนแปลงเหล่านี้จะไม่สามารถใช้ได้ในเครื่องอื่น ๆ หากไม่ได้มุ่งมั่น

และเพื่อละเว้นไดเรกทอรีที่ไม่จำเป็น:

xcuserdata/

ฉันต้องบอกว่าฉันเป็นแฟนของการยอมรับ Pods ไปยังที่เก็บ การติดตามลิงก์ที่กล่าวถึงแล้วจะทำให้คุณมีไฟล์. gitignore ที่ดีเพื่อรับโปรเจ็กต์ Xcode ของคุณสำหรับ iOS เพื่ออนุญาตให้ Pods และสำหรับคุณที่จะแยกพวกเขาได้อย่างง่ายดายหากคุณต้องการ: https://github.com/github/gitignore/ หยด / Master / วัตถุประสงค์ C.gitignore

เหตุผลของฉันในการเป็นแฟนของการเพิ่ม Pods ลงในที่เก็บเป็นเหตุผลพื้นฐานอย่างหนึ่งที่ดูเหมือนว่าไม่มีใครจะหยิบขึ้นมาจะเกิดอะไรขึ้นถ้าห้องสมุดที่โครงการของเราพึ่งพานั้นถูกลบออกจากเว็บทันที?

• บางทีโฮสต์ตัดสินใจว่าพวกเขาไม่ต้องการเปิดบัญชี GitHub อีกต่อไปจะเกิดอะไรขึ้นถ้าห้องสมุดพูดว่าหลายปี (เช่นอายุมากกว่า 5 ปีเป็นต้น) มีความเสี่ยงสูงโครงการอาจไม่สามารถหาแหล่งได้อีกต่อไป
• อีกประเด็นหนึ่งจะเกิดอะไรขึ้นถ้า URL ไปยังที่เก็บข้อมูลเปลี่ยนแปลง? ให้บอกว่าคนที่ให้บริการ Pod จากบัญชี GitHub ของพวกเขาตัดสินใจที่จะเป็นตัวแทนของตัวเองภายใต้หมายเลขอ้างอิงอื่น - URL ของ Pods ของคุณกำลังจะแตก
• ในที่สุดอีกจุดหนึ่ง พูดว่าถ้าคุณเป็นนักพัฒนาอย่างฉันที่เขียนโค้ดจำนวนมากเมื่ออยู่ในเที่ยวบินระหว่างประเทศ ฉันทำการดึงอย่างรวดเร็วในสาขา 'ปรมาจารย์' ทำการติดตั้งพ็อดที่สาขานั้นในขณะที่นั่งอยู่ในสนามบินและเตรียมพร้อมสำหรับการบินในอีก 8 ชั่วโมงข้างหน้า ฉันใช้เวลา 3 ชั่วโมงในการบินและรู้ว่าฉันต้องเปลี่ยนไปใช้สาขาอื่น .... 'DOH' - ข้อมูลพ็อดที่ขาดหายไปซึ่งมีเฉพาะในสาขา 'มาสเตอร์' เท่านั้น

หมายเหตุ ... โปรดทราบว่าสาขา 'ต้นแบบ' สำหรับการพัฒนาเป็นเพียงตัวอย่างเท่านั้น 'สาขาหลัก' ในระบบควบคุมเวอร์ชันควรมีการรักษาความสะอาดและสามารถปรับใช้ / สร้างได้ตลอดเวลา

ฉันคิดว่าจากสิ่งเหล่านี้สแนปชอตในที่เก็บรหัสของคุณนั้นดีกว่าการ จำกัด ขนาดของที่เก็บ และตามที่ได้กล่าวไปแล้วไฟล์ podfile.lock - ในขณะที่เวอร์ชันควบคุมจะให้ประวัติของรุ่น Pod ของคุณได้ดี

ในตอนท้ายของวันหากคุณมีกำหนดเวลาที่เร่งรีบงบประมาณที่ จำกัด เวลาเป็นสิ่งสำคัญ - เราจำเป็นต้องมีความคิดสร้างสรรค์เท่าที่จะเป็นไปได้และไม่ต้องเสียเวลากับอุดมการณ์ที่เข้มงวดและแทนที่จะใช้ชุดเครื่องมือเพื่อทำงานร่วมกัน - เพื่อทำให้ชีวิตของเราง่ายขึ้นมีประสิทธิภาพมากขึ้น

ท้ายที่สุดก็ขึ้นอยู่กับคุณว่าจะทำอย่างไร

นี่คือสิ่งที่ทีม Cocoapods คิดเกี่ยวกับมัน:

ไม่ว่าคุณจะเช็คอินในโฟลเดอร์ Pods ขึ้นอยู่กับคุณหรือไม่ก็ตามเนื่องจากเวิร์กโฟลว์นั้นแตกต่างกันไปในแต่ละโปรเจ็กต์ เราขอแนะนำให้คุณเก็บไดเรกทอรี Pods ไว้ภายใต้การควบคุมของแหล่งที่มาและไม่ควรเพิ่มลงใน. gitignore ของคุณ แต่ท้ายที่สุดการตัดสินใจนี้ขึ้นอยู่กับคุณ

ส่วนตัวผมต้องการที่จะให้ฝักออกเป็นnode_modulesถ้าฉันได้ใช้โหนดหรือbower_componentsถ้าฉันได้ใช้Bower สิ่งนี้ใช้กับผู้จัดการ Dependency เกือบทุกรายและเป็นปรัชญาของGit submodulesเช่นกัน

อย่างไรก็ตามมีบางครั้งที่คุณอาจต้องการแน่ใจเกี่ยวกับสถานะของการพึ่งพาที่แน่นอนในแบบที่คุณเป็นเจ้าของการพึ่งพาภายในโครงการของคุณ แน่นอนว่ามีข้อเสียหลายประการที่นำไปใช้หากคุณทำเช่นนั้น แต่ข้อกังวลไม่เพียง แต่นำไปใช้กับ Cocoapods เท่านั้นสิ่งเหล่านั้นจะมีผลกับผู้จัดการการพึ่งพาใด ๆ

ด้านล่างมีรายการข้อดี / ข้อเสียที่ดีทำโดยทีม Cocoapods และข้อความฉบับเต็มของข้อความที่กล่าวถึงก่อนหน้านี้

ทีม Cocoapods: ฉันควรตรวจสอบไดเรกทอรี Pods ลงในการควบคุมแหล่งที่มาหรือไม่?

มันขึ้นอยู่กับ:

เหตุใดฝักควรเป็นส่วนหนึ่งของ repo (ภายใต้การควบคุมแหล่ง) และไม่ควรละเว้น

• แหล่งที่มาเหมือนกัน
• คุณสามารถสร้างได้ทันทีตามที่เป็น(แม้ไม่มี cocoapods)
• แม้ว่าจะมีการลบพ็อด แต่เราก็ยังมีสำเนาอยู่(ใช่สามารถเกิดขึ้นได้และทำได้ในโครงการเก่าที่คุณต้องการการเปลี่ยนแปลงเพียงเล็กน้อยคุณต้องใช้ไลบรารี่ใหม่เพื่อให้สามารถสร้างได้
• pods.xcodeprojการตั้งค่าเป็นส่วนหนึ่งของการควบคุมแหล่งที่มาเช่นกัน ซึ่งหมายความว่าเช่นถ้าคุณมีโครงการswift 4แต่บางฝักต้องอยู่ในswift 3.2เนื่องจากยังไม่ได้อัปเดตการตั้งค่าเหล่านี้จะถูกบันทึกไว้ มิฉะนั้นคนที่ลอกแบบ repo ก็จะพบกับข้อผิดพลาด
• คุณสามารถลบพ็อดจากโครงการได้ตลอดเวลาและทำงานpod installไม่สามารถทำสิ่งที่ตรงกันข้ามได้
• แม้แต่ผู้เขียน Cocoapods ก็ยังแนะนำ

ข้อเสียบางประการ: พื้นที่เก็บข้อมูลขนาดใหญ่ขึ้นทำให้เกิดความสับสน

สำหรับฉันข้อกังวลที่ใหญ่ที่สุดคือการพิสูจน์แหล่งที่มาของคุณในอนาคต หากคุณวางแผนที่จะให้โครงการของคุณมีอายุการใช้งานสักพักหนึ่งและ CocoaPods จะหายไปหรือแหล่งที่มาของหนึ่งในพ็อดลดลงคุณจะโชคดีถ้าคุณพยายามสร้างสดใหม่จากที่เก็บถาวร

สิ่งนี้สามารถบรรเทาลงได้ด้วยการเก็บถาวรซอร์สเต็มเป็นระยะ

ตรวจสอบใน Pods

ฉันคิดว่านี่ควรเป็นหลักสำคัญของการพัฒนาซอฟต์แวร์

• งานสร้างทั้งหมดจะต้องทำซ้ำได้
• วิธีเดียวที่จะทำให้แน่ใจว่าบิวด์สามารถทำซ้ำได้คือควบคุมการพึ่งพาทั้งหมด การตรวจสอบในการอ้างอิงทั้งหมดจึงต้อง
• นักพัฒนาใหม่ที่เริ่มต้นจากศูนย์จะสามารถตรวจสอบโครงการของคุณและเริ่มทำงานได้

ทำไม?

CocoaPods หรือไลบรารีภายนอกอื่น ๆ อาจเปลี่ยนแปลงซึ่งอาจทำให้สิ่งต่าง ๆ เสียหาย หรือพวกเขาอาจย้ายหรือถูกเปลี่ยนชื่อหรือถูกลบออกไปโดยสิ้นเชิง คุณไม่สามารถพึ่งพาอินเทอร์เน็ตในการจัดเก็บสิ่งต่าง ๆ สำหรับคุณ แล็ปท็อปของคุณอาจเสียชีวิตและมีข้อผิดพลาดร้ายแรงในการผลิตซึ่งจำเป็นต้องแก้ไข ผู้พัฒนาหลักอาจโดนรถบัสและผู้แทนของเขาจะต้องเริ่มต้นอย่างรวดเร็ว และฉันหวังว่าอันสุดท้ายเป็นตัวอย่างทางทฤษฎี แต่มันเกิดขึ้นจริงเมื่อเริ่มต้นฉันอยู่กับ ฉีก.

ตอนนี้ตามความเป็นจริงคุณไม่สามารถตรวจสอบการอ้างอิงทั้งหมดได้ คุณไม่สามารถเช็คอินรูปภาพของเครื่องที่คุณใช้ในการสร้างบิลด์ คุณไม่สามารถตรวจสอบคอมไพเลอร์รุ่นที่แน่นอนได้ และอื่น ๆ มีข้อ จำกัด ที่เหมือนจริง แต่การเช็คอินทั้งหมดที่คุณทำได้ - ไม่ทำเช่นนั้นเพียงแค่ทำให้ชีวิตของคุณยากขึ้น และเราไม่ต้องการมัน

คำสุดท้าย: พ็อดไม่ได้สร้างสิ่งประดิษฐ์ บิวด์บิวด์คือสิ่งที่ได้รับจากบิวด์ของคุณ งานสร้างของคุณใช้พ็อดไม่ใช่สร้างขึ้น ฉันไม่แน่ใจด้วยซ้ำว่าทำไมเรื่องนี้ถึงต้องได้รับการพิจารณา

ข้อดีของการไม่เช็คอินPods/กับการควบคุมเวอร์ชัน (ตามลำดับความสำคัญตามอัตวิสัย):

1. ผสานการคอมมิทได้ง่ายขึ้นมากและโค้ดตรวจสอบต่างกัน การผสานเป็นสาเหตุของปัญหาทั่วไปในฐานของรหัสและสิ่งนี้ช่วยให้คุณสามารถมุ่งเน้นเฉพาะสิ่งที่เกี่ยวข้อง
2. เป็นไปไม่ได้ที่ผู้ให้ข้อมูลสุ่มบางรายจะแก้ไขการอ้างอิงตนเองและตรวจสอบการเปลี่ยนแปลงที่พวกเขาไม่ควรทำ (และอีกครั้งจะยากที่จะระบุว่า diff ต่างกันมากหรือไม่) การแก้ไขการพึ่งพาเป็นการปฏิบัติที่ไม่ดีมากเพราะในอนาคตpod installอาจทำให้เกิดการเปลี่ยนแปลงได้
3. ความแตกต่างระหว่างPodfileและPods/ไดเรกทอรีจะพบได้เร็วขึ้นในหมู่เพื่อนร่วมทีม หากคุณเช็คอินPods/และตัวอย่างเช่นอัปเดตเวอร์ชันในPodfileแต่ลืมที่จะเรียกใช้pod installหรือตรวจสอบการเปลี่ยนแปลงPods/คุณจะมีเวลามากขึ้นที่จะสังเกตเห็นแหล่งที่มาของความขัดแย้ง หากPods/ไม่ได้เช็คอินคุณจะต้องเรียกใช้pod installต่อไป
4. ขนาด repo ที่เล็กลง การมีไบต์ขนาดเล็กลงนั้นดี แต่ก็ไม่สำคัญอะไรนัก สำคัญกว่า: การมีสิ่งต่าง ๆ ใน repo เพิ่มภาระการรับรู้ของคุณ ไม่มีเหตุผลที่จะมีสิ่งต่าง ๆ ใน repo ที่คุณไม่ควรมอง อ้างถึงเอกสาร (สิ่งที่เป็นนามธรรม) เพื่อดูว่ามีอะไรทำงานได้บ้างไม่ใช่รหัส (การนำไปใช้)
5. ง่ายขึ้นที่จะแยกแยะว่ามีคนมีส่วนร่วมมากน้อยเพียงใด (เนื่องจากบรรทัดรหัสของพวกเขามีส่วนช่วยไม่รวมการพึ่งพาที่พวกเขาไม่ได้เขียน)
6. JARไฟล์.venv/(สภาพแวดล้อมเสมือน) และnode_modules/ไม่รวมอยู่ในการควบคุมเวอร์ชัน หากเราไม่เชื่อเรื่องพระเจ้าอย่างสมบูรณ์การไม่เช็คอินPodsจะเป็นค่าเริ่มต้นตามแบบอย่าง

ข้อเสียของการไม่เช็คอินPods/

1. คุณต้องทำงานpod installเมื่อเปลี่ยนสาขาหรือคืนค่าการคอมมิชชัน
2. คุณไม่สามารถเรียกใช้โครงการโดยการโคลนที่เก็บ pod installคุณต้องติดตั้งเครื่องมือฝักเรียกใช้แล้ว
3. คุณต้องมีการเชื่อมต่ออินเทอร์เน็ตเพื่อให้ทำงานpod installได้และจะต้องมีแหล่งที่มาของพ็อด
4. หากเจ้าของการอ้างอิงลบแพ็คเกจของพวกเขาแสดงว่าคุณกำลังมีปัญหา

โดยสรุปไม่รวมPodsไดเรกทอรีเป็นรั้วกับการปฏิบัติที่เลวร้ายมากขึ้น รวมทั้งPodsทำให้ไดเรกทอรีทำงานโครงการได้ง่ายขึ้น ฉันชอบอดีตมากกว่าหลัง คุณไม่จำเป็นต้องซักถามบุคคลใหม่ในโครงการเกี่ยวกับ "สิ่งที่ไม่ควรทำ" หากไม่มีความเป็นไปได้ที่จะทำผิดพลาดตั้งแต่แรก ฉันยังชอบความคิดที่จะมีการควบคุมเวอร์ชันแยกต่างหากPodsซึ่งช่วยลดข้อเสีย

ในทางทฤษฎีคุณควรตรวจสอบในไดเรกทอรี Pods ในทางปฏิบัติมันจะไม่ทำงานเสมอไป พ็อดจำนวนมากเกินขนาด จำกัด ของไฟล์ GitHub ดังนั้นหากคุณใช้ GitHub คุณจะพบปัญหาในการตรวจสอบในไดเรกทอรี Pods

TL; DR: เมื่อคุณติดตามPods/โฟลเดอร์โครงการจะรับได้ง่ายขึ้น เมื่อคุณไม่ติดตามมันจะง่ายขึ้นเมื่อคุณทำงานเป็นทีม

แม้ว่าองค์กร Cocoapods สนับสนุนให้เราติดตามPods/ไดเรกทอรีพวกเขาบอกว่ามันขึ้นอยู่กับ devs ที่จะตัดสินใจว่าจะทำหรือไม่ตามข้อดีข้อเสียเหล่านี้:  http://guides.cocoapods.org/using/using-cocoapods.html # ควร-I-check-the-ฝักไดเรกทอรีเข้าไปในแหล่งที่มาของการควบคุม

โดยส่วนตัวฉันมักจะติดตามPods/โฟลเดอร์สำหรับโครงการที่ฉันจะไม่ทำงานอีกต่อไปชั่วขณะ ด้วยวิธีนี้นักพัฒนาซอฟต์แวร์สามารถเลือกใช้งานได้อย่างรวดเร็วและทำงานต่อไปโดยใช้ cocoapod รุ่นที่เหมาะสม

ในทางกลับกันฉันคิดว่าประวัติความเป็นมาทำความสะอาดและง่ายขึ้นในการรวมรหัสและตรวจสอบรหัสของบุคคลอื่นเมื่อคุณไม่ได้ติดตามPods/โฟลเดอร์ ฉันมักจะตั้งค่าเวอร์ชันของ cocoapod library เมื่อฉันติดตั้งเพื่อให้แน่ใจว่าทุกคนสามารถติดตั้งโครงการโดยใช้เวอร์ชันเดียวกับฉัน

นอกจากนี้เมื่อPods/มีการติดตามไดเรกทอรีทั้งหมด devs ต้องใช้ Cocoapods รุ่นเดียวกันเพื่อป้องกันไม่ให้มีการเปลี่ยนแปลงไฟล์หลายสิบไฟล์ทุกครั้งที่เราเรียกใช้pod installเพื่อเพิ่ม / ลบพ็อด

Bottom line : เมื่อคุณติดตามPods/โฟลเดอร์โครงการจะง่ายต่อการรับ เมื่อคุณไม่ติดตามมันจะง่ายขึ้นในการปรับปรุง

ดูเหมือนว่าเป็นวิธีที่ดีในการจัดโครงสร้างสิ่งนี้จะต้องมีไดเรกทอรี "Pods" เป็นโครงการ submodule / แยก git นี่คือเหตุผล

• การมีพ็อดในโครงการ repo ของคุณเมื่อทำงานกับนักพัฒนาหลายคนอาจทำให้ VERY LARGE แตกต่างกันในคำขอแบบดึงซึ่งแทบจะเป็นไปไม่ได้เลยที่จะเห็นงานจริงที่คนเปลี่ยนไป มีการเปลี่ยนแปลงเล็กน้อยในโครงการจริง)

• ฉันเห็นปัญหาที่จะไม่ทำอะไรคอมไพล์ในขณะที่คนที่เป็นเจ้าของห้องสมุดสามารถเอามันลงได้ตลอดเวลาและคุณก็คือ SOL นี่เป็นสิ่งที่แก้ได้เช่นกัน

ไม่ว่าคุณจะเช็คอินในโฟลเดอร์ Pods ขึ้นอยู่กับคุณหรือไม่ก็ตามเนื่องจากเวิร์กโฟลว์นั้นแตกต่างกันไปในแต่ละโปรเจ็กต์ เราขอแนะนำให้คุณเก็บไดเรกทอรี Pods ไว้ภายใต้การควบคุมของแหล่งที่มาและไม่ควรเพิ่มลงใน. gitignore ของคุณ แต่ท้ายที่สุดการตัดสินใจนี้ขึ้นอยู่กับคุณ:

ประโยชน์ของการตรวจสอบในไดเรกทอรี Pods

1. หลังจากโคลน repo โครงการสามารถสร้างและเรียกใช้ได้ทันทีโดยไม่ต้องติดตั้ง CocoaPods บนเครื่อง ไม่จำเป็นต้องเรียกใช้การติดตั้งพ็อดและไม่จำเป็นต้องเชื่อมต่ออินเทอร์เน็ต
2. Pod วัตถุ (รหัส / ไลบรารี) พร้อมใช้งานเสมอถึงแม้ว่าแหล่งที่มาของ Pod (เช่น GitHub) จะลงไป
3. สิ่งประดิษฐ์ Pod รับประกันว่าจะเหมือนกันกับสิ่งที่อยู่ในการติดตั้งดั้งเดิมหลังจากโคลน repo

ประโยชน์ของการเพิกเฉยไดเรกทอรี Pods

1. repo การควบคุมแหล่งที่มาจะมีขนาดเล็กลงและใช้พื้นที่น้อยลง ตราบใดที่แหล่งที่มา (เช่น GitHub) สำหรับ Pods ทั้งหมดพร้อมใช้งาน CocoaPods สามารถสร้างการติดตั้งเดียวกันได้อีกครั้ง (ในทางเทคนิคไม่มีการรับประกันว่าการติดตั้งพ็อดจะเรียกใช้และสร้างสิ่งประดิษฐ์ที่เหมือนกันเมื่อไม่ใช้ SHA ที่ยอมรับใน Podfile โดยเฉพาะอย่างยิ่งเมื่อใช้ไฟล์ zip ใน Podfile)
2. จะไม่มีข้อขัดแย้งใด ๆ เมื่อจัดการการดำเนินการควบคุมแหล่งที่มาเช่นการรวมสาขากับรุ่น Pod ที่แตกต่างกัน ไม่ว่าคุณจะเช็คอินในไดเรกทอรี Pods หรือไม่ก็ตาม Podfile และ Podfile.lock ควรเก็บไว้ภายใต้การควบคุมเวอร์ชันเสมอ