Tôi đã thực hiện phát triển iOS được vài tháng và mới biết về thư viện đầy triển vọng của CocoaPods để quản lý phụ thuộc.

Tôi đã thử nó trong một dự án cá nhân: thêm một phụ thuộc vào Kiwi vào Podfile của tôi, chạy pod install CocoaPodsTest.xcodeprojvà voila , nó hoạt động rất tốt.

Điều duy nhất tôi còn băn khoăn là: tôi đăng ký cái gì và tôi bỏ qua điều gì để kiểm soát phiên bản? Có vẻ như rõ ràng là tôi muốn kiểm tra chính Podfile và có lẽ là tệp .xcworkspace; nhưng tôi có bỏ qua thư mục Pods / không? Có các tệp khác sẽ được tạo ra không (khi tôi thêm các phụ thuộc khác) mà tôi cũng nên thêm vào .gitignore của mình?

Cá nhân tôi không kiểm tra trong thư mục & nội dung của Pods. Tôi không thể nói rằng tôi đã dành thời gian dài để xem xét các hàm ý nhưng lý luận của tôi là một cái gì đó như:

Podfile đề cập đến một thẻ cụ thể hoặc cam kết của từng phụ thuộc để bản thân Pods có thể được tạo từ podfile, ergo chúng giống như một sản phẩm xây dựng trung gian hơn là một nguồn và do đó, không cần kiểm soát phiên bản trong dự án của tôi.

Tôi cam kết thư mục Pods của tôi. Tôi không đồng ý rằng thư mục Pods là một vật phẩm xây dựng. Trong thực tế, tôi muốn nói điều đó chắc chắn là không. Đó là một phần của nguồn ứng dụng của bạn: nó sẽ không được xây dựng mà không có nó!

Thật dễ dàng hơn khi nghĩ rằng CocoaPods là một công cụ dành cho nhà phát triển hơn là một công cụ xây dựng. Nó không xây dựng dự án của bạn, nó chỉ đơn giản là nhân bản và cài đặt các phụ thuộc của bạn cho bạn. Không cần thiết phải cài đặt Cốc Cốc để có thể đơn giản xây dựng dự án của bạn.

Bằng cách làm cho Cốc Cốc trở thành một sự phụ thuộc vào bản dựng của bạn, bây giờ bạn cần đảm bảo rằng nó có sẵn ở mọi nơi bạn có thể cần để xây dựng dự án của mình ... một quản trị viên nhóm cần nó, máy chủ CI của bạn cần nó. Theo nguyên tắc, bạn phải luôn có thể sao chép kho lưu trữ nguồn của mình và xây dựng mà không cần bất kỳ nỗ lực nào nữa.

Không cam kết thư mục Pods của bạn cũng tạo ra một cơn đau đầu lớn nếu bạn thường xuyên chuyển đổi chi nhánh. Bây giờ bạn cần chạy pod install mỗi khi bạn chuyển nhánh để đảm bảo sự phụ thuộc của bạn là chính xác. Điều này có thể ít rắc rối hơn vì sự phụ thuộc của bạn ổn định nhưng trong một dự án thì đây là một khoảng thời gian lớn.

Vì vậy, những gì tôi bỏ qua? Không có gì. Podfile, tệp khóa và thư mục Pods đều được cam kết. Tin tôi đi, nó sẽ giúp bạn tiết kiệm rất nhiều rắc rối. Nhược điểm là gì? Một repo lớn hơn một chút? Không phải la tận cung của thê giơi.

Tôi khuyên bạn nên sử dụng gitignore Objective-C của GitHub . Cụ thể, các thực tiễn tốt nhất là:

• Các Podfile phải luôn luôn dưới sự kiểm soát nguồn.
• Các Podfile.lock phải luôn luôn dưới sự kiểm soát nguồn.
• Không gian làm việc được tạo bởi CocoaPods phải được kiểm soát dưới nguồn.
• Bất kỳ Pod nào được tham chiếu với :pathtùy chọn nên được giữ dưới sự kiểm soát nguồn.
• Các ./Podsthư mục có thể được giữ dưới sự kiểm soát nguồn.

Để biết thêm thông tin bạn có thể tham khảo hướng dẫn chính thức .

nguồn: Tôi là thành viên của nhóm nòng cốt của Cốc Cốc, như @alloy

Mặc dù thư mục Pods là một tạo phẩm xây dựng, có những lý do mà bạn có thể cân nhắc trong khi quyết định thời tiết để giữ nó dưới sự kiểm soát nguồn:

• CocoaPods không phải là người quản lý gói nên tác giả có thể xóa nguồn gốc của thư viện trong tương lai.
• Nếu thư mục Pods được bao gồm trong kiểm soát nguồn, không cần thiết phải cài đặt CocoaPods để chạy dự án vì thanh toán sẽ đủ.
• CocoaPods vẫn đang hoạt động và có các tùy chọn không luôn dẫn đến cùng một kết quả (ví dụ: :headvà các :gittùy chọn hiện không sử dụng các cam kết được lưu trữ trong Podfile.lock).
• Có ít điểm thất bại hơn nếu bạn có thể tiếp tục công việc trong một dự án sau một khoảng thời gian trung bình / dài.

tập tin .gitignore

Không có câu trả lời thực sự cung cấp một .gitignore, vì vậy đây là hai hương vị.

Kiểm tra trong thư mục Pods ( Lợi ích )

Bỏ qua git thân thiện với Xcode / iOS, bỏ qua các tệp hệ thống Mac OS, Xcode, bản dựng, kho lưu trữ và bản sao lưu khác.

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

Bỏ qua thư mục Pods ( Lợi ích )

.gitignore: (nối vào danh sách trước)

# Cocoapods
Pods/

Cho dù bạn có kiểm tra trong thư mục Pods hay không, Podfile và Podfile.lock phải luôn được giữ dưới sự kiểm soát phiên bản.

Nếu Podskhông được đăng ký, Podfilecó lẽ bạn nên yêu cầu số phiên bản rõ ràng cho mỗi Cocoapod. Cocoapods.org thảo luận ở đây .

Tôi thường làm việc trên ứng dụng của khách hàng. Trong trường hợp đó, tôi cũng thêm thư mục Pods vào repo, để đảm bảo rằng tại bất kỳ thời điểm nào, bất kỳ nhà phát triển nào cũng có thể thực hiện kiểm tra và xây dựng và chạy.

Nếu đó là một ứng dụng của riêng chúng tôi, tôi có thể sẽ loại trừ thư mục Pods cho đến khi tôi không làm việc với nó trong một thời gian.

Trên thực tế, tôi phải kết luận rằng tôi có thể không phải là người tốt nhất để trả lời câu hỏi của bạn, so với quan điểm của người dùng thuần túy :) Tôi sẽ tweet về câu hỏi này từ https://twitter.com/CocoaPodsOrg .

Tôi kiểm tra mọi thứ. ( Pods/vàPodfile.lock .)

Tôi muốn có thể sao chép kho lưu trữ và biết rằng mọi thứ sẽ chỉ hoạt động như lần trước tôi đã sử dụng ứng dụng.

Tôi muốn các nhà cung cấp thay vì mạo hiểm có các kết quả khác nhau có thể do một phiên bản đá quý khác hoặc ai đó viết lại lịch sử trong kho lưu trữ của Pod, v.v.

Câu trả lời cho điều này được đưa ra trực tiếp trong tài liệu của Cocoapod. Bạn có thể xem " http://guides.cocoapods.org/USE/USE-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control "

Việc bạn có kiểm tra thư mục Pods hay không là tùy thuộc vào bạn, vì quy trình công việc khác nhau tùy theo dự án. Chúng tôi khuyên bạn nên giữ thư mục Pods dưới sự kiểm soát nguồn và không thêm nó vào .gitignore của bạn. Nhưng cuối cùng quyết định này tùy thuộc vào bạn:

Lợi ích của việc kiểm tra trong thư mục Pods

• Sau khi nhân bản repo, dự án có thể ngay lập tức xây dựng và chạy, ngay cả khi không cài đặt Cốc Cốc trên máy. Không cần phải chạy cài đặt pod, và không cần kết nối Internet.
• Các tạo phẩm Pod (mã / thư viện) luôn có sẵn, ngay cả khi nguồn của Pod (ví dụ GitHub) bị hỏng.
• Các tạo phẩm Pod được đảm bảo giống hệt với các bản cài đặt gốc sau khi nhân bản repo.

Lợi ích của việc bỏ qua thư mục Pods

• Repo kiểm soát nguồn sẽ nhỏ hơn và chiếm ít không gian hơn.

• Miễn là các nguồn (ví dụ GitHub) cho tất cả các Pod đều có sẵn, nói chung, Cốc Cốc có thể tạo lại cài đặt tương tự. (Về mặt kỹ thuật, không có gì đảm bảo rằng việc chạy cài đặt pod sẽ tìm nạp và tạo lại các tạo phẩm giống hệt nhau khi không sử dụng SHA cam kết trong Podfile. Điều này đặc biệt đúng khi sử dụng tệp zip trong Podfile.)

• Sẽ không có bất kỳ xung đột nào để giải quyết khi thực hiện các hoạt động kiểm soát nguồn, chẳng hạn như hợp nhất các nhánh với các phiên bản Pod khác nhau.

Cho dù bạn có kiểm tra trong thư mục Pods hay không, Podfile và Podfile.lock phải luôn được giữ dưới sự kiểm soát phiên bản.

Tôi đang ở trong trại của các nhà phát triển, những người không kiểm tra thư viện, cho rằng chúng tôi có sẵn một bản sao tốt ở một vị trí khác. Vì vậy, trong .gitignore của tôi, tôi bao gồm các dòng sau dành riêng cho CocoaPods:

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

Sau đó, tôi đảm bảo rằng chúng tôi có một bản sao của các thư viện ở một vị trí an toàn. Thay vì (mis-) sử dụng kho lưu trữ mã của dự án để lưu trữ các phụ thuộc (được biên dịch hay không) Tôi nghĩ cách tốt nhất để làm điều này là lưu trữ các bản dựng. Nếu bạn sử dụng máy chủ CI cho các bản dựng của mình (chẳng hạn như Jenkins), bạn có thể lưu trữ vĩnh viễn mọi bản dựng quan trọng đối với bạn. Nếu bạn thực hiện tất cả các bản dựng sản xuất trong Xcode cục bộ của mình, hãy tạo thói quen lấy một kho lưu trữ dự án của bạn cho bất kỳ bản dựng nào bạn cần giữ. Một cái gì đó như: 1. Sản phẩm -> Lưu trữ

1. Phân phối ... Gửi tới Cửa hàng ứng dụng iOS / Lưu cho doanh nghiệp hoặc triển khai đặc biệt / những gì có bạn

2. Hiển thị thư mục dự án của bạn trong Finder

3. Nhấp chuột phải và nén "AnyProject"

Điều này cung cấp một hình ảnh được xây dựng cho toàn bộ dự án, bao gồm các cài đặt dự án và không gian làm việc hoàn chỉnh được sử dụng để xây dựng ứng dụng cũng như các bản phân phối nhị phân (như Sparkle, SDK độc quyền như TestFlight, v.v.) cho dù họ có sử dụng CocoaPods hay không.

Cập nhật: Tôi đã thay đổi suy nghĩ về điều này và bây giờ cam kết Podfile.lockkiểm soát nguồn. Tuy nhiên, tôi vẫn tin rằng chính các nhóm này là các tạo phẩm xây dựng và nên được quản lý như vậy ngoài tầm kiểm soát nguồn, thông qua một phương pháp khác như máy chủ CI của bạn hoặc quy trình lưu trữ như tôi mô tả ở trên.

Tôi thích cam kết Podsthư mục cùng với PodfilevàPodfile.lock để đảm bảo bất kỳ ai trong nhóm của tôi có thể kiểm tra nguồn bất cứ lúc nào và họ không phải lo lắng về bất cứ điều gì hoặc làm thêm công cụ để làm cho nó hoạt động.

Điều này cũng giúp trong trường hợp bạn đã sửa lỗi bên trong một trong các nhóm hoặc sửa đổi một số hành vi theo nhu cầu của bạn nhưng những thay đổi này sẽ không khả dụng trên các máy khác nếu không được cam kết.

Và để bỏ qua các thư mục không cần thiết:

xcuserdata/

Tôi phải nói rằng, tôi là một fan hâm mộ của việc cam kết Pods vào kho lưu trữ. Theo liên kết đã được đề cập sẽ cung cấp cho bạn một tệp .gitignore tốt để tải lên các dự án Xcode cho iOS để cho phép Pods nhưng cũng để bạn dễ dàng loại trừ chúng nếu bạn muốn: https://github.com/github/gitignore/ blob / master / Objective-C.gitignore

Lý do của tôi là một người hâm mộ thêm Pods vào kho lưu trữ là vì một lý do cơ bản mà dường như không ai chọn, điều gì xảy ra nếu một thư viện mà dự án của chúng tôi phụ thuộc quá đột ngột bị xóa khỏi web?

• Có thể chủ nhà quyết định họ không còn muốn mở tài khoản GitHub nữa. Điều gì xảy ra nếu thư viện nói vài năm tuổi (chẳng hạn như hơn 5 tuổi) có nguy cơ cao dự án không còn khả dụng tại nguồn
• Ngoài ra một điểm khác, điều gì xảy ra nếu URL đến kho lưu trữ thay đổi? Giả sử người phục vụ Pod từ tài khoản GitHub của họ, quyết định tự đại diện cho mình dưới một xử lý khác - URL Pods của bạn sẽ bị hỏng.
• Cuối cùng là một điểm khác. Giả sử nếu bạn là nhà phát triển như tôi, người thực hiện nhiều mã hóa khi đang trên chuyến bay giữa các quốc gia. Tôi thực hiện nhanh chóng trên nhánh 'chính chủ', cài đặt pod trên nhánh đó, trong khi ngồi trong sân bay và chuẩn bị sẵn sàng cho chuyến bay 8 giờ sắp tới. Tôi có 3 giờ trong chuyến bay của mình và nhận ra rằng tôi cần phải chuyển sang một chi nhánh khác .... 'DOH' - thông tin Pod bị thiếu chỉ có trên nhánh 'chính chủ'.

NB ... xin lưu ý rằng nhánh 'chính' để phát triển chỉ là ví dụ, rõ ràng là các nhánh 'chính' trong các hệ thống kiểm soát phiên bản, nên được giữ sạch sẽ và có thể triển khai / xây dựng bất cứ lúc nào

Tôi nghĩ từ những điều này, ảnh chụp nhanh trong kho mã của bạn chắc chắn tốt hơn so với việc nghiêm ngặt về kích thước kho lưu trữ. Và như đã đề cập, tệp podfile.lock - trong khi phiên bản được kiểm soát sẽ cung cấp cho bạn một lịch sử tốt về các phiên bản Pod của bạn.

Vào cuối ngày, nếu bạn có thời hạn cuối cùng, ngân sách eo hẹp, thời gian là điều cốt yếu - chúng ta cần phải tháo vát nhất có thể và không lãng phí thời gian vào những ý thức hệ nghiêm ngặt, và thay vào đó khai thác một bộ công cụ để làm việc cùng nhau - để làm cho cuộc sống của chúng ta dễ dàng hiệu quả hơn.

Cuối cùng là tùy thuộc vào bạn cách tiếp cận.

Đây là những gì nhóm Cocoapods nghĩ về nó:

Việc bạn có kiểm tra thư mục Pods hay không là tùy thuộc vào bạn, vì quy trình công việc khác nhau tùy theo dự án. Chúng tôi khuyên bạn nên giữ thư mục Pods dưới sự kiểm soát nguồn và không thêm nó vào .gitignore của bạn. Nhưng cuối cùng quyết định này là tùy thuộc vào bạn.

Cá nhân tôi muốn loại bỏ Pods , dưới dạng node_modules nếu tôi đang sử dụng Node hoặc bower_components nếu tôi đang sử dụng Bower . Điều này áp dụng cho hầu hết mọi Trình quản lý phụ thuộc ngoài kia và là triết lý đằng sau các mô đun con git .

Tuy nhiên, đôi khi bạn có thể muốn thực sự chắc chắn về công nghệ hiện đại của một sự phụ thuộc nhất định, theo cách đó bạn đang mang sự phụ thuộc trong dự án của mình. Tất nhiên, có một số nhược điểm áp dụng nếu bạn làm điều đó, nhưng những lo ngại không chỉ áp dụng cho Cocoapods, những điều này áp dụng cho bất kỳ Trình quản lý phụ thuộc nào ngoài đó.

Bên dưới có một danh sách ưu / nhược điểm tốt được thực hiện bởi nhóm Cocoapods và toàn văn trích dẫn được đề cập trước đó.

Nhóm Cocoapods: Tôi có nên kiểm tra thư mục Pods vào kiểm soát nguồn không?

Nó phụ thuộc, cá nhân:

Tại sao các pod phải là một phần của repo (dưới sự kiểm soát nguồn) và không nên bỏ qua

• Nguồn giống hệt nhau
• Bạn có thể xây dựng nó ngay lập tức (ngay cả khi không có cocoapods)
• Ngay cả khi một nhóm bị xóa, chúng tôi vẫn có bản sao của nó (Có, điều này có thể xảy ra và nó đã xảy ra. Trong một dự án cũ mà bạn muốn chỉ cần một thay đổi nhỏ, bạn sẽ cần phải thực hiện một thư viện mới để có thể xây dựng).
• pods.xcodeprojcài đặt là một phần của kiểm soát nguồn là tốt. Điều này có nghĩa là ví dụ nếu bạn có dự án swift 4, nhưng một số nhóm phải ở trongswift 3.2 vì chúng chưa được cập nhật, các cài đặt này sẽ được lưu. Nếu không, người đã nhân bản repo sẽ bị lỗi.
• Bạn luôn có thể xóa các nhóm từ dự án và chạy pod install, điều ngược lại không thể được thực hiện.
• Ngay cả các tác giả của Cocoapods cũng khuyên nó.

Một số nhược điểm: kho lưu trữ lớn hơn, khác biệt khó hiểu (chủ yếu cho các thành viên trong nhóm), có khả năng xung đột nhiều hơn.

Đối với tôi, mối quan tâm lớn nhất là chứng minh nguồn của bạn trong tương lai. Nếu bạn dự định duy trì dự án của mình trong một thời gian và CocoaPods sẽ biến mất hoặc nguồn của một trong các nhóm bị hỏng, bạn hoàn toàn không gặp may nếu cố gắng xây dựng mới từ kho lưu trữ.

Điều này có thể được giảm nhẹ với các lưu trữ nguồn đầy đủ định kỳ.

Kiểm tra trong Pods.

Tôi nghĩ rằng đây là một nguyên lý phát triển phần mềm

• Tất cả các bản dựng phải được tái sản xuất
• Cách duy nhất để đảm bảo các bản dựng có thể tái sản xuất là kiểm soát tất cả các phụ thuộc; do đó kiểm tra trong tất cả các phụ thuộc là phải.
• Một nhà phát triển mới bắt đầu từ đầu sẽ có thể kiểm tra dự án của bạn và bắt đầu làm việc.

Tại sao?

CocoaPods hoặc bất kỳ thư viện bên ngoài nào khác có thể thay đổi có thể phá vỡ mọi thứ. Hoặc chúng có thể di chuyển, hoặc được đổi tên hoặc được loại bỏ hoàn toàn. Bạn không thể dựa vào internet để lưu trữ mọi thứ cho bạn. Máy tính xách tay của bạn có thể đã chết và có một lỗi nghiêm trọng trong sản xuất cần được sửa chữa. Nhà phát triển chính có thể bị xe buýt đâm và người thay thế phải khởi động vội vàng. Và tôi ước rằng cái cuối cùng là một ví dụ lý thuyết nhưng nó thực sự đã xảy ra ở một startup tôi đã ở cùng. YÊN NGHỈ.

Bây giờ, thực tế, bạn không thể thực sự kiểm tra TẤT CẢ các phụ thuộc. Bạn không thể kiểm tra hình ảnh của máy bạn đã sử dụng để tạo bản dựng; bạn không thể kiểm tra phiên bản chính xác của trình biên dịch. Và như thế. Có giới hạn thực tế. Nhưng hãy kiểm tra tất cả những gì bạn có thể - không làm như vậy chỉ khiến cuộc sống của bạn trở nên khó khăn hơn. Và chúng tôi không muốn điều đó.

Từ cuối cùng: Pods không được tạo tác. Tạo tác tạo là những gì được tạo từ bản dựng của bạn. Bản dựng của bạn sử dụng Pods, không tạo ra chúng. Tôi thậm chí không chắc chắn tại sao điều này phải được tranh luận.

Ưu điểm của việc không kiểm tra Pods/phiên bản kiểm soát (theo thứ tự quan trọng chủ quan):

1. Dễ dàng hơn nhiều để hợp nhất các cam kết và xem xét mã khác nhau. Sáp nhập là một nguồn phổ biến của các vấn đề trong cơ sở mã và điều này cho phép bạn chỉ tập trung vào những thứ thích hợp.
2. Một số người đóng góp ngẫu nhiên không thể tự chỉnh sửa các phụ thuộc và kiểm tra các thay đổi mà họ không bao giờ nên làm (và một lần nữa sẽ khó xác định nếu khác biệt là lớn). Chỉnh sửa các phụ thuộc là thực tiễn rất xấu vì một tương lai pod installcó thể bao gồm các thay đổi.
3. Sự khác biệt giữa Podfilevà Pods/thư mục được tìm thấy nhanh hơn giữa các đồng đội. Nếu bạn đăng ký Pods/và, ví dụ, cập nhật một phiên bản trong Podfile, nhưng quên chạy pod installhoặc kiểm tra các thay đổi Pods/, bạn sẽ gặp khó khăn hơn nhiều khi nhận thấy nguồn gốc của sự khác biệt. Nếu Pods/không được đăng ký, bạn luôn cần chạy pod install.
4. Kích thước repo nhỏ hơn. Có một dấu chân byte nhỏ hơn là tốt, nhưng điều đó không quan trọng lắm trong sơ đồ lớn. Quan trọng hơn: có nhiều thứ trong repo cũng làm tăng tải nhận thức của bạn. Không có lý do để có những thứ trong repo mà bạn không nên nhìn vào. Tham khảo tài liệu (sự trừu tượng) để biết cách thức hoạt động của một cái gì đó, không phải ở mã (việc thực hiện).
5. Dễ dàng nhận ra số tiền mà ai đó đóng góp (vì các dòng mã được đóng góp sẽ không bao gồm các phụ thuộc mà họ không viết)
6. JARcác tệp, .venv/(môi trường ảo) và node_modules/không bao giờ được bao gồm trong kiểm soát phiên bản. Nếu chúng ta hoàn toàn thuyết bất khả tri về câu hỏi, không check-in Podssẽ là mặc định dựa trên tiền lệ.

Nhược điểm của việc không kiểm traPods/

1. Bạn phải chạy pod install khi chuyển nhánh, hoặc hoàn nguyên các xác nhận.
2. Bạn không thể chạy một dự án chỉ bằng cách nhân bản kho lưu trữ. Bạn phải cài đặt công cụ pod, sau đó chạy pod install.
3. Bạn phải có kết nối internet để chạy pod installvà nguồn của các nhóm phải có sẵn.
4. Nếu chủ sở hữu của một phụ thuộc loại bỏ gói của họ, bạn sẽ gặp rắc rối.

Nói tóm lại, không bao gồm các Podsthư mục là một hộ lan tôn sóng chống lại hủ tục hơn. Bao gồm các Podsthư mục làm cho việc chạy dự án dễ dàng hơn. Tôi thích cái trước hơn cái sau. Bạn sẽ không cần phải phỏng vấn mọi người mới trong một dự án về "những việc không nên làm" nếu không có khả năng mắc một số sai lầm nhất định ngay từ đầu. Tôi cũng thích ý tưởng có một điều khiển phiên bản riêng để Podsgiảm bớt Nhược điểm.

Về lý thuyết, bạn nên kiểm tra trong thư mục Pods. Trong thực tế, nó không phải luôn luôn đi làm. Nhiều nhóm vượt quá giới hạn kích thước của tệp github, vì vậy nếu bạn đang sử dụng github, bạn sẽ gặp vấn đề khi kiểm tra trong thư mục Pods.

TL; DR: khi bạn theo dõi Pods/thư mục, dự án sẽ dễ lấy hơn. Khi bạn không theo dõi nó, sẽ dễ dàng cải thiện hơn khi bạn làm việc trong một nhóm.

Mặc dù tổ chức Cocoapods khuyến khích chúng tôi theo dõi Pods/thư mục, họ nói rằng tùy thuộc vào các nhà phát triển quyết định có nên làm điều đó hay không dựa trên những ưu và nhược điểm này:  http://guides.cocoapods.org/USE/USE-cocoapods.html # Should-i-check-the-pods-thư mục-vào-kiểm soát nguồn

Cá nhân, tôi thường theo dõi Pods/thư mục chỉ cho các dự án mà tôi sẽ không làm việc trong một thời gian nữa. Bằng cách đó, bất kỳ nhà phát triển nào cũng có thể nhanh chóng lấy từ nó và tiếp tục công việc bằng cách sử dụng phiên bản phù hợp của cocoapods.

Mặt khác, tôi nghĩ rằng lịch sử cam kết sẽ sạch hơn và dễ dàng hợp nhất mã hơn và xem lại mã của người khác khi bạn không theo dõi Pods/thư mục. Tôi thường đặt phiên bản của thư viện cocoapod khi tôi cài đặt nó để đảm bảo mọi người có thể cài đặt dự án bằng các phiên bản giống như tôi.

Ngoài ra, khi Pods/thư mục đang được theo dõi, tất cả các nhà phát triển phải sử dụng cùng một phiên bản Cocoapods để ngăn nó thay đổi hàng tá tệp mỗi khi chúng tôi chạy pod installđể thêm / xóa một nhóm.

Dòng dưới cùng : khi bạn theo dõi Pods/thư mục, dự án sẽ dễ dàng lấy hơn. Khi bạn không theo dõi nó, nó sẽ dễ dàng hơn để cải thiện.

Có vẻ như một cách tốt để cấu trúc điều này thực sự sẽ có thư mục "Pods" như một mô hình con git / dự án riêng biệt, đây là lý do tại sao.

• Có các nhóm trong repo dự án của bạn, khi làm việc với một số nhà phát triển, có thể khiến RẤT LỚN khác nhau trong các yêu cầu kéo mà gần như không thể thấy công việc thực tế đã bị thay đổi bởi mọi người (nghĩ rằng hàng trăm đến hàng nghìn tệp đã thay đổi cho các thư viện và chỉ một một số thay đổi trong dự án thực tế).

• Tôi thấy vấn đề không cam kết bất cứ điều gì với git, vì người sở hữu thư viện có thể gỡ bỏ nó bất cứ lúc nào và về cơ bản bạn là SOL, điều này cũng giải quyết được điều đó.

Việc bạn có kiểm tra thư mục Pods hay không là tùy thuộc vào bạn, vì quy trình công việc khác nhau tùy theo dự án. Chúng tôi khuyên bạn nên giữ thư mục Pods dưới sự kiểm soát nguồn và không thêm nó vào .gitignore của bạn. Nhưng cuối cùng quyết định này tùy thuộc vào bạn:

Lợi ích của việc kiểm tra trong thư mục Pods

1. Sau khi nhân bản repo, dự án có thể ngay lập tức xây dựng và chạy, ngay cả khi không cài đặt Cốc Cốc trên máy. Không cần phải chạy cài đặt pod, và không cần kết nối Internet.
2. Các tạo phẩm Pod (mã / thư viện) luôn có sẵn, ngay cả khi nguồn của Pod (ví dụ GitHub) bị hỏng.
3. Các tạo phẩm Pod được đảm bảo giống hệt với các bản cài đặt gốc sau khi nhân bản repo.

Lợi ích của việc bỏ qua thư mục Pods

1. Repo kiểm soát nguồn sẽ nhỏ hơn và chiếm ít không gian hơn. Miễn là các nguồn (ví dụ: GitHub) cho tất cả các Pod đều có sẵn, thì Cốc Cốc thường có thể tạo lại cài đặt tương tự. Điều này đặc biệt đúng khi sử dụng tệp zip trong Podfile.)
2. Sẽ không có bất kỳ xung đột nào để giải quyết khi thực hiện các hoạt động kiểm soát nguồn, chẳng hạn như hợp nhất các nhánh với các phiên bản Pod khác nhau. Cho dù bạn có kiểm tra trong thư mục Pods hay không, Podfile và Podfile.lock phải luôn được giữ dưới sự kiểm soát phiên bản.