Saya telah melakukan pengembangan iOS selama beberapa bulan sekarang dan baru belajar dari perpustakaan CocoaPods yang menjanjikan untuk manajemen ketergantungan.

Saya mencobanya pada proyek pribadi: menambahkan ketergantungan pada Kiwi ke Podfile saya, berlari pod install CocoaPodsTest.xcodeproj, dan voila , itu bekerja dengan baik.

Satu-satunya hal yang membuat saya bertanya-tanya adalah: apa yang harus saya periksa, dan apa yang saya abaikan untuk kontrol versi? Tampak jelas bahwa saya ingin memeriksa di Podfile sendiri, dan mungkin file .xcworkspace juga; tetapi apakah saya mengabaikan direktori Pods /? Apakah ada file lain yang akan dibuat di jalan (ketika saya menambahkan dependensi lain) yang juga harus saya tambahkan ke .gitignore saya?

Secara pribadi saya tidak memeriksa di direktori Pod & konten. Saya tidak bisa mengatakan saya menghabiskan waktu lama untuk mempertimbangkan implikasinya, tetapi alasan saya adalah seperti:

Podfile mengacu pada tag atau komit tertentu dari setiap ketergantungan sehingga Pod itu sendiri dapat dihasilkan dari podfile, karena mereka lebih seperti produk build menengah daripada sumber dan, karenanya, tidak memerlukan kontrol versi dalam proyek saya.

Saya melakukan direktori Pods saya. Saya tidak setuju bahwa direktori Pods adalah artefak build. Sebenarnya saya akan mengatakan itu pasti tidak. Itu bagian dari sumber aplikasi Anda: itu tidak akan dibangun tanpanya!

Lebih mudah untuk memikirkan CocoaPods sebagai alat pengembang daripada alat bangun. Itu tidak membangun proyek Anda, itu hanya mengkloning dan menginstal dependensi Anda untuk Anda. Seharusnya tidak perlu memiliki CocoaPods diinstal untuk hanya dapat membangun proyek Anda.

Dengan menjadikan CocoaPods ketergantungan dari bangunan Anda, Anda sekarang perlu memastikan itu tersedia di mana pun Anda mungkin perlu membangun proyek Anda ... admin tim membutuhkannya, server CI Anda membutuhkannya. Anda harus, sebagai suatu peraturan, selalu dapat mengkloning repositori sumber Anda dan membangun tanpa upaya lebih lanjut.

Tidak melakukan direktori Pods Anda juga membuat sakit kepala besar jika Anda sering berganti cabang. Sekarang Anda harus menjalankan instal pod setiap kali Anda mengganti cabang untuk memastikan dependensi Anda benar. Ini mungkin tidak terlalu merepotkan karena dependensi Anda stabil tetapi pada awal proyek ini adalah waktu yang sangat lama.

Jadi, apa yang harus saya abaikan? Tidak ada. Podfile, file kunci dan direktori Pods semuanya dikomit. Percayalah, itu akan menghemat banyak kerumitan. Apa yang kontra? Repo yang sedikit lebih besar? Bukan akhir dari dunia.

Saya sarankan untuk menggunakan gitignore Objective-C GitHub . Secara rinci, praktik terbaik adalah:

• Itu Podfile harus selalu berada di bawah kontrol sumber.
• Itu Podfile.lock harus selalu berada di bawah kontrol sumber.
• Ruang kerja yang dihasilkan oleh CocoaPods harus disimpan di bawah kendali sumber.
• Pod apa pun yang dirujuk dengan :path opsi harus disimpan di bawah kendali sumber.
• The ./Podsfolder dapat disimpan di bawah kontrol sumber.

Untuk informasi lebih lanjut, Anda dapat merujuk ke panduan resmi .

sumber: Saya anggota tim inti CocoaPods, seperti @alloy

Meskipun folder Pods adalah artefak build, ada beberapa alasan yang dapat Anda pertimbangkan saat memutuskan apakah akan menyimpannya di bawah kendali sumber:

• CocoaPods bukan pengelola paket sehingga sumber asli perpustakaan dapat dihapus di masa depan oleh penulis.
• Jika folder Pods termasuk dalam kontrol sumber, tidak perlu menginstal CocoaPods untuk menjalankan proyek karena checkout sudah cukup.
• CocoaPods masih bekerja dalam proses dan ada opsi yang tidak selalu mengarah ke hasil yang sama (misalnya opsi :headdan :gitsaat ini tidak menggunakan komit yang disimpan di Podfile.lock).
• Ada sedikit poin kegagalan jika Anda dapat melanjutkan bekerja pada suatu proyek setelah jangka waktu menengah / panjang.

File .gitignore

Tidak ada jawaban yang benar-benar menawarkan .gitignore, jadi inilah dua rasa.

Memeriksa di direktori Pods ( Manfaat )

Abaikan, git ramah Xcode / iOS diabaikan, melewatkan file sistem Mac OS, Xcode, build, repositori dan cadangan lainnya.

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

Mengabaikan direktori Pods ( Manfaat )

.gitignore: (tambahkan ke daftar sebelumnya)

# Cocoapods
Pods/

Apakah Anda memeriksa atau tidak di direktori Pods, Podfile dan Podfile.lock harus selalu disimpan di bawah kontrol versi.

Jika Podstidak check-in, Anda Podfilemungkin harus meminta nomor versi eksplisit untuk setiap Cocoapod. Diskusi Cocoapods.org di sini .

Saya biasanya bekerja pada aplikasi klien. Dalam hal ini saya menambahkan direktori Pods ke repo juga, untuk memastikan bahwa pada waktu tertentu setiap pengembang dapat melakukan checkout dan membangun dan menjalankan.

Jika itu adalah aplikasi kami sendiri, saya mungkin akan mengecualikan direktori Pods sampai saya tidak akan mengerjakannya untuk sementara waktu.

Sebenarnya, saya harus menyimpulkan bahwa saya mungkin bukan orang terbaik untuk menjawab pertanyaan Anda, dibandingkan pandangan pengguna murni :) Saya akan tweet tentang pertanyaan ini dari https://twitter.com/CocoaPodsOrg .

Saya memeriksa semuanya. ( Pods/dan Podfile.lock.)

Saya ingin dapat mengkloning repositori dan tahu bahwa semuanya akan berfungsi seperti yang terjadi terakhir kali saya menggunakan aplikasi.

Saya lebih suka menjual barang daripada berisiko memiliki hasil yang berbeda yang dapat disebabkan oleh versi permata yang berbeda, atau seseorang yang menulis ulang riwayat di repositori Pod, dll.

Jawaban untuk ini diberikan langsung dalam dokumen Cocoapod. Anda dapat melihat " http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control "

Apakah Anda memeriksa atau tidak di folder Pods terserah Anda, karena alur kerja bervariasi dari proyek ke proyek. Kami menyarankan Anda menyimpan direktori Pods di bawah kendali sumber, dan jangan menambahkannya ke .gitignore Anda. Namun pada akhirnya keputusan ini terserah Anda:

Manfaat memeriksa di direktori Pods

• Setelah mengkloning repo, proyek dapat segera membangun dan menjalankan, bahkan tanpa CocoaPods diinstal pada mesin. Tidak perlu menjalankan instal pod, dan tidak ada koneksi Internet diperlukan.
• Artefak Pod (kode / pustaka) selalu tersedia, bahkan jika sumber Pod (mis. GitHub) akan turun.
• Artefak Pod dijamin identik dengan instalasi asli setelah mengkloning repo.

Manfaat mengabaikan direktori Pods

• Repo kontrol sumber akan lebih kecil dan menghabiskan lebih sedikit ruang.

• Selama sumber (mis. GitHub) untuk semua Pod tersedia, CocoaPods umumnya dapat membuat ulang instalasi yang sama. (Secara teknis tidak ada jaminan bahwa menjalankan pemasangan pod akan mengambil dan membuat kembali artefak yang identik ketika tidak menggunakan SHA komit di Podfile. Ini terutama berlaku ketika menggunakan file zip di Podfile.)

• Tidak akan ada konflik yang harus dihadapi ketika melakukan operasi kontrol sumber, seperti menggabungkan cabang dengan versi Pod yang berbeda.

Apakah Anda memeriksa atau tidak di direktori Pods, Podfile dan Podfile.lock harus selalu disimpan di bawah kontrol versi.

Saya di kamp pengembang yang tidak memeriksa perpustakaan, dengan asumsi kami memiliki salinan yang baik tersedia di lokasi lain. Jadi, di .gitignore saya, saya menyertakan baris berikut khusus untuk CocoaPods:

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

Kemudian saya memastikan bahwa kami memiliki salinan perpustakaan di lokasi yang aman. Daripada (salah-) menggunakan repositori kode proyek untuk menyimpan dependensi (dikompilasi atau tidak) saya pikir cara terbaik untuk melakukan ini adalah dengan mengarsipkan build. Jika Anda menggunakan server CI untuk bangunan Anda (seperti Jenkins), Anda dapat secara permanen mengarsipkan semua bangunan yang penting bagi Anda. Jika Anda melakukan semua build produksi di Xcode lokal Anda, biasakan mengambil arsip proyek Anda untuk setiap build yang perlu Anda pertahankan. Sesuatu seperti: 1. Produk -> Arsip

1. Distribusikan ... Kirim ke App Store iOS / Simpan untuk Perusahaan atau Penyebaran Ad-hoc / apa pun yang Anda miliki

2. Buka folder proyek Anda di Finder

3. Klik kanan dan Kompres "Proyek Apapun"

Ini memberikan gambar yang dibangun dari keseluruhan proyek, termasuk pengaturan proyek dan ruang kerja lengkap yang digunakan untuk membangun aplikasi serta distribusi biner (seperti Sparkle, SDK eksklusif seperti TestFlight, dll.) Baik mereka menggunakan CocoaPods atau tidak.

Pembaruan: Saya sudah berubah pikiran tentang hal ini dan sekarang lakukan komit Podfile.lockke kontrol sumber. Namun, saya masih percaya bahwa pod itu sendiri adalah artefak yang dibangun dan harus dikelola di luar kendali sumber, melalui metode lain seperti server CI Anda atau proses arsip seperti yang saya jelaskan di atas.

Saya lebih suka melakukan Podsdirektori bersama Podfiledan Podfile.lockuntuk memastikan siapa pun di tim saya dapat checkout sumber kapan saja dan mereka tidak perlu khawatir tentang apa pun atau melakukan hal-hal tambahan untuk membuatnya berfungsi.

Ini juga membantu dalam skenario di mana Anda telah memperbaiki bug di dalam salah satu pod atau mengubah beberapa perilaku sesuai kebutuhan Anda, tetapi perubahan ini tidak akan tersedia di komputer lain jika tidak dilakukan.

Dan untuk mengabaikan direktori yang tidak perlu:

xcuserdata/

Saya harus mengatakan, saya penggemar melakukan Pods ke repositori. Mengikuti tautan yang telah disebutkan akan memberi Anda file .gitignore yang baik untuk mendapatkan proyek Xcode Anda untuk iOS yang memungkinkan Pods tetapi juga bagi Anda untuk dengan mudah mengecualikannya jika Anda menginginkannya: https://github.com/github.com/githign/gitignore/ gumpalan / master / Objective-C.gitignore

Alasan saya menjadi penggemar menambahkan Pod ke repositori adalah karena satu alasan mendasar yang sepertinya tidak ada yang mengerti, apa yang terjadi jika perpustakaan yang sangat bergantung pada proyek kami tiba-tiba dihapus dari web?

• Mungkin tuan rumah memutuskan mereka tidak lagi ingin membuka akun GitHub mereka. Apa yang terjadi jika perpustakaan dikatakan berumur beberapa tahun (misalnya lebih dari 5 tahun misalnya) ada risiko tinggi proyek mungkin tidak lagi tersedia di sumber
• Juga poin lain, apa yang terjadi jika URL ke repositori berubah? Katakanlah orang yang melayani Pod dari akun GitHub mereka, memutuskan untuk mewakili diri mereka di bawah pegangan yang berbeda - URL Pods Anda akan rusak.
• Akhirnya poin lain. Katakanlah jika Anda seorang pengembang seperti saya yang melakukan banyak pengkodean saat dalam penerbangan antar negara. Saya melakukan penarikan cepat pada cabang 'master', melakukan instal pod pada cabang itu, sambil duduk di bandara dan siap untuk penerbangan 8 jam mendatang. Saya mendapatkan 3 jam dalam penerbangan saya, dan menyadari bahwa saya perlu beralih ke cabang lain .... 'DOH' - informasi Pod hilang yang hanya tersedia di cabang 'master'.

NB ... harap dicatat cabang 'master' untuk pengembangan hanya untuk contoh, cabang-cabang 'master' dalam sistem kontrol versi, harus tetap bersih dan dapat digunakan / dibangun kapan saja

Saya pikir dari ini, snapshot dalam repositori kode Anda tentu lebih baik daripada menjadi ketat pada ukuran repositori. Dan seperti yang telah disebutkan, file podfile.lock - selagi versi terkontrol akan memberi Anda riwayat versi Pod yang baik.

Pada akhirnya, jika Anda memiliki tenggat waktu yang mendesak, anggaran yang ketat, waktu adalah yang paling penting - kita harus memiliki sumber daya sebanyak mungkin dan tidak membuang waktu untuk ideologi yang ketat, dan alih-alih memanfaatkan seperangkat alat untuk bekerja bersama - untuk membuat hidup kita lebih mudah lebih efisien.

Pada akhirnya terserah Anda pendekatan yang Anda ambil.

Inilah yang dipikirkan tim Cocoapods tentang hal itu:

Apakah Anda memeriksa atau tidak di folder Pods terserah Anda, karena alur kerja bervariasi dari proyek ke proyek. Kami menyarankan Anda menyimpan direktori Pods di bawah kendali sumber, dan jangan menambahkannya ke .gitignore Anda. Namun pada akhirnya keputusan ini terserah Anda.

Secara pribadi saya ingin mencegah Pod , sebagai node_modules jika saya menggunakan Node atau bower_components jika saya menggunakan Bower . Ini berlaku untuk hampir semua Manajer Ketergantungan di luar sana, dan juga merupakan filosofi di balik submisi git .

Namun ada kalanya Anda mungkin ingin benar-benar yakin tentang keadaan ketergantungan tertentu, dengan cara itu Anda membawa sendiri ketergantungan dalam proyek Anda. Tentu saja ada beberapa kelemahan yang berlaku jika Anda melakukan itu, tetapi kekhawatiran tidak hanya berlaku untuk Cocoapods, itu berlaku untuk Manajer Ketergantungan di luar sana.

Di bawah ini ada daftar pro / kontra yang baik yang dibuat oleh tim Cocoapods, dan teks lengkap dari kutipan yang disebutkan sebelumnya.

Tim Cocoapods: Haruskah saya memeriksa direktori Pods ke dalam kontrol sumber?

Itu tergantung, secara pribadi:

Mengapa pod harus menjadi bagian dari repo (di bawah kendali sumber) dan tidak boleh diabaikan

• Sumbernya identik
• Anda dapat membangunnya langsung apa adanya (bahkan tanpa cocoapods)
• Bahkan jika pod dihapus, kami masih memiliki salinannya (Ya, ini bisa terjadi dan memang terjadi. Dalam proyek lama di mana Anda hanya menginginkan perubahan kecil, Anda perlu mengimplementasikan perpustakaan baru untuk dapat membangunnya).
• pods.xcodeprojPengaturan juga merupakan bagian dari kontrol sumber. Ini berarti misalnya jika Anda memiliki proyek swift 4, tetapi beberapa pod harus masuk swift 3.2karena belum diperbarui, pengaturan ini akan disimpan. Kalau tidak, orang yang mengkloning repo akan berakhir dengan kesalahan.
• Anda selalu dapat menghapus pod dari proyek dan menjalankan pod install, sebaliknya tidak dapat dilakukan.
• Bahkan penulis Cocoapod merekomendasikannya.

Beberapa kontra: repositori yang lebih besar, diff yang membingungkan (terutama untuk anggota tim), berpotensi lebih banyak konflik.

Bagi saya, kekhawatiran terbesar adalah pembuktian sumber Anda di masa depan. Jika Anda berencana untuk mempertahankan proyek Anda untuk sementara waktu dan CocoaPods pernah hilang atau sumber salah satu podnya turun, Anda benar-benar kurang beruntung jika mencoba membuat yang baru dari arsip.

Ini dapat dikurangi dengan arsip sumber penuh berkala.

Periksa di Pods.

Saya pikir ini harus menjadi prinsip pengembangan perangkat lunak

• Semua build harus dapat direproduksi
• Satu-satunya cara untuk memastikan bangunan dapat direproduksi adalah dengan mengendalikan semua dependensi; karena itu memeriksa semua dependensi adalah suatu keharusan.
• Pengembang baru mulai dari awal harus dapat memeriksa proyek Anda dan mulai bekerja.

Mengapa?

CocoaPods atau perpustakaan eksternal lainnya dapat berubah yang mungkin merusak banyak hal. Atau mereka mungkin pindah, atau diganti nama, atau dihapus sama sekali. Anda tidak dapat mengandalkan internet untuk menyimpan barang-barang untuk Anda. Laptop Anda mungkin sudah mati dan ada bug penting dalam produksi yang perlu diperbaiki. Pengembang utama mungkin tertabrak bus dan penggantinya harus mulai terburu-buru. Dan saya berharap yang terakhir adalah contoh teoretis tetapi itu benar-benar terjadi pada startup yang saya ikuti. MENINGGAL DUNIA.

Sekarang, secara realistis, Anda tidak dapat benar-benar memeriksa SEMUA dependensi. Anda tidak dapat memeriksa gambar mesin yang Anda gunakan untuk membuat build; Anda tidak dapat memeriksa versi kompiler yang tepat. Dan seterusnya. Ada batasan realistis. Tetapi periksa semua yang Anda bisa - tidak melakukannya hanya membuat hidup Anda lebih sulit. Dan kami tidak menginginkan itu.

Kata terakhir: Pod bukan membangun artefak. Bangun artefak adalah apa yang dihasilkan dari bangunan Anda. Build Anda menggunakan Pods, bukan menghasilkannya. Saya bahkan tidak yakin mengapa ini harus diperdebatkan.

Kelebihan dari tidak memeriksa Pods/ke kontrol versi (dalam urutan kepentingan subjektif):

1. Jauh lebih mudah untuk menggabungkan komit, dan meninjau kode berbeda. Penggabungan adalah sumber masalah yang umum dalam basis kode, dan ini memungkinkan Anda untuk fokus hanya pada hal-hal yang terkait.
2. Tidak mungkin bagi beberapa kontributor acak untuk mengedit dependensi itu sendiri dan memeriksa perubahannya, yang seharusnya tidak pernah mereka lakukan (dan sekali lagi akan sulit untuk mengidentifikasi apakah perbedaannya masif). Mengedit dependensi adalah praktik yang sangat buruk karena masa depanpod install dapat menutup perubahan.
3. Perbedaan antara Podfiledan Pods/direktori ditemukan lebih cepat di antara rekan tim. Jika Anda masuk Pods/dan, misalnya, memperbarui versi di Podfile, tetapi lupa menjalankan pod installatau memeriksa perubahan di Pods/, Anda akan mengalami waktu yang jauh lebih sulit untuk mengetahui sumber perbedaan tersebut. Jika Pods/tidak masuk, Anda harus pod installtetap menjalankannya .
4. Ukuran repo yang lebih kecil. Memiliki byte-footprint yang lebih kecil itu bagus, tapi itu tidak masalah dalam skema besar. Lebih penting lagi: memiliki lebih banyak hal dalam repo juga meningkatkan beban kognitif Anda. Tidak ada alasan untuk memiliki hal-hal di repo yang seharusnya tidak Anda lihat. Lihat dokumentasi (abstraksi) untuk mengetahui cara kerja sesuatu, bukan pada kode (implementasinya).
5. Lebih mudah untuk mengetahui berapa banyak kontribusi seseorang (karena baris kode yang dikontribusikannya tidak akan menyertakan dependensi yang tidak mereka tulis)
6. JARfile, .venv/(lingkungan virtual), dan node_modules/tidak pernah disertakan dalam kontrol versi. Jika kami benar-benar agnostik tentang pertanyaan itu, tidak memeriksa Podsakan menjadi default berdasarkan preseden.

Kontra karena tidak memeriksaPods/

1. Anda harus menjalankan pod installketika berpindah cabang, atau mengembalikan komit.
2. Anda tidak dapat menjalankan proyek hanya dengan kloning repositori. Anda harus menginstal alat pod, lalu jalankan pod install.
3. Anda harus memiliki koneksi internet untuk dijalankan pod install, dan sumber pod harus tersedia.
4. Jika pemilik dependensi menghapus paket mereka, Anda dalam masalah.

Singkatnya, tidak termasuk yang Podsdirektori adalah pagar pembatas terhadap praktek-praktek yang lebih buruk. Termasuk yang Podsmerek direktori menjalankan proyek lebih mudah. Saya lebih suka yang pertama daripada yang terakhir. Anda tidak perlu menanyai setiap orang baru di proyek tentang "apa yang tidak boleh dilakukan" jika tidak ada kemungkinan untuk membuat kesalahan tertentu. Saya juga menyukai gagasan memiliki kontrol versi terpisah untuk Podsyang mengurangi Cons.

Secara teori, Anda harus memeriksa di direktori Pods. Dalam praktiknya, itu tidak selalu berhasil. Banyak pod jauh melebihi batas ukuran file github jadi jika Anda menggunakan github Anda akan mengalami masalah memeriksa di direktori Pods.

TL; DR: ketika Anda melacak Pods/folder, proyek lebih mudah diambil. Ketika Anda tidak melacaknya, lebih mudah untuk ditingkatkan ketika Anda bekerja dalam tim.

Meskipun organisasi Cocoapods mendorong kami untuk melacak Pods/direktori, mereka mengatakan itu tergantung pada para devs untuk memutuskan apakah akan melakukannya berdasarkan pro dan kontra ini:  http://guides.cocoapods.org/using/using-cocoapods.html # harus-i-periksa-direktori-pod-ke-kontrol-sumber

Secara pribadi, saya biasanya melacak Pods/folder hanya untuk proyek-proyek yang saya tidak akan kerjakan lagi untuk sementara waktu. Dengan begitu pengembang mana pun dapat dengan cepat mengambilnya dan melanjutkan pekerjaan menggunakan versi cocoapod yang tepat.

Di sisi lain, saya pikir histori komit menjadi lebih bersih dan lebih mudah untuk menggabungkan kode dan meninjau kode orang lain ketika Anda tidak melacak Pods/folder. Saya biasanya mengatur versi perpustakaan cocoapod ketika saya menginstalnya untuk memastikan siapa pun dapat menginstal proyek menggunakan versi yang sama seperti saya.

Juga, ketika Pods/direktori sedang dilacak semua devs harus menggunakan versi yang sama dari Cocoapods untuk mencegahnya mengubah lusinan file setiap kali kita menjalankan pod installuntuk menambah / menghapus pod.

Intinya : ketika Anda melacak Pods/folder, proyek lebih mudah diambil. Ketika Anda tidak melacaknya, lebih mudah untuk ditingkatkan.

Sepertinya cara yang baik untuk struktur ini akan benar-benar memiliki direktori "Pods" sebagai git submodule / proyek terpisah, inilah alasannya.

• Memiliki pod di repo proyek Anda, ketika bekerja dengan beberapa pengembang, dapat menyebabkan VERY LARGE berbeda dalam permintaan tarik di mana hampir tidak mungkin untuk melihat pekerjaan aktual yang diubah oleh orang-orang (pikirkan beberapa ratus hingga ribuan file diubah untuk perpustakaan, dan hanya sebuah sedikit yang berubah dalam proyek aktual).

• Saya melihat masalah tidak melakukan apa pun untuk git, karena orang yang memiliki perpustakaan dapat menghapusnya kapan saja dan Anda pada dasarnya adalah SOL, ini juga menyelesaikannya.

Apakah Anda memeriksa atau tidak di folder Pods terserah Anda, karena alur kerja bervariasi dari proyek ke proyek. Kami menyarankan Anda menyimpan direktori Pods di bawah kendali sumber, dan jangan menambahkannya ke .gitignore Anda. Namun pada akhirnya keputusan ini terserah Anda:

Manfaat memeriksa di direktori Pods

1. Setelah mengkloning repo, proyek dapat segera membangun dan menjalankan, bahkan tanpa CocoaPods diinstal pada mesin. Tidak perlu menjalankan instal pod, dan tidak ada koneksi Internet diperlukan.
2. Artefak Pod (kode / pustaka) selalu tersedia, bahkan jika sumber Pod (mis. GitHub) akan turun.
3. Artefak Pod dijamin identik dengan instalasi asli setelah mengkloning repo.

Manfaat mengabaikan direktori Pods

1. Repo kontrol sumber akan lebih kecil dan menghabiskan lebih sedikit ruang. Selama sumber (mis. GitHub) untuk semua Pod tersedia, CocoaPods umumnya dapat membuat ulang instalasi yang sama. (Secara teknis tidak ada jaminan bahwa menjalankan pod installasi akan mengambil dan membuat ulang artefak yang identik ketika tidak menggunakan komit SHA di Podfile Ini terutama benar ketika menggunakan file zip di Podfile.)
2. Tidak akan ada konflik yang harus dihadapi ketika melakukan operasi kontrol sumber, seperti menggabungkan cabang dengan versi Pod yang berbeda. Apakah Anda memeriksa atau tidak di direktori Pods, Podfile dan Podfile.lock harus selalu disimpan di bawah kontrol versi.